a question of hop()

[HughBanton]

I have a simple question about 'hop()'.

In DSP I might write e.g. hop(32){ // <my code> // }, which if then converted to Assembler would give me

Code: Select all

mov eax,ecx;
and eax,31;
cmp eax,0;
jnz end;
// <my code> //
end:

I understand how that works, by and-ing the sample counter (ecx) with 32, which creates a mask that's zero every 32nd sample. So <my code> runs only on samples 0, 32, 64 and so on.

However it has occured to me that if I have, say, two linked modules both set to hop(32) this presumably means that they will both run together on 0, 32, 64 etc.

But if I did this on one of them :

Code: Select all

mov eax,ecx;
add eax,5; //un-sync?
and eax,31;
cmp eax,0;
jnz end;
// my code //
end:

.. would that make this module run on samples 5, 37, 69 etc., thus shareing the load, reducing the log-jam a fraction?

Or am I making an embarrassing error ...

[adamszabo]

Interesting question. I dont think that would work, because it can only hop in multiplies of 2? So you wouldnt be able to hop even numbers. Someone could correct me if Im wrong

[tulamide]

CAUTION: I HAVE NO KNOWLEDGE ABOUT ASSEMBLER!

Having said that, "anding" numbers work quite like modulus, in which case adding something in front of the precedure won't change its behavior. It will still run on 0, 32, etc., but reach it earlier (in your example 5 samples earlier)

So to have it run later you'd need to subtract.

However, if this whole thing is bound to multiples of 2 (2^x), it won't work.

EDIT: Also, there is a delay prim, delaying by one sample. Wouldn't that help with your situation?

[martinvicanek]

I hate to disagree with the two gentlemen posters before me, but this time I think you err. Hop offset is perfectly possible as already pointed out by Trog (how I miss him). Refer to attached demo. You still hop at powers of two, though. (It is also possible to relax that restriction but at some higher CPU cost.)

[tulamide]

I hate to disagree with the two gentlemen posters before me, but this time I think you err. Hop offset is perfectly possible as already pointed out by Trog (how I miss him). Refer to attached demo. You still hop at powers of two, though. (It is also possible to relax that restriction but at some higher CPU cost.)

Well, I said it would work, only if the confinement is 2^x it wouldn't (so, when the actual result has to be a multiple of 2).

But, I don't see where you delay by 5?

Example1: 25 & 31 = 25 + 5 = 30 // The actual result is already at 30 although the counter is at 25. Zero is reached in 2 samples
Example2: 25 & 31 = 15 - 5 = 20 // The actual result is only at 20, although the counter is at 25. Zero is reached in 12 samples

Example2 would be a delay, while Example1 would be a lookahead, no?

[martinvicanek]

Yes,

Code: Select all

add eax,5

in the asm code would execute 5 samples earlier. You can likewise delay execution by

Code: Select all

sub eax,5

or

Code: Select all

add eax,-5

Refer to the spikes in the cycle meter display in my demo.

[HughBanton]

Good to know that I'm getting things about right . Even if Trog already did this years ago .. and also picked the number '5'. (Coincidence, honest guv!)

I presume, then, that the following is feasible as well, in order to delay the first time <my code> is executed until the 251st sample. ~5ms at 44.1kHz. (Only for where that's both acceptable / useful / desirable of course).

Code: Select all

mov eax,ecx; // ecx is sample counter
cmp eax,250;
jl wait; // wait until 251st cycle
add eax,5; // un-sync by +5
and eax,31; // hop 32
cmp eax,0;
jnz end;
//
// <my code>
//
end:
wait:


So as I see it <my code> should then only run on samples 251, 256, 288, 320, 352 .. Or close to those numbers anyway!

[trogluddite]

I presume, then, that the following is feasible as well

Yes (in principle, I haven't checked your code) But there's one small caveat. The counter is a 32-bit unsigned integer, and when it reaches the maximum possible value, it will loop back around to zero, and the startup delay will happen again. The interval between zero-crossings will be...

(2 ^ 32) / sample_rate (seconds)

For 44.1kHz audio, that works out at about 27 hours. If you burn the midnight oil that much, you might notice a glitch now and then (but then, you might anyway if your studio sessions are that long!)

Trog (how I miss him)

Hence I had to respond to this thread! Thankyou, martin, I'm really touched!