DSP Robotics Support

While I actively "try" to avoid my plugin for a while.

Maybe some of you Flowstone-ninjas can enlighten me on these questions regarding CPU costs...?

Versus statements:

--> 10 multipliers in green vs 10 multiplications in Ruby?

--> 10 poly multipliers vs 10 multiplications in DSP?

--> 3 DSP with 10 multiplications each vs 1 DSP with 30 multiplications?

--> 1 division in poly vs "if applicable" 1 multiplication in poly (I know divisions cost more but is it a dealbreaker)

--> How do you FS/math-ninjas handle functions like sin() in poly (they are pretty sluggish in green also of course)? I'm not a math guy at all! I end up in overengineered exponential functions (and inversions of them) mixed with linear, only to get reallt sh*tty approximations of what I wanted Are you using DSP only for this?

Note on the versus statements:
I understand that dividing into separate code parts is at a cost itself. I'm just curious of how much I loose or gain with one, or the other...

And... lastly...

--> So DSP is recompiled into ASM?
But unoptimized, contrary to for example MV's highly optimized ASM's.
If poly prims are DSP that compiles to ASM? Are they to be considered separate DSP code parts that come at the same cost as connecting the same operations using separate DSP's? This relates a bit to the versus above on poly.

Newbie question overload here. Sorry

Hi, some response,

- Ruby or green is faster because it doesn't work on 44100 or more sample per second.
(Maybe if you force ruby to go to higher frequency it could cost cpu, i doesn't try this so much)

- Poly could be more cpu because if you play more than 4 note it need to have one more instance.
4 notes is suppose the same as blue, 5-8 is like 2 blue code, 9-12 is like 3 blue code, ...
> But the blue to poly process could also cost some cpu. (not so much)

- Normally one dsp with 30 multiplication will be faster.. I did not test it so much but almost sure..

- division cost a lot more, i always try to avoid them.. If it come from green you could make do 1/x in green then multiply with it.
(In my current project i try to hop some division then lowpass/smooth the result. it's a little experimental but i get better cpu)

- For sin function, i never get better approximation than the one from Martin Vicaneck !)
But depending of the frequency you want to achieve you could sometime use lighter process.
> But it will not be so much less cpu..
( i tried some approach here : viewtopic.php?f=4&t=94114)

- Not sure for the prims. They seams sometime optimized in asm but they tend to read the memory in a not so much optimized way in some case. Most of time it's possible to do faster in asm, but for example the dezip prims seams to be the faster code possible. (or you loose precision for not visible gain unless using 1000000 dezip..)

Thank you Tepeix!

- Ruby or green is faster because it doesn't work on 44100 or more sample per second.
(Maybe if you force ruby to go to higher frequency it could cost cpu, i doesn't try this so much)

Hmmm... But which is faster, or do they have the same execution time do you think?

- Normally one dsp with 30 multiplication will be faster.. I did not test it so much but almost sure..

That's touching at some of what I wan't to know. Since I am like... on a 1st grade level at math i'm... for example feeding multipliers to alter pitches and such. More like a electrical switching circuits than efficient code. I feel much more at home with logic circuits within electronics, that's what I dealt with in school. They are somewhat visual, than abstract code... after all.
But these debaucheries doesn't seem cost me measurable cpu, but I know they add to the whole cpu cost in the end. So... I might as well start micro-optimizing later on.

- For sin function, i never get better approximation than the one from Martin Vicaneck !)
But depending of the frequency you want to achieve you could sometime use lighter process.
> But it will not be so much less cpu..
( i tried some approach here : viewtopic.php?f=4&t=94114)

That Martin is one optimized dude!

- Not sure for the prims. They seams sometime optimized in asm but they tend to read the memory in a not so much optimized way in some case. Most of time it's possible to do faster in asm, but for example the dezip prims seams to be the faster code possible. (or you loose precision for not visible gain unless using 1000000 dezip..)

Also interesting, but expected I guess...
How do you guys even gauge their behaviour, perfomance and memory usage?


There's always room for more contemplation... anyone else have ideas surrounding my statements?

I can’t really answer your questions with any certainty. However, are you aware of hopping?

Any DSP code which doesn’t need to operate at audio sample rate can be hopped to save CPU. Not much per code block maybe, but it can add up. For example, envelope generators can do hop(16) without any issues. If you have several it should add up and make a difference.

However, are you aware of hopping?

Yep, I remember trying it on something after reading some discussions here...
I increased the hop() until failure of a "part" of a DSP just to see how the output correlated with the non hop:ing part.

Haven't had much to test on though, since I know so little DSP at the moment.
I suppose I could check how many samples I can skip at the max 80hz of my LFOs (don't ask me why 80... just thought it borders on being an audio oscillator itself around 60-80). Maybe save a little bit of time on my pitch shifters for example.

Then of course there's my panning function which is an overengineered thing of marvel. Amazed that it even worked. 4 linear functions with adjustrable floor and ceiling... all made up of prims. Probably easy for anyone of you but that was a challenge for my peanut. Rudimentary but It works well enough, also with portamento.

I persist calling myself newbie. And I am... I knew very little about FS and know even less about audio and audio processing.
I'm better suited for creating simple graphics. Actually created an entire playable android 3D-piano in Unity once, with wav-samples and my own envelopes, metronome, recording capability and infinity knobs and everything... using only that mono-tool and C#. Somehow, this is equally hard crazy

The nested if-statements in my eventhandling for the multi-touch on android was... "special"... as a mother would call their ill-behaved kids. But It even handled velocity, held keys and glissando all at the same time, on dual rows of keys, like an organ (but no pipes on it Spogg just a little bit of the Unity built in filter to emulate some dampened strings)

But, in Unity I could attach a timer to my different codeparts and gauge exactly how many ms they consumed... I haven't worked with FS 3.09 only used it for exports but maybe there are more options for benchmarking in that version I don't know.

R&R wrote:--> 10 poly multipliers vs 10 multiplications in DSP?

As Tepeix pointed out, that depends.

In poly, voices are assigned to SSE channels, so if you play up to 4 notes simultaneously, CPU load will not change as all voices will be processed in parallel. Once you exceed 4 simultaneous notes, a second processing instance will be created, which of course increases CPU load. Next CPU increase with more than 8 voices and so on.

In DSP, it is up to you plugin developer to make use of SSE. If you do nothing about it, you are basically using only the rightmost (in UK: leftmost) lane of a 4-lane freeway. In that cse, 10 DSP multiplies is about the same CPU as 10 poly multiplies with up to 4 notes playes simultaneously.

R&R wrote:--> 3 DSP with 10 multiplications each vs 1 DSP with 30 multiplications?

It depends (again). Multiplication is really such a fast operation that most of the execution time is actually spent on loading and unloading data. At the end of the day it very much depends on algorithmic context, how well you can pipeline stuff.

R&R wrote:--> 1 division in poly vs "if applicable" 1 multiplication in poly (I know divisions cost more but is it a dealbreaker)

Division is about equivalent to 4 multiplies, so it is not really devastating but if you can avoid it, why not.

R&R wrote:---> How do you FS/math-ninjas handle functions like sin() in poly (they are pretty sluggish in green also of course)? I'm not a math guy at all! I end up in overengineered exponential functions (and inversions of them) mixed with linear, only to get reallt sh*tty approximations of what I wanted Are you using DSP only for this?

If you only need to calculate math functions when the user turns a knob, use green (and some cheap smoothing). For other purposes like modulation, envelopes etc. you want to use DSP (or ASM). Some functions have been implemented, maybe yourd is among them
download/file.php?id=13260

implemented, maybe yourd is among them
download/file.php?id=13260

LOL^2

In DSP, it is up to you plugin developer to make use of SSE. If you do nothing about it, you are basically using only the rightmost (in UK: leftmost) lane of a 4-lane freeway. In that cse, 10 DSP multiplies is about the same CPU as 10 poly multiplies with up to 4 notes playes simultaneously.

Hmmm... just to make sure I understood, you mean that... If (and every time) I route a poly connection to a DSP code-snippet, i'm basically detaching myself from the 4-lane SSE optimization, "unless" I write my DSP accordingly. So the stream operations inside every DSP is treated/calculated as separate intructions (or non optimized) by CPU then.

But what happens at the DSP output? I guess the streams are merged again for 4-lane operations?

I wonder if... If this is the cause I had to create a really annoying 3 x DSP split for my panning module... or maybe the cause is some natural stream handling I not up to speed on yet.

Thanks for the info!
Always more fun to walk the path than being carried by helicopter to the top of the mountain, and learning nothing...

Ha... so I might be better of switching back to some of my first solutions using polyint as switches then since they are 4-lane optimized, and my DSP that replaced them is not. Until I get a grip on DSP, if ever...

Oh god don't tell me some poly prims aren't SSE optimized under the hood?!

R&R wrote: ... Oh god don't tell me some poly prims aren't SSE optimized under the hood?!

I think Martin could give a better answer, but anyway…

Everything in poly white will automatically utilise SSE without you having to do anything. I believe the exception is in ASM coding where you can have more control of the 4 “lanes”.

In the mono blue world you can use pack and unpack to take advantage of all 4 lanes. So for example you could have 1 filter which could be turned into 4 filters each with its own cutoff and resonance. These could be wired in series or parallel and all for the CPU cost of just one filter.
If you look inside my SIM-GUZHENG you’ll see what I did to make use of mono4 (pack-unpack) for the sound generators. I have 24 “strings” but only 6 string generators, so I get 24 strings for the price of 6, all running in mono4 blue. It was important for that instrument due to the need to play huge sweeping glissandos which on a poly system would quickly exceed a hundred voices due to the longish envelope times (I did try this at first just to see!).
You’ll also see that I got 4 formant filters for the price of 1!