another bug related to file/preset system

[tester]

Okay, here is another spooky problem, it seems to be a bug. While trying to make backup system for "sensitive" modules that can cause crashes of FS app pretty often, I found that... I can't.

Here it is. Run teh schematic. Before you touch anything, important note:

Brown leds are of the same type, synced, to avoid misinterpretation here. They both are connected in the same order: first - backup system, second - load/reset shape. First led on the left - triggers shape loading(you can use provided example). Second brown led triggers "reset" which means that "default shape" is loaded. Both shapes are in folder. Third important element - on the preset manager, there is button/box named "b".

Concept. Because loading shapes in running application causes crashes, I decided to add a possibility to discretely save the preset in the background - before shape is loaded. Thus - if app crashes, I don't need to start from zero. So, if you click on whatever brown led (left or right), trigger goes first to manager and saves in the background the preset in relative "backup folder", and everything else happens next after that. The "b" box is for manual backup, without any dialog.

Do following.
1. Open schematic, don't load anything yet.
2. Open backup folder, to see when it works and when not.
3. Click the "b" box on preset manager. In backup folder new file emerges.
4. Click the right brown led (resets shape). In backup folder new file emerges.
5. Click the left brown led and cancel/esc the dialog. In backup folder new file emerges.
6. Click left brown led, and load whatever shape.
7. From that moment, if you repeat points 3-6, no backup file is saved. "Preset text file" receives triggers correctly, but does not saves anything, nor sends triggers (except for pt 8).
8. If you reload schematic - everything resets.
9. You can still save the preset from preset manager (which opens windows dialog box).

Triggers are monitored on brown leds and inside preset manager.

[tester]

To avoid duplications - I sent this one to support.

[trogluddite]

Weird - I just tried it here, following your instructions exactly, and it seems to work perfectly - even when I make an effort to try and confuse it, I get a backup saved every time, using either the buttons or loading a new shape.
No audio running though - I wonder if that makes a difference, though I can't think why it should.

[tester]

Not working here, tested on two separate machines. I played with the schematic in the state as attached above. When I load a shape via dialog box (left led) - the background savig goes dead. See the picture; even the control triggers are not sent from preset. The only difference between left and right led (because both load external shape files) is, that with left led, in order to load a shape - you must confirm the load via windows gui dialog box (and this confirmation - not the dialog box itself - seems to cause the problem).

I will try another tiny thing here - the one that MyCo does not likes so much - time based separation between string update and saving trigger (interactivity emulation; instead of JohnA and JohnB - John and Nick, so to speak). Otherwise - no ideas.

//update:

With delay - not working. Even more - timer seems to be dependent on windows dialog box (i.e. in such case - background saving stops working also when left led is just clicked).

Trog - what your tools are showing on your computer?

[tester]

Major update.
This issue has to do with relative file paths in conjuction to comfirmation via windows dialog box (default shape loads from relative folder too).

If I switch the path into:
"X:\[folder-structure]\backup\filename.txt"
then it works as it should, but if the path is relative, like this:
"backup\filename.txt"
then it does not works.

Any idea how to automatically (ruby? no ruby? ruby?) detect the path where from application is being started/executed?

[tester]

Major update #2.
It looks that this issue exist generally in schematic mode.

Because it did not worked under FS, I did not do anything else. But few minutes ago - I just wanted to check something. It appears that exported exe (at least simple one; not tested under heavy load) works fine (not tested with VST yet), while schematic loaded to FS - not. Spooky...

I also checked the "start folder" primitive, which is confusing. In schematic mode it shows where plugin or exe will be exported (was exported last time), but it shows correct path of exe when starting that exe. Either it should give the ability, to show the folder where schematic is (to provide absolute paths), or they should fix relative paths issues.

[trogluddite]

It appears that exported exe (at least simple one; not tested under heavy load) works fine

That is rather odd - maybe it explains why it worked for me; just because all the files had been moved to my temporary 'downloads' folderm, with no memory of a previous file path etc.
AFAIK, when saving using the FS prim's, they will never create a new directory - they can fail silently if the requested folder doesn't yet exist. So it seems likely that for some reason the root path is being changed ("Start folder" prim, seems a likely suspect) - so causing it to not find a valid 'backup' sub-folder, hence no save, and no 'completed' trigger.

.

In schematic mode it shows where plugin or exe will be exported (was exported last time), but it shows correct path of exe when starting that exe

Yes, it does work a little strangely - when you're within the schematic, it's intended that you manually set a folder using the input - but I've always found that rather clunky, as it needs changing any time you move files around.

Same in Ruby, too - the 'official' "$FILE" variable always points to a system directory instead of to the current schematic path.

[tester]

It looks, that after struggle - auto-backup system works perfectly, also under heavy load. The downside - exported application crashes more often than before and produces more glitches. Of course it was somewhat predictable, I just did not knew to what degree.

So here is my thought about possible optimization.

1. Certain operations must be done step by step, one after another, not all at once.
2. There are several units that load shapes when global audio is on.
3. Clicking on "load-shape" in whatever one should send trigger to A) open local gate, and B) turn off main audio switch.
4. From main audio switch trigger should go to preset manager, to do auto-backup.
5. Confirmation after backup is done - should be sent to all units
6. Only unit with local gate opened - will pass the preset trigger.
7. That trigger should A) close the local gate and B) go to loading shape routine.
8. After shape is loaded, trigger should be sent to main onoff switch, to turn it on.
9. Secondary thread of triggers will go anywhere, because all gates are closed.
10. No triggers will pass through also when programs are saved/loaded, because all gates are closed.

That's the theory (if I did not overlooked something).
But - will it reduce the amount of glitches?
Surely it should reduce the amount of crashes.

Is there anthing that sends a trigger / confirmation - after all audio activity is off?

*

ps.: I see that we both write right now. In all tests I used backup fo.lder created manually. But yes - primitive could have the ability to create (yes/no) folder if none exists.

[trogluddite]

Is there anthing that sends a trigger / confirmation - after all audio activity is off?

Sadly not - but a short delay is almost certainly a good idea because the audio is divided up into buffers, so probably won't be truly 'off' until the current buffer is cleared. One of those rare cases where even I would use a Timer just to be sure.

Sounds like a reasonable plan though. I have done similar in the past where I have a schematic with lots of audio changes at switchover time; seems better to have the re-compiling well controlled by turning off the whole system for a moment, rather than have the driver interrupted dozens of times by all the inner changes.

primitive could have the ability to create (yes/no) folder if none exists.

That would be nice.
In the meantime, here's a workaround that I've been using for a long time (originally by Philter and Exonerate at the SM forum)...

New Folder.fsm

(1.23 KiB) Downloaded 1098 times

It's OK to use this even if the folder already exists, and it will always give an output trigger once the folder is in place, so timing the file save it easy.

[tester]

Thanks for "folder creator". And for advice on delay; I'm curious whether this one will work for my advantage.

I also started to add some multiple routines, like "long reset" (click and hold for a while), to do harder job, while simple click makes the basic work, and dbclick for other things - all under one button. So we see where it ends.