incorrect trigger behavior, possible a bug

[tester]

Here is following problem.

"Text Load" primitive should open a text file from relative path (important) when app/schematic starts. "After Load" primitive shows, that trigger is sent. But nothing is loaded. Manual trigger shows, that this text can be loaded from the relative path.

I tried it in various ways, even with links order (first - refresh the string presence, second - load), but nothing seems to work. Even if the trigger order is correct (see test 2; direction of log is from up to down). So - what is the problem here? How it can be solved?

[trogluddite]

There's no bug - loading from the relative path is an undocumented "feature" which is not to be relied on. The lfile primitive and component guide explicitly state that the full path should be used (for reliability). Though it must be said, relative loading would be rather more convenient much of the time (maybe a bool input on the prim'' to choose).

You'll need to use the "start folder" primitive to construct the full file path - that will work for .exe and .dll exports reliably Note that the '\' symbol needs adding between the folder and filename as the folder path is 'bare'.
But it does have one sometimes annoying quirk - it doesn't work when you're inside FS, you have to provide a 'default' path that gets used during editing sessions.

[tester]

What's interesting - time based solution seems to work, but... will it work under heavy load? Or to be precise - are these time based solutions working, because something else than the order of connections separates trigger 1 from trigger 2?

[trogluddite]

Yes, it's weird - as if they intended to have that feature, but didn't quite finish the programming!
Seems like there is some strange effect where the triggers get intialised before the file path does - yet it works fine using the 'start folder' primitive (I have used this many times) - it is obviously not difficult to implement.

[tester]

Not documented?

Are you sure?

I don't care about how it behaves in DLL, because in my projects these are only on the side of the user interface. But thanks for reminding, that there might be an issue related to copied dlls by some hosts.

Can you show what you mean with this start folder primitive?
Will it work with preset manager, i.e. will the preset store a relative path instead of absolute?

[trogluddite]

He he, 2006!!
And look at the SM version number - wonder if it ever got reported by the Beta testers!!

[tester]

Yep, very old, at tat time I didn't even knew about it's existence.

Anyway, I wonder if there can is an easy way of storing relative paths\files to load. Otherwise - manual editing the presets - which works but is boring. Could you show on some example? My brain is somewhat off rght now.

[trogluddite]

Here's a rough sketch of what you need from an old SM example. it uses the trigger output of the VST preset to ensure that a file gets loaded automatically whenever the preset changes. Need to test, but I think the preset trigger happens at start-up too, so I don't think an 'After Load' is required.

Preset File Loader.fsm

(1.46 KiB) Downloaded 900 times

NB) It's really still an SM file (edited to '.fsm' to keep the forum attachments happy) - if you re-name to .osm it will load in SM too.

You could also store a sub-folder in the VST string if you needed to - inside the "Trogz Toolz" schematic at the SM site, there are some string modules I made for separating and combining folder, filename, extension etc. that might be useful if you need a more flexible system.

[trogluddite]

I didn't even knew about it's existence

Same here - I was using SynthEdit back then - no code, no assembly, and an awful user interface. Wish I had found SM sooner!

[MyCo]

With ruby, loading on init doesn't work, so it uses "after load"