So I've been testing, testing, testing... and testing
Poly always works. Blue though...
The most reliable or should I say "the always working" blue schematics inside FS, is when I have an
always connected blue ghost LFO-oscillator (preferably one of MV's ASM's) in parallel with my "actual" switchable free-running blue LFO's.
This ghost oscillator is multiplied down to 0 output meaning it's always running silently, without any multiplexers/selectors in it's signal path. I've tried a DSP snippets that just outputs whats going in. Didn't work, but might if it does a multiplication or something inside. Maybe.
Nevertheless, when I export to an EXE I get a varying results... EXE-exports doesn't seem to work the same as FS itself. It performs much worse against ASIO. In my mind it should be the opposite
Most commonly funny enough, the primary soundcard-output (non ASIO) is the one that usually works with the free-running LFO's in .EXE exports. ASIO however
Selecting ASIO crashes the .EXE quite often, but usually the free-running LFO's don't work or when they do stops working right away.
I've put a button for a clear audio-prim in the GUI. Sometimes the free-running gets going for a short while after clearing all streams. So... A latency and audio-buffer issue it is then...
I have a humble question about this, without knowing anything about the heavy coding aspects/development...
If the blue streams are actually realtime (system-, audio drivers-latency and- ASIO- buffer-dependent)... couldn't FS in theory be updated to allow an introduction of internal delay to garuantee full execution of it's own audiostream components?
As it is now... Having schematic functionality-dropout is much much much worse than allowing for configurable latency tolerance or even silence (when system isn't up to the task) in my mind... Even crashing is better than non functional features inside a plugin (from a UX/usability perspective).
It would be nice to know how FS handles Mono contrary to Poly. Since Poly always seem to work
)