prim stability question

[tester]

I noticed, that one primitive seems to produce unstable behaviors in my schematics (exe tends to crash more often for some reason). "Trigger switch" (the one that opens or closes the pathway according to bool). This problem does not happens when I use "Select" primitive (the one with true/false inputs) instead.

"Spooky issue" so to speak (somewhat non-trackable), that seems to happen when preset manager is involved in the loop, or activating some processing on streams with ticks (multiple triggers?) in the game. But I was curious - did anyone noticed it?

[Nubeat7]

I noticed, that one primitive seems to produce unstable behaviors in my schematics (exe tends to crash more often for some reason). "Trigger switch" (the one that opens or closes the pathway according to bool). This problem does not happens when I use "Select" primitive (the one with true/false inputs) instead.

"Spooky issue" so to speak (somewhat non-trackable), that seems to happen when preset manager is involved in the loop, or activating some processing on streams with ticks (multiple triggers?) in the game. But I was curious - did anyone noticed it?

i changed this part too a while ago in my last project but the true/false select isnt working for triggersignals but when changing from the normal selector to the triggerswitchfor triggering the "mono to float" i didn`t notice any changes in stability, maybe i will havea closer look on this

[billv]

unstable behaviors in my schematics (exe tends to crash

I have used many "Trigger switch" in my last synth update, and and still trying to track
an error that's causes plug in to crash while using an EQ Mod.

Can you describe the crash???

[tester]

In one situation - there was a "loop" for a backup/autobackup system. Shape selector turned off the audio, audio off triggered preset saving, preset saving triggered shape loading in selected unit, shape loading triggered turning on audio. 3 timers/delays on board to make it smooth. For auto backup system, "trigger select" was somewhere around preset manager (I don't remember where exactly; it was dozens versions ago) - some "pass or block the trigger". In the past I always used the "select" primitive (habits), but just recently found this one and wanted to check it because it looks simpler. So I exchanged the "select" (used with standard trigger blocker) into "trigger switch", and my exported exe started to... crash around the backup/autobackup routine. I switched back into "select" + "blocker", and all went back to normal.

Another time, it was in visualization system, to block or pass tick100 for clicked visualizers, to avoid CPU usage on non showed displays. Exe app started to crash. Switched back to select with blocker, and all came back to normal.

Around my schematics "trigger switch" is used in many situations (some of them I even don't understand), so it's not that this is a "bad primitive". It rather seems to have bad behaviors in some "flow" situations, where delays happen and are caused by disk/memory usage, ticks or m2f-like routines; and maybe in large schematics (a lot of elements). As if "waiting for trigger" ("stretching the trigger grid") was a problem?

But as I said - I did not tracked that "spooky bug", I just changed into something else, and when I noticed that it works fine - I moved forward. Anyway if you see it happens on your schematic, you may try to switch into passive true/false (no trigger when/from switching) i.e. "select" with "trigger blocker" on boolean node (if you need just triggers, then make a module of it, and change output node into trig).

Maybe Trog knows something more?