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

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

  1. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    I think I understand what is happening with the delay_old code. Even without the 0x800 thing, it does still produce an address, (and with the default settings, the default delay just happens to be 0x1c20000, which concidentally (?) happens to be (0x1c20000 / 0x800 = 14400) the size the xTram used by that plugin. So any delay setting above the default, is reading beyond the size of its delay line.

    To explain the reason why you can still hear it, after unloading/reloading it, I am guessing that that when you write to TRAM, that it propigates through the entire TRAM address space, until it encounters another write pointer (which it does not do if nothing else is using TRAM, and as such, the full TRAM is used). So when you read beyond the the size of your delay line, you are reading further down the TRAM's address space, effectively increasing the delay time, beyond that of your own delay line (and with feedback, you are writing the value back over and over again). With a value of 50%, the delay time is (0x40000000 / 800 = (524288 / 48000) = a little more than 9 seconds of delay (a delay of 100% would be a little more than 21 seconds of delay, but I would guess that it stops when it reaches the TRAM size allocated by the driver). So, if you do not wait a full 22 seconds before you reload the plugin, you can still pickup the previous samples in TRAM if you move the delay slider far enough. Additionally, if you do have other plugins using TRAM (that were loaded after this plugin, so that there address space is ahead of the delay_old plugin's address space), then this plugin will read into thier address space, picking up whatever is in their delay line (and with feedback, writing that back into it's address space / delay line). I bet this is how shared gpr's (and lookup tables) would work (i.e. if you knew the correct address to read, then all plugins could access the info (although it would probably require the use of iTram because of latency issues.).

    In any case, I am not sure why this plugin does this. Maybe it was originally intended to be used as the only plugin using xTram (when it is used), or maybe, it was originally designed without a slider, and the slider was added later, but they forgot to increase the xTram size to the max possible delay time. There are many possibilities, and it would not be the only plugin that ended up getting included with kX, that contained a bug (if that behavior was not intentional).

    <edit>
    I have not really played with delays that big (i.e. 21 seconds), but I would guess that the delay line is not flushed when you unload you plugin (it is just not feeding back into it any longer), so if you made a large delay (that does not read beyond its own delay size), and were able to unload/reload it within the delay time period, you probably would still be able to pick up the old samples from the TRAM.
    </edit>
     
    Last edited: Jan 31, 2006
  2. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Remember that you are adding to an address, so you need a starting address. It would be best to calculate all your addresses from &wrt since it is at 0 (the beginning of your delay line (which probably is not the address 0x0)). Or at least calculate your first address like this, and then you can use your calculated address to calculate your next address, etc, the point is to start with a known address location.

    Not with the code I posted. With a delay of zero, all the read pointers will be 0 (or actually, zero added to &wrt). With the delay set to full (100%), then it would be as you described.

    Right, it does not loop back around on it's own.
     
  3. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    BTW: I thought that one thing that might be confusing you is the fact that the '0' or '0x0' in:
    xdelay write wrt at 0x0;
    - is not the address 0x0, nor is it the beginning of TRAM (otherwise all plugins would be using the same starting point). Dane (or the plugin loader, or whatever) is translating that 0x0 to an appriopriate address, such that it is outside the TRAM used by other plugins. It basically just means the starting point of your delay line.

    Additonally, with initial read addresses, such as:
    xdelay read rd2 at 12000;
    - the 12000 is not the address, it is an address that is 12000 samples beyond the starting point of your delay line.

    Since the value is translated to an address behind the scenes, we do not know what the actual addresses are, except that using the '&' operator retrieves that address. This is why you need to start with a known starting address (i.e. &wrt) when calculating new addresses.
     
    Last edited: Jan 31, 2006
  4. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    YES! - Ok, Ive been playing around and I see that - each plugin has 'segregated' / protected tram...

    So for instance - I just discovered - if I want 4 ins and 4 outs - with ONLY common 'delay' adjustment - and NO singal from in1 being sent to OUT2,3,4 -
    Ie - emulate 4 mono delays - but with ONLY a common delay adjutment..
    is impossible - unless some trickery can 'emulate' protected tram within a plugins tram space. - Its obvious now why - but It JUST hit me.

    Thats prolly why my failed example are not making sense.

    Im gonn try to make one that; the delay adjustment is an input (also an output) - so I can daisy chain 4 seperate mono delay plugins - and use ONLY 1 delay adjust to control them all.

    But I see that a 'control' is read only - so I would need to make a 'Master' and a 'Slave' for this... but I KNOW I can do it.

    Now I wonder whats involved to get a MIDI clock to control delay times - in beats and not just time. Too bad - KX Control MIDI port cant supply a 'register' (a translated tempo thats read accessable by dane) for this function... if its not already there. ... heh - I dream, I know...

    BUT! Maybe theres hope for me yet...





    alright! no need for nasty comments.... :D
     
  5. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    BTW - is there a reference on what registers ARE available for use - I seen NOISE and I thought SINE - are there other - even if not obviously useful - I may be able to find uses for em... maybe..??
     
  6. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Do not forget that you can create multiple delay lines within the same plugin, instead of daisy chaining 4 plugins together (just create multiple write pointers). (look at plugins that do stereo delay... they only use one slider).
    ie. (with xtramsize 24002)
    xdelay write wr1 at 0;
    xdelay read rd1 at 12000;
    xdelay write wr2 at 12001;
    xdelay read rd2 at 24001;
    Then you move the first read pointer using the first write pointer's address for reference, and you move the second read pointer using the second write pointer's address for reference.

    As for the midi clock, I do not know much about that stuff as of yet, but you can create counters/timers based on the sample rate to work out whatever timing you need.

    As for the registers:
    The as10k1 manual lists them.
    Also, dspnames.h in the kX SDK lists them. Not all of them can be used in Dane (i.e. physical inputs and outputs require C++.).
    I think the main one's you would be interested in (for use with Dane), are:
    ccr, accum, noise1, and noise2

    There is one more restriction with TRAM that I haven't mentioned as of yet, and that is the number of read/write pointers that you can have. For xTram, you can only have 32 within the whole DSP. For iTram it is 128. So keep that in mind if you want to create a delay with a lot of taps. I am not sure if it is different for 10k2 cards, but that info is shown at the top of the DSP window . i.e. 'iTram 0/128' and 'xTram 0/32' shows how much is in use, and the maximum number that can be used.
     
    Last edited: Feb 1, 2006
  7. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    >ccr, accum, noise1, and noise2

    there're also dbac and irq (dbac is xtram delay base address counter, and irq is the register to fire interrupts) - no big use for these two though (the only application i can remember is AC3 passthrough thingy for K1)
     
  8. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Ahhh...
    I was wondering what those meant.


    My card btw..

    Shows 192 & 64 pointers allowed.
     
  9. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    The first number is the line number as you discovered. The second number is just some error code, and its description (I imagine) would be the error text that follows it.
     
  10. Tril

    Tril Triple screen racing ftw

    Joined:
    Sep 26, 2004
    Messages:
    1,665
    Likes Received:
    19
    Trophy Points:
    48
    You can display the line numbers. Right-click in the window of the kX Dane Editor, click properties, go to the Misc tab and choose the decimal line numbering style. It's useful to find out which line is causing an error.
     
  11. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Speaking of, does anyone know a way to get those settings to stick?
     
  12. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    >Speaking of, does anyone know a way to get those settings to stick?

    btw. are still that settings available in 38? i thought v38 has plain text editing window (no customization at all)

    anyway (for an earlier versions?) - there's no way to save editor settings. (in fact i always wonder if somebody uses kX Editor for editing *.da files... exactly because of those unsaved settings (i hate that font) and non-resizable window...)

    it could be more comfortable to use any external editor with customizable syntax highlighting (there're tons of such - personally i use 'context') - however (since there's no standalone dane translator) kX Editor is still the only way (now) to check if code is correct and (if needed) to translate *.da into C++ structures - so if you need to check code for correctness too often - that jumping between different editors can be weird again... ouch.
     
    Last edited: Feb 1, 2006
  13. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Well - Im a noob with DSP's - and I HAVE to rely on DANE editor to syntax highlight cuz I make so many mistakes... Not to mention the simple code check button.

    I like/have textpad - but havent bothered making syntax/dictionary files for dane, because the missing ability to use kx/dane as an external compiler from textpad.

    I spent a little time looking in registry and other files - looking for where dane editor 'reads' those un-savable settings from - but couldnt find a thing.

    But yes - in 3538h and j - I can/could change the font; add/choose line number; edit key-shortcuts - even edit Pascal/HTML/Java/SQL/XML files with syntax highlighting.. hehe - looks like dane is a 3rd party text editor embedded in KX.
     
  14. Maddogg6

    Maddogg6 Tail Razer

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

    If seen some non-related things that allowed - Im not sure how explain this...

    But like for netmeeting: a batch/script can be made to 'jump' into parts of a DLL like

    rundll32.exe msconf.dll,CallToProtocolHandler IP_Address

    This is supposed to allow one use a script/batch file to kind of use 'command line params' in a way Ive not seen before. - Netmeeting btw, doesnt appear to allow CLP's.

    This (Im a programming challenged sole, mind you) looks like one can access parts of a DLL directly..

    I was wondering if dane error checking/ compiling & export C++ was possible in such a manner.

    Thus, external editors would be possible/easier to use...

    ?? - I dunno - just an idea/wondering.
     
  15. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    I also do a lot of editing to code that is allready uploaded (i.e. with .dll plugins), and the kX Editor seems to be the only choice for doing that. (i.e. testing out different things, without having to re-export to C++, and recompile, etc, it is nice being able to make the changes like this).
     
  16. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Yeah, I know what you are talking about Maddogg6. I am not sure if we could do such things with kX Editor or not, but it is something to look into.
     
  17. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Ok - here is a pretty cool 'Stereo - to - 4 Channel Delay'

    Thanks to Russ for his patients as I would have nover understood much of this without him.

    Code:
    ; Generated by kX DSP Editor - microcode dump
    name "Delay ST2QD A";
    copyright "(c) Mark Davis 2007 - Based on work by: (c)Max Mikhailov, 2003-2005";
    ; Russ G. Gets ALOT of credit for this too - 
    
    ; NOTE The present DSP microcode dump is protected by the 
    ; license agreement bundled with the appropriate software 
    ; package containing this microcode,
    ; regardless the particular copyright notice is present in the dump.
    
    comment "Stereo->4 ch delay A";
    	guid "38a8b450-2f64-4ad1-9b9b-d97cd7e973e5";
    	; -- generated GUID
    
    
    	xtramsize 48000;
    
    ; Registers
    	output out1, out2, out3, out4;
    	input inL, inR;
    	control level=1, feedback=0.5;
    	control delay=0.5;
        static x, y;
    
       
        ; copy & summ the INS to avoid re-use error
        interp x, inL, .5, inR;
        interp y, inR, .5, inL
      	
       ; setup tram read and write points
        xdelay write wrt1a at 0;
        xdelay read rd1a at 11999;
        xdelay read rd2a at 23999;
        xdelay read rd3a at 35999;
        xdelay read rd4a at 47999;
        
    
        ; offset delay read times by adjusting the read pointer
        ; Thanks to Russ - I would have never figured this out	 
        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
    	 macs 	 out1,  x,  level,  rd1a;
    	 macs 	 out2,  y,  level,  rd2a;
    	 macs 	 out3,  x,  level,  rd3a;
    	 macs 	 out4,  y,  level,  rd4a;	 	 
    	 
    	 ; write feedback to tram
    	 macs 	 wrt1a,  x,  out4,  feedback;
         
    	 
    
    end
    
    I had to re-read this thread for refresher on delay lines - as its gonna be my first attempt at adding 'tap tempo' (via MIDI CC) ability - for my C++ undertaking.


    Mark
     
  18. Russ

    Russ Well-Known Member

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

    There is only one thing that I noticed (after a quick glance), that is probably not what you intended:

    Code:
    ; copy & summ the INS to avoid re-use error
        interp x, inL, .5, inR;
        interp y, inR, .5, inL
    
    From your comment, it looks like you are trying to avoid using input registers more than once in your code, but then you did it anyway (note that 'inL' and 'inR' are used in both instructions (thus they are used more than once)).

    <edit>
    Actually I am not quite sure what you are trying to do there (you seem to be mixing the left and right inputs together (kind of a mono-mix to 4 channel delay))...
    </edit>

    -Russ
     
    Last edited: Mar 6, 2007
  19. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Doh - I did reuse them huh... I changed that. Thank you sir
    /lame excuse
    I had originally *just* mixed in L + R - but then I swapped the mix (2nd intepol) and the mix at the outs too - its a sort of 'circular' delay with my 4 point (Front & Rear) 'surround'.
    /lame excuse

    No one understood whats his name... that artist/painter who cut off his ear either... lolz

    ... :D

    Its just a cool sounding 4 channel delay - I don't hear too many 'surround' delay algos to compare to it - so... I dunno - just tried making something 'musical' I guess.
    Thought this worked well for 3/4 meter music. (still trying to make a 4/4 one. - me thinks I need to add a 5th delay tap to delay between 4th and 1st taps)

    Heres the fix:
    Code:
    	xtramsize 48000;
    
    ; Registers
    	output out1, out2, out3, out4;
    	input inL, inR;
    	control level=1, 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, .5, y;
      	interp y, y, .5, z;
      	
    	; setup tram read and write points
    	xdelay write wrt1a at 0;
    	xdelay read rd1a at 11999;
        xdelay read rd2a at 23999;
        xdelay read rd3a at 35999;
        xdelay read rd4a at 47999;
        
    
        ; 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
    	 macs 	 out1,  x,  level,  rd1a;
    	 macs 	 out2,  y,  level,  rd2a;
    	 macs 	 out4,  x,  level,  rd3a;
    	 macs 	 out3,  y,  level,  rd4a;	 	 
    	 
         ; write feedback to tram
    	 macs 	 wrt1a,  x,  out4,  feedback;
         
    end
    
    
    Still learning.
     
  20. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    yup, as Russ noticed:
    Code:
    ; 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, .5, y;
    interp y, y, .5, z;
    
    i see no "cross-mix" here too. y is always equal to x with this (simply because
    "A + B = B + A" ;))
    It would make the trick though - if you replace '.5' with some 'crossmix' control
    (although it will be significant only for 'hard-stereo' input)
     
    Last edited: Mar 6, 2007

Share This Page

visited