Ok I see what you guys mean- Code: xtramsize 48001; ; Registers output out1, out2, out3, out4; input inL, inR; control feedback=0.5; control delay=0.8; static x, y, z; ; copy to avoid re-use error macs x, InL, 0, 0 macs y, inR, 0, 0 macs z, x, 0, 0 ; create cross mix interp x, x, .25, y; interp y, y, .25, z; interp z, x, .5, y ; setup tram read and write points xdelay write wrt1a at 0; xdelay read rd1a at 0; xdelay read rd2a at 12000; xdelay read rd3a at 24000; xdelay read rd4a at 36000; ; offset delay read times by adjusting the read pointer macs &rd1a, &wrt1a, 0x1770000, delay; macs &rd2a, &rd1a, 0x1770000, delay; macs &rd3a, &rd2a, 0x1770000, delay; macs &rd4a, &rd3a, 0x1770000, delay; ; Mix and output delayed samples interp out1, rd1a, .5 , x; interp out2, rd2a, .5 , y; interp out4, rd3a, .5 , y; interp out3, rd4a, .5 , x; ; Mix (in L+R) and write feedback to tram macs wrt1a, z, out4, feedback; end I *think* this makes more sense. I got rid of the level control too as I use it as a send effect anyway. Thanks again guys.... Mark
Well it is all good, if it does what you want. Here is what I see it doing (for out1): out1 = (50% of (75% of inL + 25% of inR)) + (50% of delayed (50% of (75% of inL + 25% of inR))) <edit> Actually that is not right... I forget to add out4 into the feedback... err nevermind </edit>
hehe - you know me - Im not smart enough with this stuff to 'get what I want'... lol (specially since Im not sure what I want :sigh: ) I'll be the first to admit, Im still not fully 'thinking' in a 'per sample' mind set...so I'm just listening for something I like. And I thought it sounded cool with a 3/4 panning staccato guitar, so.... Now to concentrate out how to implement 'time' from samples with good ol *cough* C++ .
Just so it is clear, with the way you are using x, y, and z in your code (writing to them first), thay are basically temp's (i.e. static is not needed), so the interp instruction is not doing a running average or anything like that, it is just mixing (which from your comments, seems to be what you wanted).
Well - I *was* trying something like that - but it just seemed to make feedback times longer when I did... so I re-init those registers. But I kept them statics as recommended in the guide.
And that makes sense, unless you are trying to do a ping-pong thing like Max does. In any case, congrats on figuring out the whole TRAM addressing thing. The more you play around with (any) code, the more things will start to makes sense, etc.
maybe I'll try converting his (correction: hacking) Delays to be 4 channel as well later - but I want to get to the whole C++ changing registers thing (calculate time from samples and display) - which will lead to *gasp* trying the tempo detection.... thanks again for all you help everyone.. Mark
The following 2 instructions cause bad noise for me: Code: macs wr3, wr1, rd3, Feedback; macs wr4, wr2, rd4, Feedback; You probably should not read from a TRAM write address like that. It should probably be (to give the same result without the noise): Code: macs wr3, rL, rd3, Feedback; macs wr4, rR, rd4, Feedback; Other then the above, it seems to work good
Ah - I think it needs to lower the level - the stacking is prolly overloading Wr3/4. But your change -changed the behaviour.. (the rear lost its 'faster' delay) This is more what it should sound like: That sounds more like intended.
Your right, my suggestion was not quite the same thing, but the noise was not an overloading problem. i.e. (this code should do what original code did (and works ok for me without lowering the level)): Code: acc3 fL, inL, 0, 0; acc3 fR, inR, 0, 0; macs rL, fL, rd1, Feedback; macs rR, fR, rd2, Feedback; acc3 wr1, rL, 0, 0; acc3 wr2, rR, 0, 0; macs wr3, rL, rd3, Feedback; macs wr4, rR, rd4, Feedback; ...
Yup thats it - I changed my original to free up those 2 tmps I added. And of course credit for your suggestion too... Mark edit - Im better at naming plugins than making them.. what can I say...:sigh:
No, it worked good, except for that one part. I am just surprised you did not notice the noise (was pretty severe for me).
Naa - worked fine for me - but I was using lower level inputs - and did notice that it 'peaked' the rears when I boosted input levels - but 'sounded' fine otherwise - So just Looked like overload on my end. Now - the rears output never exceed the inputs levels - as it should be anyway...