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

Russ · Jan 31, 2006, 07:51 AM

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>

Russ · Jan 31, 2006, 08:43 AM

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.

Maddogg6 · Jan 31, 2006, 08:50 AM

Quote:

Originally Posted by Russ

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>

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

Russ · Jan 31, 2006, 09:06 AM

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.

Maddogg6 · Jan 31, 2006, 09:09 AM

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...

Russ · Jan 31, 2006, 09:17 AM

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.

Maddogg6 · Jan 31, 2006, 09:26 AM

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

Maddogg6 · Jan 31, 2006, 09:28 AM

Wait - I take that back - I guess I dont understand the 0x800 factor thing...

anyway....

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

Russ · Jan 31, 2006, 09:56 AM

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.

Maddogg6 · Jan 31, 2006, 09:16 PM

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... )

Russ · Jan 31, 2006, 10:16 PM

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>

Russ · Jan 31, 2006, 10:42 PM

Quote:

Originally Posted by Maddogg6

Ahh - so I could have also use '0x0' instead of &rd1 or &wrt

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.

Quote:

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

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.

Quote:

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

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

Russ · Feb 1, 2006, 12:05 AM

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.

Maddogg6 · Feb 1, 2006, 12:32 AM

Quote:

Originally Posted by Russ

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 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 Dane is doing the translation, 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 calcualting new addresses.

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....

Maddogg6 · Feb 1, 2006, 12:34 AM

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..??

Russ · Feb 1, 2006, 01:06 AM

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.

Max M. · Feb 1, 2006, 02:10 AM

>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)

Maddogg6 · Feb 1, 2006, 03:18 AM

Quote:

Originally Posted by Russ

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.

Ahhh...
I was wondering what those meant.

My card btw..

Shows 192 & 64 pointers allowed.

Russ · Feb 1, 2006, 05:24 AM

Quote:

Originally Posted by Maddogg6

well, I fixed the error - but was hoping the first 2 numbers meant something..

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.

Tril · Feb 1, 2006, 06:46 AM

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.

Russ · Feb 1, 2006, 07:03 AM

Quote:

Originally Posted by Tril

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.

Speaking of, does anyone know a way to get those settings to stick?

Max M. · Feb 1, 2006, 11:09 AM

>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.

Maddogg6 · Feb 1, 2006, 07:47 PM

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.

Maddogg6 · Feb 1, 2006, 10:09 PM

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.

Russ · Feb 1, 2006, 10:10 PM

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).

Russ · Feb 1, 2006, 10:20 PM

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.

Maddogg6 · Mar 6, 2007, 04:05 AM

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

Russ · Mar 6, 2007, 05:28 AM

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

Maddogg6 · Mar 6, 2007, 07:30 AM

Quote:

Originally Posted by Russ

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)).

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

Quote:

<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>

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

...

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.

Max M. · Mar 6, 2007, 11:47 AM

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)

Jan 31, 2006, 07:51 AM	#31
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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 by Russ; Jan 31, 2006 at 08:20 AM.

Jan 31, 2006, 09:56 AM	#39
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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 by Russ; Jan 31, 2006 at 10:08 AM.

Jan 31, 2006, 10:16 PM	#41
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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 by Russ; Jan 31, 2006 at 11:07 PM.

Feb 1, 2006, 12:05 AM	#43
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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 by Russ; Feb 1, 2006 at 12:17 AM. Reason: typos

Feb 1, 2006, 01:06 AM	#46
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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 by Russ; Feb 1, 2006 at 01:26 AM.

Jan 31, 2006, 08:43 AM	#32
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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.

Jan 31, 2006, 09:06 AM	#34
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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.

Jan 31, 2006, 09:09 AM	Thread Starter #35
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 50	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...

Jan 31, 2006, 09:17 AM	#36
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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.

Jan 31, 2006, 09:26 AM	Thread Starter #37
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 50	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

Jan 31, 2006, 09:28 AM	Thread Starter #38
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 50	Wait - I take that back - I guess I dont understand the 0x800 factor thing... anyway.... Cheers... Nastrovia, Oye, Bottoms up, GULP.

Jan 31, 2006, 09:16 PM	Thread Starter #40
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 50	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... )

Feb 1, 2006, 12:34 AM	Thread Starter #45
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 50	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..??

Feb 1, 2006, 02:10 AM	#47
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,606 Rep Power: 66	>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)

Feb 1, 2006, 06:46 AM	#50
Tril S-3D enthusiast Join Date: Sep 2004 Location: Canada Posts: 1,675 Rep Power: 62 System Specs	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.

Feb 1, 2006, 11:09 AM	#52
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,606 Rep Power: 66	>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 by Max M.; Feb 1, 2006 at 11:28 AM.

Feb 1, 2006, 07:47 PM	Thread Starter #53
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 50	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.

Feb 1, 2006, 10:09 PM	Thread Starter #54
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 50	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.

Feb 1, 2006, 10:10 PM	#55
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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).

Feb 1, 2006, 10:20 PM	#56
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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.

Mar 6, 2007, 05:28 AM	#58
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,507 Rep Power: 61	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 by Russ; Mar 6, 2007 at 05:47 AM.

Mar 6, 2007, 11:47 AM	#60
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,606 Rep Power: 66	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 by Max M.; Mar 6, 2007 at 11:53 AM.