ODD's and EVEN's in ASM

[martinvicanek]

In the "bue" domain, stage 0 is executed once at the beginning and then we usully work with stage 2 to execute at every sample. We may make use of 4 SSE channels being initiated and executed in parallel, if we wish.

In the "white" poly domain, however, we face the problem that each instance of a DSP or ASM block assigns up to 4 notes to the 4 SSE channels. Now each note may start at a different time, but the stages process all four SSE channels in parallel. Therefore, stage 0 can at most initialize the first of four notes, but not the other three.

Trog discovered back then that ecx starts at zero at each new note (and then increments by 1 every sample), so this can be used to init each note. However, you need to know which of the four SSE channels to init. You probably do not want to disturb a running note. It is tricky!

[martinvicanek]

Has someone already written? Or attempted to write ASM versions of the two DSP's found in the Toolbox S&H?
These short DSPs maybe not taxing on the CPU but ASM's are always sweeter when using alot of them...

Here you go. In the ASM I ditched the redundant variable "current" and some unnecessary comparisons that were present in the DSP code.

S&H by Frequency

Code: Select all

streamin in;
streamin freq;
streamout out;

float ramp=1.0;
float F1=1.0;

movaps xmm0,in;
movaps xmm1,out;
subps xmm0,xmm1;   // in - out

movaps xmm2,ramp;

movaps xmm3,F1;
cmpps xmm3,xmm2,2;   // 1 <= ramp
andps xmm0,xmm3;   // (in - out)&(ramp >= 1)
addps xmm1,xmm0;
movaps out,xmm1;

andps xmm3,F1;
subps xmm2,xmm3;   // ramp within 0 to 1
addps xmm2,freq;   // incremented ramp
movaps ramp,xmm2;

S&H By +ve Zero Cross

Code: Select all

streamin in;
streamin control;
streamout out;

int greater=0;   // bool
float zero=0;

movaps xmm0,in;
movaps xmm1,out;
subps xmm0,xmm1;      // in - out

movaps xmm2,control;
cmpps xmm2,zero,5;      // control >= 0
andps xmm0,xmm2;

movaps xmm3,greater;   // last control >= 0
andnps xmm3,xmm0;
addps xmm1,xmm3;
movaps out,xmm1;

movaps greater,xmm2;

[Tepeix]

That's strange, but the random stage 0 seams to works, maybe a change in version of flowstone ?
I make this little test schematic with random note. It seams to trigger fine.
(to test i use the keyboard + the virtual keyboard to have enough voice)

[R&R]

I'll try and wrap my head around this

Therefore, stage 0 can at most initialize the first of four notes, but not the other three.

Hmm...
Might explain why I have noticed 1 sample glitches when putting together/testing some stuff in separate schematics, but when in my synth it's just "gone". Either I don't test correctly when implemented in the synth, or, my way if using polytrigger "as is in the actual synth" eliminates it. Might investigate this further later on...
Since there might be unwanted behaviour that i'm not noticing probably alot of it... LOL

Thanks both of you... this is really something to digest.

Here you go. In the ASM I ditched the redundant variable "current" and some unnecessary comparisons that were present in the DSP code.

Saving my peabrain from headaches once again Not learning much ASM this way, but i'm more than happy I can dodge trying to convert these ones. Thanks Martin!
Going to try these out soon!

[R&R]

Edit:
FS and the ZDFs put up a little fight against me and my schematic. But MacGyvers spaghetti won this round...

Second try. Updated version of my newbie synth works hopefully.

As previously mentioned in removed post key updates are:
* 2x combinations of MVs ZDF filters... inspired by testing Tepeix tripple pole ZDF
* S&H mode for some knobs... idea came from Spoggs sims to add this feature

Finally got to justify adding fancy neon circle around my cutoff

Anyways...

Happy new year!

[R&R]

Looking at finding some additional use of MVs ZDFs in my plugin. Maybe they can act as crude EQs if my synths F2-filter is unselected/free for use... Since I won't be adding a dedicated FX or EQ section to the plugin. Too advanced for me...

Combo_filters.jpg (82.75 KiB) Viewed 9094 times

Super efficient low/high shelfs by just adding outputs together?
Anyone know if I can sqeeze a little extra (due to being 2nd order) out of the ZDF's by overshooting cutoffs?

Iow is it safe to feed a cutoff slightly larger than 1 into these ZDF's? They go bananas at around 1.04< and then cuts out. Some kind of denormalization or a more regular division issue dependant of a given samplerate perhaps?

Math looks straight forward when looking at MVs original DSPs, but still I have no clue... Math Like "gazing into the void beyond" for me
I only need to feed a cutoff of <1.03, but don't know if it might break for some reason.

Btw
Thanks again Martin,
made use of your S&H by frequency atleast 27 instances for the moment, of which 18 might be used simultaneosly. Likely be adding some more later...

[martinvicanek]

Cutoff = 1 corresponds to Nyquist frequency, which is half the sampling rate. Standard bilinear mapping treats Nyquist as infinity, so you can't go beyond.

I have designed and implemented matched filters which avoid cramping at Nyquist and even allow cutoffs beyond Nyquist. Those won't modulate well, they are meant for static filtering.

Hope that helps?

[R&R]

Cutoff = 1 corresponds to Nyquist frequency, which is half the sampling rate. Standard bilinear mapping treats Nyquist as infinity, so you can't go beyond.

...

Hope that helps?

Thanks for explaining, helps alot...

It wasn't what I was hoping for but kind of expected this to be the case that any cut value beyond 1 is a no go. The ZDFs seem very slimmed for performance.

I'll see if I can just add an amp reduction on the filter outputs near fully closed/open on these 2x and shelf combos in my plugin. I don't think my synth is nice to the filters, so any main filter have to handle modulation extremely well without breaking

I have designed and implemented matched filters which avoid cramping at Nyquist and even allow cutoffs beyond Nyquist. Those won't modulate well, they are meant for static filtering.

I do use some of your matched filters I think some ended up inside the dist module...

Hmmm... maybe... I might be able to use a matched 1-pole set beyond nyquist to statically subtract a tiny bit of output. Might not cost more than a funky curve/mapping that reduces filter output amp...

[R&R]

Jumping between threads... just like I've broken my own original plan a whole lot by adding the option-dropdown to begin with.
What a letdown!

Might as well keep going.

Still not sure about naming...

Screenhot_v0.51.jpg (69.54 KiB) Viewed 8931 times

The "P1 Decay..." dropdown-items? Should I call it decay, strike or exciter? It's just an oscillator for a (decay or gated) burst to get a feedback loop ringing.
Just by this screenshot what would be the most clear naming, for drawing "an only visual" conclusion of what the function is...?

[R&R]

Jumping between threads... just like I've broken my own original plan a whole lot by adding the option-dropdown to begin with.
What a letdown!

Might as well keep going.

Still not sure about naming...

Screenhot_v0.51.jpg

The "P1 Decay..." dropdown-items? Should I call it decay, strike or exciter? It's just an oscillator for a (decay or gated) burst to get a feedback loop ringing.
Just by this screenshot what would be the most clear naming, for drawing "an only visual" conclusion of what the function is...?

As mentioned had to scrap that Osc Module for now sounded completely different at different samplerates. Didn't know it was called this but apparently a Karplus-Strong circuit as shown in Martins interpolated delay demo.
I suspect the issue with my Osc Module is likely all interpolation differences adding up together ending up as different sum/output. Have to learn more I think

Anyways...

As this thread begun as an ASM question... i'll return to basic ASM question again

This is some poly-spaghetti run through the signal analyzer:

Code: Select all

movaps [ebp+4208],xmm6;          // 0f 29 b5 70 10 00 00
movaps [ebp+4224],xmm7;          // 0f 29 bd 80 10 00 00
movaps xmm0,[ebp];               // 0f 28 85 00 00 00 00
mulps xmm0,[ebp+12640];          // 0f 59 85 60 31 00 00
movaps [ebp+12624],xmm0;      // 0f 29 85 50 31 00 00
movaps xmm0,[ebp];               // 0f 28 85 00 00 00 00
mulps xmm0,[ebp];                // 0f 59 85 00 00 00 00
movaps [ebp+12768],xmm0;      // 0f 29 85 e0 31 00 00
movaps xmm0,[ebp];               // 0f 28 85 00 00 00 00
mulps xmm0,[ebp+12768];          // 0f 59 85 e0 31 00 00
movaps [ebp+12752],xmm0;      // 0f 29 85 d0 31 00 00
movaps xmm0,[ebp];               // 0f 28 85 00 00 00 00
mulps xmm0,[ebp+12880];          // 0f 59 85 50 32 00 00
movaps [ebp+12864],xmm0;      // 0f 29 85 40 32 00 00
movaps xmm0,[ebp];               // 0f 28 85 00 00 00 00
maxps xmm0,[ebp+12992];          // 0f 5f 85 c0 32 00 00
movaps [ebp+12976],xmm0;      // 0f 29 85 b0 32 00 00
movaps xmm0,[ebp+12976];      // 0f 28 85 b0 32 00 00
addps xmm0,[ebp+13008];          // 0f 58 85 d0 32 00 00
movaps [ebp+12912],xmm0;      // 0f 29 85 70 32 00 00
movaps xmm0,[ebp+12912];      // 0f 28 85 70 32 00 00
mulps xmm0,[ebp+13024];          // 0f 59 85 e0 32 00 00
movaps [ebp+12896],xmm0;      // 0f 29 85 60 32 00 00
movaps xmm0,[ebp+12848];      // 0f 28 85 30 32 00 00
addps xmm0,[ebp+12864];          // 0f 58 85 40 32 00 00
addps xmm0,[ebp+12896];          // 0f 58 85 60 32 00 00
movaps [ebp+12784],xmm0;      // 0f 29 85 f0 31 00 00
movaps xmm0,[ebp+12752];      // 0f 28 85 d0 31 00 00
mulps xmm0,[ebp+12784];          // 0f 59 85 f0 31 00 00
movaps [ebp+12736],xmm0;      // 0f 29 85 c0 31 00 00
movaps xmm0,[ebp+12720];      // 0f 28 85 b0 31 00 00
addps xmm0,[ebp+12736];          // 0f 58 85 c0 31 00 00
movaps [ebp+12656],xmm0;      // 0f 29 85 70 31 00 00
movaps xmm0,[ebp+12624];      // 0f 28 85 50 31 00 00
mulps xmm0,[ebp+12656];          // 0f 59 85 70 31 00 00
movaps [ebp+12608],xmm0;      // 0f 29 85 40 31 00 00
movaps xmm7,[ebp+4224];          // 0f 28 bd 80 10 00 00
movaps xmm6,[ebp+4208];          // 0f 28 b5 70 10 00 00

26 movaps
7 mulps
4 addps
1 maxps


Same functionality but as ASM box run through the signal analyzer:

Code: Select all

movaps [ebp+4208],xmm6;          // 0f 29 b5 70 10 00 00
movaps [ebp+4224],xmm7;          // 0f 29 bd 80 10 00 00
movaps xmm0,[ebp];               // 0f 28 85 00 00 00 00
mulps xmm0,[ebp+12688];          // 0f 59 85 90 31 00 00
movaps xmm1,[ebp];               // 0f 28 8d 00 00 00 00
maxps xmm1,[ebp+12640];          // 0f 5f 8d 60 31 00 00
addps xmm1,[ebp+12656];          // 0f 58 8d 70 31 00 00
mulps xmm1,[ebp+12704];          // 0f 59 8d a0 31 00 00
addps xmm0,xmm1;                 // 0f 58 c1
addps xmm0,[ebp+12720];          // 0f 58 85 b0 31 00 00
movaps xmm1,[ebp];               // 0f 28 8d 00 00 00 00
mulps xmm1,xmm1;                 // 0f 59 c9
mulps xmm1,[ebp];                // 0f 59 8d 00 00 00 00
mulps xmm0,xmm1;                 // 0f 59 c1
addps xmm0,[ebp+12672];          // 0f 58 85 80 31 00 00
movaps xmm1,[ebp];               // 0f 28 8d 00 00 00 00
mulps xmm1,[ebp+12624];          // 0f 59 8d 50 31 00 00
mulps xmm0,xmm1;                 // 0f 59 c1
movaps [ebp+12608],xmm0;      // 0f 29 85 40 31 00 00
movaps xmm7,[ebp+4224];          // 0f 28 bd 80 10 00 00
movaps xmm6,[ebp+4208];          // 0f 28 b5 70 10 00 00

9 movaps
7 mulps
4 addps
1 maxps


If such is the case that custom ASM boxes are more efficient... it's of course a balance between "schematic readability" and "micro-optimization" in the end. But some confined modules/parts/pieces of spaghetti can easily be converted.

So... does this actually mean 17 less of those aligned move operation? Or is there just some compiler magic taking place inside FS that makes it unnecessary even bothering to convert as much spaghetti to ASM boxes as possible regarding reduction of movaps operations?