Ping Pong delay

Maddogg6 · Feb 7, 2006, 05:44 AM

Ok - so I re-grew some nerves and decided to make a delay algo that I meant to be the outcome, instead of blindly 'stumbling' upon anything..

So - IT WORKS! -well - it sounds like a ping pong to me.

Code:

; 	xtramsize 36001;
; Registers
	output Out1, Out2;
	input In;
	control level= 1, feedback= .5, delay= .25;
	static t1, t2, ad1=0x1770000; ad1 = 12000 * 0x800


   
		
; Then we set up the WRITE points	
	xdelay write wrt at 0;
	xdelay read rd1 at 1;	
	xdelay read rd2 at 12002;	
	
; Lets make sure the INPUT not used more than once
	macs t1, In, 0, 0 ;	

	 
	; Now we adjust the delay length by adjusting the RD points

macs	t2, 0, ad1, delay; 
macints &rd1, &wrt, t2, 1;
macints &rd2, &wrt, t2, 2;

	 
	 ; Send (input + (delayed*level)) to output
	 

	 macs 	 Out1,  t1,  rd2, level;
	 
	 macs 	 Out2,  t1,  rd1, level;
	 
	

	 ; Add criss-cross feedback to delay lines
	 

	 macs 	 wrt,  t1,  rd2, feedback;	 


end

I have a question tho...

If I change the last line (feedback) to
macs wrt, rd1, rd2, feedback

everything goes silent... why is this... a short answer is fine - I just don't understand, because the rd2 is used..??

Russ · Feb 7, 2006, 05:52 AM

It looks pretty good, but your xTramsize is bigger than it needs to be (you probably only need a size of 24001).

<edit>
As for your question, it goes silent because you are never writing any data to the delay line that way (i.e. you can't get output if you do not add input).

Maddogg6 · Feb 7, 2006, 06:00 AM

Well - 36001 - would make more sense...

Im doubling the second line.

Code:

; Now we adjust the delay length by adjusting the RD points

	 macs 	 &rd1,  &wrt,  ad1, delay;
	 macints t2, 0, 2, delay; Double delay size 
	 macs 	 &rd2,  &rd1,  ad1, t2;

edit: corrected typeo -

Maddogg6 · Feb 7, 2006, 06:02 AM

Quote:

Originally Posted by Russ

As for your question, it goes silent because you are never writing any data to the delay line that way (i.e. you can't get output if you do not add input).

Ahhh . Doh!

Russ · Feb 7, 2006, 06:03 AM

You are right, I did not see that line (glanced over it to quick I guess). Good job.

Damn speed reading course! ROFL

Maddogg6 · Feb 7, 2006, 06:04 AM

Nevermind...

Russ · Feb 7, 2006, 06:08 AM

No, the xDelay write intruction just defines a write pointer. If anything, it writes a 0.

Maddogg6 · Feb 7, 2006, 06:09 AM

Quote:

Originally Posted by Russ

No, if anything, it writes a zero.

Yeah - its just setting up a register to be an address - I suspect.

Russ · Feb 7, 2006, 06:12 AM

Quote:

Originally Posted by Maddogg6

Well - 360001 - would make more sense...

So we do not confuse anybody, that should read 36001.

Maddogg6 · Feb 7, 2006, 07:06 AM

But - the code is correct then - right?

Russ · Feb 7, 2006, 07:09 AM

Quote:

Originally Posted by Maddogg6

But - the code is correct then - right?

Yeah, it looks pretty good.

Russ · Feb 7, 2006, 07:13 AM

Doh, spoke too soon.

Just a couple things:
What are you trying to do here? :
macs t1, In, 1, 0 ;

1 * 0 = 0

Why not just use:

macs t1, In, 0, 0 ;

Maybe it is just a typo?

Also, here:
macints t2, 0, 2, delay; Double delay size
You should swap the X and Y param, as delay is a fractional number, and 2 is an integer.

Maddogg6 · Feb 7, 2006, 07:15 AM

that would equal -

t1 = in

- Im making sure I dont reuse that input register... no?

Maddogg6 · Feb 7, 2006, 07:16 AM

so its t1 = IN + (1*0) = IN

Isnt it the same?

Maddogg6 · Feb 7, 2006, 07:19 AM

Quote:

Originally Posted by Russ

Also, here:
macints t2, 0, 2, delay; Double delay size
You should swap the X and Y param, as delay is a fractional number, and 2 is an integer.

This JUST doubles the delay -or

T2 = 0 + (2 * delay)

oops - THERE was a typeo...

But I read that any number can be an integer... i thought anyway...

Russ · Feb 7, 2006, 07:20 AM

Quote:

Originally Posted by Maddogg6

so its t1 = IN + (1*0) = IN

Isnt it the same?

Yes, it is the same, it is just that the 1 serves no purpose, so you might as well leave it out ( make it zero).

i.e.
'T1 = IN + (1*0)' is the same as 'T1 = IN + (0*0)'

Maddogg6 · Feb 7, 2006, 07:25 AM

confirmed:

Either can be integers...

Its prolly bad form tho...

Russ · Feb 7, 2006, 07:27 AM

The X param can be either (which means you should enter the number in hex so that Dane is sure of your intention), but the Y param is always an integer, and as 'delay' is not an integer (it is a fractional number), you do not want it to be the Y param.

i.e. Instead of muitplying 0.5 * 2, it is multiplying 1073741824 * 2.

Maddogg6 · Feb 7, 2006, 07:30 AM

Quote:

Originally Posted by Russ

The X param can be either (which means you should enter the number in hex so that Dane is sure of your intention), but the Y param is always an integer, and as 'delay' is not an integer (it is a fractional number), you do not want it to be the Y param.

The guide recommends using decimal for easier understanding - but I DO see everyone using HEX - I'm beginning to see a few sources of confusions...

Not to down the guide - but maybe it could be updated or changed... If I ever get to a level of understanding I may just do that...

Maddogg6 · Feb 7, 2006, 07:32 AM

Quote:

Originally Posted by Russ

The X param can be either (which means you should enter the number in hex so that Dane is sure of your intention), but the Y param is always an integer, and as 'delay' is not an integer (it is a fractional number), you do not want it to be the Y param.

i.e. Instead of muitplying 0.5 * 2, it is multiplying 1073741824 * 2.

I got ya - I was thinking the other was assumed an integer

Russ · Feb 7, 2006, 07:37 AM

Well it is not necessarliy a matter of everyone is using hex (I generally do), it is more likley that they are posting the microcode dump, instead of the source, and the dump shows the numbers in hex.

As for the whole matter with the X param of a MACINTS instruction can be either, that is pretty confusing, and I am not really sure how we are supposed to let the processor know what we meant it to be, so I generally try to avoid it (you do not have to multiply 2 integers together all that often), and when I have to do it, I verify the results are what I intended.

Maddogg6 · Feb 7, 2006, 07:59 AM

It doesnt seem to make a difference:

macints t2, 0, 2, delay; Double delay size

sounds the same as

macints t2, 0, delay, 2; Double delay size

Thus Im thinking the the number format going into that indtruction is indicated..
Maybe the DSP's CCR - not sure what flags are in there. But it could make sense.

Russ · Feb 7, 2006, 08:22 AM

In this case it ends up with the same result, but it is doing so by using some undocumented feature. I think maybe if the integer is above a certain number, that it treats it as a fractional number instead. And in this case, because delay is defined elsewhere, it knows that it is supposed to be a fractional number. Had you entered those numbers in manually (in decimal) however, you would have gotten different results.
The Y paramater would have been rounded off to the nearest integer value (1).

Max M. · Feb 7, 2006, 01:59 PM

macints t2, 0, delay, 2;
macints t2, 0, 2, delay;

these are equal actually... normally, X and Y operands are fully swappable in macint* instructions
(in both cases Dane is able to understand that 2 is integer, since 2 can’t be valid fractional)
The only exception would be if 1 is used:
macints t2, 0, delay, 1;
macints t2, 0, 1, delay;
in that case the second instruction goes wrong - Dane treats X = 1 as fractional 1.
When the value of constant is ambiguous (1 can be both valid integer and valid fractional) - Dane (for macint* instr.) simply treats X as fractional and Y as integer (this is Dane's feature/issue and not the property of processor)

the one can use 'i' suffix to avoid ambiguity:
macints t2, 0, 1i, delay; does what is expected

>but I DO see everyone using HEX

NO! this is illusion forced by kX Editor. Note that when you click 'Edit' in kX DSP you typically see disassembler listing - not a source code! (and hex numbers are there for two reasons:
1. to ensure that listing produces binary equal code when compiled back 2. just to keep disassembler 's code simple).

How do you think does it really make sense to write
macsn r, 0x5b22d0e4, x, 0x7fffffff
instead of
macsn r, 0.712, x, 1
?

Although sometimes the hexs do the trick if they look less ambiguous (0x1 instead of 1 (don't forget about 1i)) or just more clear (0x800 instead of 2048)

-----

there's some small issue also (if i'm not mistaken):
macints t2, 0, 2, delay;
macs &rd2, &rd1, ad1, t2;

->when 'Delay' fader is above .5 (50%) - it doesn't anymore change t2 (because of saturation - t2 always = 1 when delay > .5; ... t2 just can't be > 1)
Was that your intention? (delay control still affects rd2 though - since rd1 still changes)
If not (e.g. if non-linear behavior of the second delay is not your goal) then you could just reorder some operations a bit... like that maybe:

Code:

macs    &rd1, &wrt, ad1, delay;
macs    t2, 0, ad1, delay;
macints &rd2, &rd1, t2, 2;

or (more clear to see what the code does actually)

Code:

macs	t2, 0, ad1, delay
macints &rd1, &wrt, t2, 1;
macints &rd2, &wrt, t2, 3; was this your intention? or it should be 2?

-- just ignore my post if i'm out of subject (sure, i understand that this was a testing/educational code and it shouldn't be ideal)

Maddogg6 · Feb 7, 2006, 05:43 PM

Quote:

Originally Posted by Max M.

there's some small issue also (if i'm not mistaken):
macints t2, 0, 2, delay;
macs &rd2, &rd1, ad1, t2;

->when 'Delay' fader is above .5 (50%) - it doesn't anymore change t2 (because of saturation - t2 always = 1 when delay > .5; ... t2 just can't be > 1)
Was that your intention? (delay control still affects rd2 though - since rd1 still changes)
If not (e.g. if non-linear behavior of the second delay is not your goal) then you could just reorder some operations a bit... like that maybe:

Code:

macs    &rd1, &wrt, ad1, delay;
macs    t2, 0, ad1, delay;
macints &rd2, &rd1, t2, 2;

or (more clear to see what the code does actually)

Code:

macs	t2, 0, ad1, delay
macints &rd1, &wrt, t2, 1;
macints &rd2, &wrt, t2, 3; was this your intention? or it should be 2?

-- just ignore my post if i'm out of subject (sure, i understand that this was a testing/educational code and it shouldn't be ideal)

Very informative - Thanks Max...

I do hear longer delay trails on one side when delay slider is low.
When delay slider is higher - its more even - left to right - but be the 'unsaturated' t2 making this so when slider is below 50% as you pointed out.

Using the suggested changes isnt what I was looking for tho

with these changes it sounds like.

S ......DL...DR.....DL...DR.....

The inital delay is longer than than the delay between R&L - it still 'ping-pong' but it would be 'off' tempo if trying to get both delays to fall on logical beats if in 4/4 time. Its would seem to work with 3/4 time tho.

(with a 123 count)
delays seem to fall on 2 and 3. Skippng the 1. when delay slider is above 50.

With my errors before - I think the rd1 saturating gave illusion of more linearity.
Then making changes - while coding was getting more correct - I lost the linearity somewhere.

The alternative suggestion (to use 2 instead of 3) fixed the skip 1 count thing above.

Back to the class for me.... I may have to stay after class and clean the chalk boards for causing others confusions...

Thanks again Max - and St. Russ.

Russ · Feb 7, 2006, 11:36 PM

Thanks for the info Max. That explains the observed behavoir of the MACINTS instruction. That 'i' option should prove handy. Are there any other such things in Dane (i.e. is there one to specify that it should be treated as a fractional number?)?

@Maddogg6, sorry I didn't pay close attention to the numbers, and looked more at the code, so I missed that saturation. There are a few ways to get around that and still get the same result.
i.e. Instead of multiplying delay * 2, multiply the result of the first (read address) calculation by 3.

Maddogg6 · Feb 8, 2006, 12:21 AM

@Russ - no problem, you've been very helpfull..

The updated code in my first post acts as I was expecting.

Feb 7, 2006, 05:44 AM	#1
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	Ping Pong delay Ok - so I re-grew some nerves and decided to make a delay algo that I meant to be the outcome, instead of blindly 'stumbling' upon anything.. So - IT WORKS! -well - it sounds like a ping pong to me. Code: ; xtramsize 36001; ; Registers output Out1, Out2; input In; control level= 1, feedback= .5, delay= .25; static t1, t2, ad1=0x1770000; ad1 = 12000 * 0x800 ; Then we set up the WRITE points xdelay write wrt at 0; xdelay read rd1 at 1; xdelay read rd2 at 12002; ; Lets make sure the INPUT not used more than once macs t1, In, 0, 0 ; ; Now we adjust the delay length by adjusting the RD points macs t2, 0, ad1, delay; macints &rd1, &wrt, t2, 1; macints &rd2, &wrt, t2, 2; ; Send (input + (delayedlevel)) to output macs Out1, t1, rd2, level; macs Out2, t1, rd1, level; ; Add criss-cross feedback to delay lines macs wrt, t1, rd2, feedback; end I have a question tho... If I change the last line (feedback) to macs wrt, rd1, rd2, feedback everything goes silent... why is this... a short answer is fine - I just don't understand, because the rd2 is used..?? Last edited by Maddogg6; Feb 7, 2006 at 05:48 PM. Reason: Fixed code to be correct*

Feb 7, 2006, 06:00 AM	Thread Starter #3
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	Well - 36001 - would make more sense... Im doubling the second line. Code: ; Now we adjust the delay length by adjusting the RD points macs &rd1, &wrt, ad1, delay; macints t2, 0, 2, delay; Double delay size macs &rd2, &rd1, ad1, t2; edit: corrected typeo - Last edited by Maddogg6; Feb 7, 2006 at 07:05 AM.

Feb 7, 2006, 07:37 AM	#21
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	Well it is not necessarliy a matter of everyone is using hex (I generally do), it is more likley that they are posting the microcode dump, instead of the source, and the dump shows the numbers in hex. As for the whole matter with the X param of a MACINTS instruction can be either, that is pretty confusing, and I am not really sure how we are supposed to let the processor know what we meant it to be, so I generally try to avoid it (you do not have to multiply 2 integers together all that often), and when I have to do it, I verify the results are what I intended. Last edited by Russ; Feb 7, 2006 at 07:44 AM.

Feb 7, 2006, 01:59 PM	#24
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	macints t2, 0, delay, 2; macints t2, 0, 2, delay; these are equal actually... normally, X and Y operands are fully swappable in macint* instructions (in both cases Dane is able to understand that 2 is integer, since 2 can’t be valid fractional) The only exception would be if 1 is used: macints t2, 0, delay, 1; macints t2, 0, 1, delay; in that case the second instruction goes wrong - Dane treats X = 1 as fractional 1. When the value of constant is ambiguous (1 can be both valid integer and valid fractional) - Dane (for macint* instr.) simply treats X as fractional and Y as integer (this is Dane's feature/issue and not the property of processor) the one can use 'i' suffix to avoid ambiguity: macints t2, 0, 1i, delay; does what is expected >but I DO see everyone using HEX NO! this is illusion forced by kX Editor. Note that when you click 'Edit' in kX DSP you typically see disassembler listing - not a source code! (and hex numbers are there for two reasons: 1. to ensure that listing produces binary equal code when compiled back 2. just to keep disassembler 's code simple). How do you think does it really make sense to write macsn r, 0x5b22d0e4, x, 0x7fffffff instead of macsn r, 0.712, x, 1 ? Although sometimes the hexs do the trick if they look less ambiguous (0x1 instead of 1 (don't forget about 1i)) or just more clear (0x800 instead of 2048) ----- there's some small issue also (if i'm not mistaken): macints t2, 0, 2, delay; macs &rd2, &rd1, ad1, t2; ->when 'Delay' fader is above .5 (50%) - it doesn't anymore change t2 (because of saturation - t2 always = 1 when delay > .5; ... t2 just can't be > 1) Was that your intention? (delay control still affects rd2 though - since rd1 still changes) If not (e.g. if non-linear behavior of the second delay is not your goal) then you could just reorder some operations a bit... like that maybe: Code: macs &rd1, &wrt, ad1, delay; macs t2, 0, ad1, delay; macints &rd2, &rd1, t2, 2; or (more clear to see what the code does actually) Code: macs t2, 0, ad1, delay macints &rd1, &wrt, t2, 1; macints &rd2, &wrt, t2, 3; was this your intention? or it should be 2? -- just ignore my post if i'm out of subject (sure, i understand that this was a testing/educational code and it shouldn't be ideal) Last edited by Max M.; Feb 7, 2006 at 02:53 PM.

Feb 7, 2006, 11:36 PM	#26
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	Thanks for the info Max. That explains the observed behavoir of the MACINTS instruction. That 'i' option should prove handy. Are there any other such things in Dane (i.e. is there one to specify that it should be treated as a fractional number?)? @Maddogg6, sorry I didn't pay close attention to the numbers, and looked more at the code, so I missed that saturation. There are a few ways to get around that and still get the same result. i.e. Instead of multiplying delay * 2, multiply the result of the first (read address) calculation by 3. Last edited by Russ; Feb 7, 2006 at 11:45 PM.

Feb 7, 2006, 05:52 AM	#2
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	It looks pretty good, but your xTramsize is bigger than it needs to be (you probably only need a size of 24001). <edit> As for your question, it goes silent because you are never writing any data to the delay line that way (i.e. you can't get output if you do not add input).

Feb 7, 2006, 06:03 AM	#5
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	You are right, I did not see that line (glanced over it to quick I guess). Good job. Damn speed reading course! ROFL

Feb 7, 2006, 06:04 AM	Thread Starter #6
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	Nevermind...

Feb 7, 2006, 06:08 AM	#7
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	No, the xDelay write intruction just defines a write pointer. If anything, it writes a 0.

Feb 7, 2006, 07:06 AM	Thread Starter #10
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	But - the code is correct then - right?

Feb 7, 2006, 07:13 AM	#12
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	Doh, spoke too soon. Just a couple things: What are you trying to do here? : macs t1, In, 1, 0 ; 1 * 0 = 0 Why not just use: macs t1, In, 0, 0 ; Maybe it is just a typo? Also, here: macints t2, 0, 2, delay; Double delay size You should swap the X and Y param, as delay is a fractional number, and 2 is an integer.

Feb 7, 2006, 07:15 AM	Thread Starter #13
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	that would equal - t1 = in - Im making sure I dont reuse that input register... no?

Feb 7, 2006, 07:16 AM	Thread Starter #14
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	so its t1 = IN + (1*0) = IN Isnt it the same?

Feb 7, 2006, 07:25 AM	Thread Starter #17
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	confirmed: Either can be integers... Its prolly bad form tho...

Feb 7, 2006, 07:27 AM	#18
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	The X param can be either (which means you should enter the number in hex so that Dane is sure of your intention), but the Y param is always an integer, and as 'delay' is not an integer (it is a fractional number), you do not want it to be the Y param. i.e. Instead of muitplying 0.5 * 2, it is multiplying 1073741824 * 2.

Feb 7, 2006, 07:59 AM	Thread Starter #22
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	It doesnt seem to make a difference: macints t2, 0, 2, delay; Double delay size sounds the same as macints t2, 0, delay, 2; Double delay size Thus Im thinking the the number format going into that indtruction is indicated.. Maybe the DSP's CCR - not sure what flags are in there. But it could make sense.

Feb 7, 2006, 08:22 AM	#23
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	In this case it ends up with the same result, but it is doing so by using some undocumented feature. I think maybe if the integer is above a certain number, that it treats it as a fractional number instead. And in this case, because delay is defined elsewhere, it knows that it is supposed to be a fractional number. Had you entered those numbers in manually (in decimal) however, you would have gotten different results. The Y paramater would have been rounded off to the nearest integer value (1).

Feb 8, 2006, 12:21 AM	Thread Starter #27
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	@Russ - no problem, you've been very helpfull.. The updated code in my first post acts as I was expecting.