Multi Osc Phase Bug???(?)

[Perfect Human Interface]

Hey, so this is really weird. I was toying around with this ringmod effect module here:
viewtopic.php?f=3&t=1265
Now this could be a bug specific to that project, but I suspect it may be the Multi Osc component inside it causing this. I haven't the patience to further test this right now since I'm already knees deep in my own project here, but I figure either way this is weird enough to warrant its own thread.

While working on my project, I was trying to get full cancellation between two instances of FS with one's output inverted when I realized that weird things were happening every time I hit the delete key... I've found that pressing the delete key (with nothing selected) or adding a component to the schematic causes the oscillator's phase to shift! This is totally bonkers and was throwing me off big time!

So uh... if this isn't already a known bug, if anyone would like to mess around with Multi Osc to test for a phase shift whenever hitting delete or adding a component, that's kind of a big issue!

[trogluddite]

Hi There,
This happens in a variety of different circumstances - it's caused by FS re-compiling the code for the audio streams whenever anything happens that might change the routing (though strange that it happens if you press delete when nothing is selected for deletion!).

Green parts don't have this problem because they are simply interpreted in real time as messages are sent between components. But for streams to be a able to process at sample rate without gobbling all of your CPU power, the graphical representation on screen is compiled to machine code each time a change is made.
This is necessary for a couple of reasons, though it does seem to be rather over-zealous very often!

1) Stream modules that have their outputs disconnected are removed from the code so that they use no CPU - for example if you use a selector to bypass an effect.
2) A schematic may appear to have parallel paths - but of course, real code can only really do things one at a time in sequence. And the order of processing each component makes a big difference to how a schematic behaves - get the order wrong, and the output would be nothing like expected. We tried once at the SM site to work out how this ordering worked - and gave up after a while because it is fiendishly complex for all but the simplest schematics.

Whenever one of these re-compilations happens, each stream component calls its "initialisation" code (known as stage(0) in FS) - in this case resetting the oscillators to zero (or the absolute phase offset if there's a value at that input). How this affects any given module depends on its internal coding, some have no 'stage(0)' code.

The re-compile when editing a schematic is annoying, but won't happen in normal use of a finished design. However, there are times when you get a reset even in an exported .exe or VST....

- If your schematic includes selectors/multiplexers etc. that re-route the audio under GUI control, there will be a reset of mono/mono4 streams whenever the user changes the routing from the front panel.
- In a poly synth, a new note always starts from its "reset" state - so, for example, oscillators always begin from zero at the start of a new note. This is unlike a real analogue synth where the oscillators continue to run even when you can't hear them, and each voice begins with a different phase offset.

Those "in use" resets certainly can be a problem sometimes, and can be rather difficult to overcome.
The re-compile during routing changes in particular can be a problem because, in a large design, the re-compiling of the code can take long enough to interrupt the audio streams and cause a short drop-out.
The "new note" reset also makes some de-tuned sounds work in an undesirable way - each note comes out with exactly the same phase relationships rather than the phasing flowing smoothly from note to note - sounding more like repeated samples than a true analogue simulation.

There are ways around these problems, but unfortunately, they are not easy, and often require breaking out the Assembly primitive and using completely custom written modules throughout the schematic.

Now that we have Ruby to overcome some of the limitations of the green triggers, many of us are hoping that audio streams are next in line for an overhaul - we have lived with these issues for a long time now, and CPU's are much more powerful than they used to be, which changes the balance of the "CPU optimisation vs. flexibility" argument.

[Perfect Human Interface]

Thank you very much for the exhaustive response. It's a bit worrisome.
Is there a way to force a reset? Do the host sequencer's transport controls cause a general reset by any chance?
I'm mainly thinking about LFO's here. I haven't gotten in to tackling that concept yet, but I would certainly hope that keeping an LFO properly in sync with the host tempo is possible.

Stream modules that have their outputs disconnected are removed from the code so that they use no CPU - for example if you use a selector to bypass an effect.

Eek, so even if I want something to run continuously, it won't run without a stream running through it continually?

[trogluddite]

Eek, so even if I want something to run continuously, it won't run without a stream running through it continually?

That one is not quite so bad to sort out - it's only when all stream output connectors of the primitive/module are completely disconnected that this happens. Fortunately, reducing the output to zero using a multiplier (amp) doesn't count as disconnected, so you can do something like this simple example...

Keep on Running.fsm

(6.48 KiB) Downloaded 973 times

You lose the CPU saving of turning the oscillator completely off, of course - but that's a small price to pay if keeping accurate phase is important. It also means that flipping the switch is no longer a "re-compile" event, so no audio audio glitches, especially with the 'de-zipper' there to smooth over the switching.

Is there a way to force a reset?

Yes, there's little primitive called 'Clear Audio" which lets you use a trigger to force a reset - it's not clear from its description, but it does also force a call of the 'stage(0)' initialisation.
Host transport controls don't trigger a reset by default, but you can connect the primitive "Is Playing" to the "Clear Audio" to force that behaviour if you need it.

exhaustive response

Exhaustive, but I hope not exhausting!
I've been accused of including too much detail very often, but I try to write so that the posts can be referred back to by users of whatever skill level. Just let me know if I'm ever aiming my answers too high or too low!

[Perfect Human Interface]

I've been accused of including too much detail very often, but I try to write so that the posts can be referred back to by users of whatever skill level. Just let me know if I'm ever aiming my answers too high or too low!

It's extremely helpful. Flowstone seems to be a little lacking in documentation and tutorials so I can already tell that your experience and your irrational dedication to sharing it is a boon for users.

[tester]

So instead of using individual resync nodes in oscillators (PHI - you can reset individual oscillators that way) - I can use the "clear audio primitive"? If so - good to know.

Just a few days ago I was wondering if there is a way (in exported design, vst/exe) to reset all code-based parts, without using selectors (when a lot of streams go through, strange things may happen).

//edit:

Just checked something. Sometimes, especially if you have a lot of oscillators and codes in your design (hunderts), it is better to have customized resync/reset, only for these parts which are important. Otherwise, clearing audio may produce much longer glitch than you wish to have.