problem with certain triggers

trogluddite · 29 Apr 2012

Yes, that is perfectly normal.

Any change to stream routing - even parts which seem disconnected - will cause SM to re-compile the code for the entire schematic. This is for two reasons...

1) CPU saving - when a module (or chain) has no output connected, that part of the code doesn't run. But SM has to determine which parts are on or off, and then alter the code slightly so that it jumps over the "dormant" parts.

2) Execution Order - when switching elements, SM has to re-assess the order in which the currently active modules are processed. This to ensure that a module is not processed before those that feed it with inputs, otherwise the audio would not flow through the schematic.

As the number of modules, and complexity of connection increases, so does the difficulty of analysing the correct processing order for the network - and hence a big spike in CPU activity (hard to see on a CPU meter because it is so brief). The glitches are often made much worse because a re-compile will always force code and assembly modules to run stage(0) - which can cause the reset of counters etc. This is often desirable - when modules "awake" from the CPU-saving state they do quite often need buffers flushing etc, to enter a known start state. It is possible to design stage(0) routines that are more benign - I did that just today with the Delays in the Trogz toolkit. By default, preset changes also cause a re-compile - this can be turned off, but if a preset changes the position of stream routing, a re-compile will still happen anyway.

This is a price we pay for SM's wonderful user interface. The re-compilation is a reflection of the complexity of turning the on-screen "flowchart" into executable code - all the things that are hidden from us in order to make SM a more comfortable environment.

SOLUTIONS This depends a lot on whether you can tolerate increased CPU load. It is possible to use gain control etc. to switch signals, so that there is no re-routing of selectors etc. - but you will lose SM's automatic CPU saving features. In effect, the whole schematic must be "always on" - even those parts currently not in use. You can get around the loss of CPU-saving to a degree - but only by using assembly, as the code module does not allow jumping over blocks of code (except for hopping). There is another advantage to this approach. Modules which are asleep remain locked in "stasis" - all variable values and buffers are remembered. So switching an oscillator in or out of circuit will normally have an effect on its phase (its clock no longer ticks when disconnected). In contrast an "always running" design retains its timing even when not contributing to the sound. If that is too extreme, you can still ease the problem by combining networks of primitives into simple code blocks, and making many small code blocks into bigger ones. In effect this does some of the job of 'compiling' the schematic, as the lines of code make execution order explicit - making less work for SM to do when it analyses the network of links.

In practice, I would mix the "always on" approach with the conventional selector/multiplex method - according to where CPU saving is most needed, or where the worse glitch problems are.

tester · 29 Apr 2012

"Always running" will not work correctly at that complexity or at least not on all computers (even if a part of schematic is running). Count: 12-16x stereo units, each has stereo AM and stereo FM, and there are 10 other stereo modulators per parameter of both - units and modulators. I'm not saying that all play at once, but they are/should be present. Preset manager is simplified - only load/save and only 1 program (at least for testing) inside - just finished. I send you the template of where am I right now, so maybe step by step we can figure out how to make it run correctly. For phase reset I have a manual resync button 😉 I redesigned gui (lot of things are removed, everything is vector now), so I use copy-gui method this time - at least for testing.

Thanks for engagement and patience.

oddson · 30 Apr 2012

trogluddite wrote: Any change to stream routing - even parts which seem disconnected - will cause SM to re-compile the code for the entire schematic. This is for two reasons...

😕 ?

That was once true and remained true for the multiplexer for long after it was fixed in the selector but it's not the case and hasn't been for a LONG time.

Or perhaps your speaking of something else?

trogluddite · 30 Apr 2012

I beg to differ....

The switch-over may have been made more benign for certain modules etc., by changing their stage(0) behaviour, but the re-compile, force to stage(0) is still there in general.

treacherousumbrella · 30 Apr 2012

would have to agree, have noticed unpleasant glitches coming from one part of a schematic when a switch in an unrelated area is toggled. Definitely still an issue so tend to use ASM and jnz where possible instead of selectors

oddson · 30 Apr 2012

I see... it's stage zero that's affected but audio processess are not necessarily interrupted.

I'm not at my SynthMaker machine so I haven't seen your example yet.

trogluddite · 30 Apr 2012

oddson wrote: I see... it's stage zero that's affected but audio processess are not necessarily interrupted.

Yes, my guess is that the improvements made previously were probably some re-programming of stage(0) for the stock components to make this more benign. I just had to to exactly that with a couple of delays just this week after reports that stage(0) was causing problems. Maybe things are a little different for poly, I'm less sure about those as I have used poly so rarely. Could also be that it's more of a problem for custom code/assembly - the stock modules may well have access to this stuff at a deeper level - e.g. stage(0) in poly is somehow slightly independent for each SSE channel (i.e. voice), which even in assembly would be very tricky to program explicitly using the limited instruction set.