another bug related to file/preset system

[tester]

Funny thing about trigger logic.

First - I created a gate, that after click - turns off the main audio, and sends then a trigger to preset manager (autobackup module). Confirmation after preset is saved from preset manager - goes back, and this trigger is responsible for loading shapes. A loop.

Then - after shape is loaded, wavetable sends the confirmation trigger to turn the main audio on.

And here is the surprise. Trogz Tools shows, that first received trigger is to turn the audio on, and then off. Which is physically impossible, because audio must be turned off in order to make the shape loading possible. Spooky. We had entangled triggers, and now time travel!

[tester]

...anyway with one delay (time based trigger separation) - autobackup works. Also - the whole unit behaves more stable now, although glitches are still present from time to time.

Now I have to think whether I decide to keep this autobackup routine or just that small "b" button for manual saving without dialog box. Anyway, turning on/off the whole unit will stay, because it seems to prevent app from crashing.

[tester]

For some reason, logic based triggering (audio off -> preset storing -> wavetable creating -> audio on), makes the app crash pretty often, and it seems to be related to preset manager part of the loop (and some primitives?). But when I added 3 timer delays (time based trigger separation on the other hand, so to speak) - it seems to work fine. With timers 500-1500ms per delay, app has time to store the preset and create wavetable separately, and generally there are not too many glitches at all. Right now it's stable, but we will see how it behaves under heavier load.

[trogluddite]

Sounds similar to a problem I have here sometimes.
Related to audio drivers, I think - my old soundcard never did it. It's as if there has to be a certain interval between connecting and disconnecting the audio streams Changing the sample rate from the FS schematic does the same thing quite often.
Oddly, I get it mostly with very small schematics - just connecting ASIO In straight to ASIO Out usually makes it crash, but fine if I put a really huge FX in between ('building' the FX = time delay, maybe?)
Seems like...
Very short audio 'gap' (e.g. selector switches over), no problem, the buffering conceals the gap.
Very long gap, no problem, there is time for the driver to 'tidy up' the start/end of the cut.
Somewhere in between, crash!
I wonder if maybe the time to build wave shapes/save presets in your design is hitting a similar 'time zone'?

Was the same with SM, for me - Malc tried to help, and the crash report seemed to be an ASIO thing, but soundcard drivers are the secret of the manufacturer (and I have a very rare/old system too), so very little he could do.

[tester]

Probably yes. When I tested my app on my friend's computer, exe (few versions earlier, before I decided for that auto-backup system) crashed almost always, while vst version worked perfectly on the other hand. Different crashing rate than on my PCs. And yes, crashes are independent from gaps, they just seem to happen with certain elements (wavetable conversion, changing the soundcard/output).

I noticed, that Flowstone is able to deal better with these stream related issues than old SM; that was one of the reasons I decided to switch. I'm also familiar with the "sample rate" primitive issue. I "solved" it, by making one SR/2 with wireless output to all modules that needed it. It was also easier to turn it off, and provide static value, or generated separately from stream.

[VPDannyMan]

I didn't read the whole thread or download the demo, but I just want to make a couple points..
-Watch for spaces in your path
-Use this "/" instead of this "\"

[tester]

Nothing like that here. I usually use traditional 8/3.

Anyway, after switching on/off the global audio for operations, and adding timers between operations - testing on a machine where exe was rather unstable shows, that now the app is more stable than ever before, has less glitches, and user switchable autobackup system works as it should be. Just one crash per several hours of continuous work, no loss of user data. I can say that I'm satisfied.