Reverse phase

[trogluddite]

Ah yes, thankyou for the correction.

In this particular case, infuzion is perfectly right - because the multiply is such a teeny weeny device, the CPU saving is cancelled out by the CPU needed for a selector that is carrying audio. And when switched on, you have the CPU of a multiply AND a stream selector.
So actually, for this application, version 2 (switching the green) is always the better solution, because the switch never carries audio.

As he says, the general principle is right - when switching a larger chunk of 'effect', the "turned off" CPU saving would be bigger, so using the stream selector would then be economical.

PS) It may not be just a matter of how newer CPU's report clock cycles. With newer chips it becomes almost impossible to work out how many operations are able to be run 'out-of-order' (or how many variable values will be subject to a cache miss) - so adding together the cycles of individual primitives is unlikely to ever be a reliable guide to the CPU usage of a complete chain.
Choosing primitives with the lowest CPU hit will still give you the best probablity of a mean, lean schematic, but only real-world testing will really tell you just how efficient your design really is.

[infuzion]

PS) It may not be just a matter of how newer CPU's report clock cycles. With newer chips it becomes almost impossible to work out how many operations are able to be run 'out-of-order' (or how many variable values will be subject to a cache miss) - so adding together the cycles of individual primitives is unlikely to ever be a reliable guide to the CPU usage of a complete chain.

Atom CPUs run in order IIRC, aside from simultaneous operations that happen to be next to each other.

[MegaHurtz]

Altho there would not be a better way of estimating cpu usage, its simply the loss thats made by decimating the units to fit a 1/100th scale. so its actually the user who is not equipped to estimate the numbers with enough resolution.

Given a good digital signal processor wont miss at all. And its mostly ram that would slow a cpu down.
There would also be arguments not to include windows into the chain, (or very little) for better overall performance, given the nature of Synthmaker the loss of letting strings in and out of windows will be tactile. Wich i personally reckon to be a good thing for music. For example a coded version of a midi in transform will yust be feeling faster hands down.

[oddson]

I'm confused...

Strangely, due to how newer CPUs report CPU usage, if you connect both the Selector & Multiply together, it reports only 3 cycles. I think it should be more like 4 or 5 due to how SM works... but you get the idea. Also, IIRC, Selectors in older CPUs like my Athlon64, the Selector took about 6 cycles, so using just the multiply is faster CPU.

Does a selector running audio through it really add to CPU usage on an ongoing basis if there are no green triggers coming into it?

When the switch [feeding the selector passing audio] changes , SM has to make changes to the way that the plugin program runs - and this can sometimes make modules in the schematic reset themselves, and notes playing on your synth might get switched off.

Does a selector running audio through it really cause the audio process to reset?

[infuzion]

I'm confused...

Strangely, due to how newer CPUs report CPU usage, if you connect both the Selector & Multiply together, it reports only 3 cycles. I think it should be more like 4 or 5 due to how SM works... but you get the idea. Also, IIRC, Selectors in older CPUs like my Athlon64, the Selector took about 6 cycles, so using just the multiply is faster CPU.

Does a selector running audio through it really add to CPU usage on an ongoing basis if there are no green triggers coming into it?

No, Selector/Multiplexor use CPU when they are in stream mode.

When the switch [feeding the selector passing audio] changes , SM has to make changes to the way that the plugin program runs - and this can sometimes make modules in the schematic reset themselves, and notes playing on your synth might get switched off.

Does a selector running audio through it really cause the audio process to reset?

When the Selector/Multiplexor changes/is switched, it forces an ASM recompile of all the audio code. This in turn causes the audio process to reset. I should test if the same Int value is sent, if that causes a recompile also...

[oddson]

Selector/Multiplexor use CPU when they are in stream mode.

Right... I guess it has too. Never thought it through before.

When the Selector/Multiplexor changes/is switched, it forces an ASM recompile of all the audio code. This in turn causes the audio process to reset...

First part makes sense to me... but I'm not sure exactly what "This in turn causes the audio process to reset" means in practice.

It once meant that all audio buffers were interrupted as everything reset... but that was fixed years ago.

...this can sometimes make modules n the schematic reset themselves, and notes playing on your synth might get switched off.

I guess this is the part I'm puzzled by. Does this happen... shouldn't it happen consistently and not 'might' and 'sometimes'?

[trogluddite]

'might' and 'sometimes'?

Sorry - Partly deliberate vagueness because I have so little experience of using poly, as I have never been a synth builder - and partly me being a little haphazard in my choice of words!
For mono/mono4, have found that the effect depends on whether there are stage(0) sections anywhere. If there are not, then following the change, all variables keep their former values. If there are stage(0) parts, then they are the first thing to run following the change, with whatever consequences are programmed in that part of the code.
I have not tested this exhaustively with primitives - by the time I was aware of the "problem", I was already in the habit of using code/assembly for pretty much all of my stream processing. I would imagine that the only primitives likely to have stage(0) behaviour would be those that reserve memory for buffers (e.g. mem's).
I guess I should have phrased t more like...
"If you find you get a audio glitches when switching selectors, then here is one likely cause..." - I didn't really mean to give the impression that stream selectors should always be avoided.

[oddson]

Got it.... stage(0) executes with stream type data.

FYI - I tested with poly... stage zero does not execute when the selector changes.

capture.png

Thanks guys.