New! 4ch delay plug-in... Delay 4D!

Discussion in 'Effects and the DSP' started by Maddogg6, Jan 17, 2006.

  1. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    First off - you are NOW called 'Saint Russ' - the PATIENT saint. :D
    Thank you for putting up with my thickness...

    i.e.
    You put the data in at position 0, and you have a read pointer at 5.
    After one cycle, that data is at position 1.
    After two cycles, that data is at position 2.
    After three cycles, that data is at position 3.
    After four cycles, that data is at position 4.
    After five cycles, that data is at position 5, where you read pointer is, so what you are reading is a sample from 5 cycles ago, thus it is delayed 5 cycles.
    If you fed a sample into position 0, every cycle, then you will get those same samples back out 5 cycles later, so they are all delayed by 5 samples. Now the samples are not removed from the delay line, they keep moving until they reach the end, so if you had another read pointer further down the line, then you would get the same samples again but a more delayed version of it.[/QUOTE]

    The above makes perfect sense to me -

    (note: questions are numbered for your answering convenience)

    1) Additional read pointers would give us more 'taps' also - correct?
    OK - What hapens when 'anything above 50% will result in a values beyond the size of the delay line.' - these samples are lost because they would be re-written to/over - correct?

    Ok - this is how we can get stereo and multiple taps
    ie.

    2) for stereo we'd need at least; 2 inputs, 2 outputs, 2 write pointers and 2 read pointers - correct?

    3) for multiple taps we simply add more read pointers at various addresses with in the maxtramsize range - correct?

    4) to have feed back - we need to mix final output with a read points contents and re-write that result to some (maybe same as said read point) tram location - correct?

    5) and NO need to CHANGE pointers (at run time) UNTIL we want to adjust the delay time (via a slider for instance) or have some dynamic tap points - correct?

    Thanks again Russ. - Er, Saint Russ.[​IMG]
     
  2. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    hehe :)

    1) Yes, and, I am not really sure what happens when you write beyond the size of the TRAM. Under normal circumstances it would be corrupting some memory somewhere else (very bad), but I am not sure what it does here (and in this case, you are actually reading, not writing anything, so I guess the worst thing that would happen is you would get data that is not audio data).

    2) Yes, for independant channels.

    3) Yes.

    4) Yes, but you would write the feedback to a write location (you cannot write to anywhere other than a write location).

    5) Yes.
     
  3. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    But we CAN dynamically change the write pointer - no?
    Or can we ONLY change the read pointer dynamically?
     
  4. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    I do like it -

    And thanks for the info and link...


    I'll have a look at your others too.
     
  5. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Actually, I am not sure about that, I have never tried, and have not seen anyone else try it either (but I suppose it is possible, although it would not be practicle). Generally, there is no need to move the write pointer, as moving the read pointer would accomplish the same thing.
     
    Last edited: Jan 30, 2006
  6. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Ahh - ok - yeah that makes sense.

    My thought was - starting with shorter delay - and feedback times increased dynamically. Whether by a modulation input - ot simply increasing over time. - granted maybe not 'pleasing' to hear. I'd think this equate to more of a reverb start - but delay (longer delay time) with the feedback. - thus *almost* accomplish a sort of reverb AND delay in one segment of tram. Thus saving on tram.

    These are the things Id like to experiment with when I mentioned 'different delay algos'.
     
  7. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Right, but again, moving the read pointer would do the same thing, as all you are really doing is changing the distances between the write pointers and the read pointers, and considering that it would not make sense to have a read pointer before it's write pointer, the write pointer may as well stay at the beginning of the delay line, and just move the read pointer.
     
  8. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    I suppose if you wanted two or more delay lines of unequal length, you could move the additional write pointers around (along with the read pointers... it wouldn't make much sense to move the first write pointer).
     
  9. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    hehe - all them years I was told 'think outside of the box' is really paying off for YOUR headache medicine makers.. lol

    Sorry - it wasn't intended.

    The point of moving read pointer instead of write pointer is still making more sense.
    I must be looking at things from a different angle or something. (out of the box of possibilities maybe - probably?)


    Im still having troubles getting a results I expect tho. I'll get it eventually. I just hope I didnt drive ya to the nut farm in the process.
     
  10. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Ok -so Im playing around - and it seems like xTRAM is kept - even after unloading the reload a plugin.. NO WONDER im getting so fricken confused...

    Heres what I see:

    I test the delay by opening the windows system sounds panel (easy way to force a sound to plat thats short and easy to hear the delays behaviour)

    I make a change to TRAM size - from 4 seconds to 1 second -
    Re-save the dane source - unload last instance of plugin - reload it with changes
    And IMMEDIATLY I hear echod sounds from lat test.

    Is there a way to force the tram cleared?
    or is this the reason why its not recommended to increase xTram buffer size?


    Also - what the heck do the DANE errors mean.

    (25) P200 bla bla bla

    it appears the '(25)' is a line number?? - I dont see anything explaining these.
     
  11. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    I have never noticed that myself. How long is your delay?
    <edit>
    Never mind, I see that you said that it was 4 seconds and 1 second. I will try it.
    </edit>

    The errors are usually fairly self explanatory, but not always.
    The most common errors would probably be:
    Mis-spelled instruction or register name, or the same name used twice (failry obvious).
    Too many or not enough parameters for an instruction (they should all have 4 parameters).
    A missing comma, or a period instead of a comma, or a comma where there should not be one (like after the instruction or after the last parameter (i.e. end of the line)).

    If you show the full text of the error, we might be able to tell you what the problem is.

    BTW: That delay thing doesn't sound right. Are you sure you are not making a loop somehwere else that is reintroducing the signal into the delay when you reload it? Does it do it, even when you have not reconnected the inputs to anything?

    <edit2>
    Well I tried to re-create it using a 4 second delay (as well as changing it to a 1 sec delay like you described) with feedback such that it repeats virtually forever, and could not reproduce the problem.
    </edit2>
     
    Last edited: Jan 31, 2006
  12. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    BTW: Make sure that your Tank Memory size is enough for a 4 second delay. Sometimes the DSP seems to allow a plugin to load, even though it uses more TRAM than is available (some kind of bug), but if you look up at the top of the DSP window, it might say something like: 'xTramSize 378/256', indicating that you are using more xTram than is available, and that might cause some anomolies.
     
  13. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    well, I fixed the error - but was hoping the first 2 numbers meant something..

    Now...
    reguardless of my logic errors in the code - if I:

    change the tram size -
    Save the dane code
    unload the plugin
    reload the plogin & reconnect ins and outs (silent input)
    I hear echos from last test.

    So - Im getting erroneous results.

    Code:
    ; itramsize 0
    	xtramsize 48000;
    ; Registers
    	output out1, out2, out3, out4;
    	input x;
    	control level=0x7fffffff, feedback=0x40000000, delay=0x1c20000;
    
    macs in, x, 1, 0;
    
    	xdelay write wrt at 0x0;
    	
    	xdelay read rd1 at 0;
    	xdelay read rd2 at 12000;
    	xdelay read rd3 at 24000;
    	xdelay read rd4 at 36000;
    	
    	
    ; Code
    	 acc3 	 &rd1,  delay,  &rd1,  0x0;
    	 ; offset RD1 delay time by adjusting the read pointer
    	 
    	 acc3 	 &rd2,  delay,  &rd2,  0x0;
    	 ; offset RD2 delay time by adjusting the read pointer
    	 
    	 acc3 	 &rd3,  delay,  &rd3,  0x0;
    	 ; offset RD3 delay time by adjusting the read pointer
    	 
    	 acc3 	 &rd4,  delay,  &rd4,  0x0;
    	 ; offset RD4 delay time by adjusting the read pointer		  
    	 
    	 macs 	 out1,  in,  level,  rd1;
    	 macs 	 out2,  in,  level,  rd2;
    	 macs 	 out3,  in,  level,  rd3;
    	 macs 	 out4,  in,  level,  rd4;		  
       
    	 
    	 macs 	 wrt,  in,  rd1,  feedback;
    
    end
    
    
    
    Its based on legacy/'Delay Old'

    I Changed the xTram size from 192000, and the reads from 48000, 96000, & 144000 respectively also.

    Maybe the dane parser isnt catching all errors. And Im sure their in there.
    But id expect to at least hear a difference - but Im not.

    Also, futher trying at this point - seems like the delay time hasnt changed.

    I switched back to H btw... cuz of the ProFx bugs.

    Maybe this was fixed in I ??

    Edit: Posted wrong code
     
    Last edited: Jan 31, 2006
  14. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    No, that code does do the same thing to me. I would not use that code. I do not not why the address is calculated that way, unless maybe something different was done internally with older kX versions that somehow made it work. I would stay away from any of the legacy code, as there is probably a reason why they are legacy plugins.
     
  15. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    huh?

    Whats changed? - why is it still included if its not valid?

    ARG! - very frustrating - because newer delay examples are more complicated...

    maybe Im just not wired to grasp this stuff...
     
  16. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    If you make the following changes it should work right:

    //////////////////////////////////////////////////////////////

    macs &rd1, &wrt, 0x1770000, delay;
    ; offset RD1 delay time by adjusting the read pointer

    macs &rd2, &rd1, 0x1770000, delay;
    ; offset RD2 delay time by adjusting the read pointer

    macs &rd3, &rd2, 0x1770000, delay;
    ; offset RD3 delay time by adjusting the read pointer

    macs &rd4, &rd3 , 0x1770000, delay;
    ; offset RD4 delay time by adjusting the read pointer

    //////////////////////////////////////////////////////////////

    The '0x1770000' is based on the 48000 (1 sec) delay size.
    i.e.
    4 read pointers: 48000 / 4 = 12000
    12000 * 0x800 = 0x1770000.
     
  17. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    So - legacy didnt require that 0x800 factored in?

    I appreciate the correction, but im not clear why you changed the offsets:

    macs &rd1, &wrt, 0x1770000, delay;

    you changed the &RD1 to &WRT ; &rd2 to &rd1.. etc...

    I understand the 0800 factor now- btw.


    - I'll come back tomarrow - cuz Im burnt out on it now....

    I need a STRONG DRINK... lol
     
  18. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Wait - I take that back - I guess I dont understand the 0x800 factor thing...

    anyway....

    Cheers... Nastrovia, Oye, Bottoms up, GULP.
     
  19. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    The problem with adding to the same read pointer is that the delay will always get bigger, no matter what the delay setting is (other than 0). That is why I started the calculations from the write pointer. The code I posted may not do what you wanted it to do, but I am not sure what you wanted it to do. I think you wanted one of the following two possibilities:

    1) You wanted equally spaced read pointers (such that each read pointers delay time is double that of the previous read pointer). The code I posted works like this.

    or

    2) You wanted the delays to be based on the original read points.
    i.e.
    Delay for the 1st read pointer is added to 0.
    Delay for the 2nd read pointer is added to 12000.
    Delay for the 3rd read pointer is added to 24000.
    Delay for the 4rd read pointer is added to 36000.
    This would produce a different effect, and is possible to do, but you have to do your calculations based on those starting positions, instead of the previous value of the read pointer.
     
    Last edited: Jan 31, 2006
  20. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Ahh - so I could have also use '0x0' instead of &rd1 or &wrt

    What I was trying to accomplish was; as delay control changes all of the pointers change equally - BUT feedback only provided by FIRST read only. Thus, as feedback decays- the other read points will recieve the feedback as well. But this brings a question to mind..

    Just to make sure actually -

    If I write a 99 to the WRT - assuming the delay control is set to 0.
    it wil appear at RD1 in 12000 samples later
    then appear at RD2 in 24000 sample later
    then appear at RD3 in 36000 samples later

    AFTER 48000 samples - the 99 is trashed/zero'd - its NOT at 0x0 again at 480001 -

    In other words - if its NOT trashed/zero'd - it would be like a feedback - and would not make sense that, after 48000 (or +1) samples - the 99 re-appears at &wrt again.

    This is my assumption/understanding.

    I will play around some more when I have a few nerves grow back.. hehe

    'I think I can, I think I can...'


    Thanks again for your 'Saintly-hood' Russ.


    Keep this up and your gonna make Pope.
    -AND you'll have ME to thank for it... (I accept most any kind of 'Thank you' currency, beer, money, little sisters > 17... ) :)
     

Share This Page

visited