Selector in Mono stream not reliable

[Spogg]

Hi all

I've searched the forum and found information that kinda relates to my problem but doesn't address it specifically.

If I use a selector prim on the outputs of MONO effects chains to mute (disconnect) the mono stream it can cause the whole audio to stop.
I got around this successfully in FS by triggering a Clear Audio Prim when muting/unmuting (one prim used for the whole project with all triggers going to it). However, when exported as a VST, whenever I mute or unmute one of the modules the audio stops. If I change presets, which have different mute configurations, a few may work but most don't and I mostly get no audio.

I want to kill the CPU for unused MONO streams since not all presets need all modules running. My selectors are wired on the output of each module and select between a dummy input (set to MONO) and the MONO stream from the module. The outputs from the modules are then all connected to a master volume/width/etc controls module.

I have successfully used this mute method in most of my projects but it only works reliably if the selector is at the end of a poly stream, not a MONO stream. When muting a Poly stream the selector outputs then feed into MONO via a combiner, and all selectors work reliably.

I gather from my reading of the forum that the selector Prim initiates re-compiling but does that happen in the exported VSTs also, or just in FS when editing? I don't see what's so special or specific about the MONO stream as opposed to a poly stream but there is something that the selector Prim doesn't agree with!

I made a simple stereo DSP mute module which works as intended but when there is no output the CPU is still in use so there is no saving of cycles; likewise with switching 0 or 1 into multipliers: It works as a mute but with no CPU saving.

If this is a bug (and I think it might be) it's a pretty significant one I think.

I'm on FS 3.08.1and I test in Reaper and use Creative ASIO.

I really would welcome some input from you guys on this!

EDIT: I tried adding a poly to mono prim as the 'dummy' for the muting selector input but same result.

Cheers

Spogg

[tulamide]

I don't see what's so special or specific about the MONO stream as opposed to a poly stream but there is something that the selector Prim doesn't agree with!

The specific difference is that the mono section is running while a sound output is active (either sound outputs as plugin, or a specific sound driver as exe), while the poly section works on demand. It is so, because of the sample accurate usage of the mono section. This can only be guaranteed when running in sync with the sound driver.
So you can basically just prevent too many monos being active, but you will always have a minimum cpu load (depending on what is active in your mono section.

When using the selector to route monos, the whole mono section needs to be re-evaluated. There are way more experienced users that will probably tell you a trick. It might also be possible with Ruby, although I've never tested it.

[Spogg]

I could cry

I spent one whole Flowstone day trying to find a way around this problem. My project is a relatively simple one: 6 chorus and pitch shift modules. I made a test one with 6 chorus modules from the Analogue Kit and the selectors worked as expected, but not in my more complex one. In the end I found that where there are 3 selectors in series (not directly) in any mono chain the problems start. So, being a pragmatist, I have resolved to use only 4 of my modules and just use a simple DSP box to mute the output lines (for auditioning only and not CPU reduction too). The CPU is very acceptable in this case and I can mostly achieve what I had in mind.

This has, however, left me feeling quite disatisfied since I couldn't achieve my design as I had planned and this seems to be down to a weirdness in Flowstone.

Anyway, tulamide, thank you for your input as always.
Maybe some kind and all-knowing soul can add more insight to the issue.

Cheers

Spogg

[KG_is_back]

This is most definitely a bug...

Selector in a stream section (be it poly or mono) should recompile the stream part of the schematic once it's triggered. This recompilation happens between ASIO buffers rendering, so they are not sample-accurate. When exactly the recompile happens depends on the buffer-size setting of your sound-driver and CPU load (because recompile is triggered by green, which have 100triggers/second limit) - it may skip one or two buffers if green is triggered intensively.

Possible causes of your problem (pure speculation):
1. The re-compilation takes too long (because of size of the schematic) and fails to finish before next buffer comes in and the new buffer calculation interrupts the compilation (instead of just pausing it). For whatever reason the previous compiled-stream-code is already dumped and audio drops out.

2. Some (code-size related?) error happens and compilation returns empty machine-code = audio drops out.

3. Black magic...

Possible fix:
For case 1. and 2. try connecting a "clear audio" prim to whatever triggers the selector (as a second connector). The prim also causes recompile and should theoretically fix the bad/interrupted compilation. For case 3. contact nearest priest

Either way, report the bug to DSP support via E-mail.