DAW song doesn't reload settings correctly.

[Spogg]

Hello!

I just found something out that I thought I should share.

I was helping Johan sort out a problem whereby presets would save and load correctly, but when changes were made to a complex wave selector in the DAW, and the song was saved, upon re-opening the song the wave selection was wrong.

It took a long time to establish that, so it would seem, the DAW doesn’t necessarily re-load the parameters in the same order as the Preset Manager would. Of course, for pretty much every control this wouldn’t matter, but for this particular system the order was critical.

I messed around using After Load prims and so on, but the solution was to add a small delay to 2 of the parameters, to get the sequence correct.

The lesson I learned is to check if changes are restored when a song is reloaded and, if not, pay attention to any control system which may depend upon the loading order.

Cheers

Spogg

[MichaelBenjamin]

.

[Spogg]

You could use the array preset for that purpose I guess. Not a bad idea and one I haven’t seen done myself.

In Johan’s synth it wouldn’t apply because the array size would vary between presets and banks of wavs loaded by the presets. A float array preset prim has to have a pre-determined size.

Also, it’s much easier to have single preset parameters for each control and not to worry about compiling, saving and restoring a range of values in an array.

I made this post to raise awareness that the DAW may restore parameters in a different order to the Preset Manager, when a song is reloaded. I’m not 100% sure about this, but my fix was based on that and it worked.

Cheers

Spogg

[trogluddite]

This kind of situation is what the "Before Preset Change" and "After Preset Change" wireless outputs from the Preset Manager are there for, though admittedly, I've not used them much and they may require a bit of additional logic.

The idea is that the "Before Preset Change" trigger is used to engage a "don't recalculate" mode (i.e. trigger blocking), the parameter values then all get updated, and once all parameters are in a legal state, "After Preset Change" triggers the calculations and restores normal operation. This can also help to prevent flurries of unnecessary triggers, as it guarantees that downstream calculations are performed only once per preset change.

The "Before Change" and "After Change" triggers from individual "Preset Parameter" primitives act in a similar way, except that these do it for each user interaction, but not for preset changes (generally much less useful, and something that took me forever to work out!)

Arbitrary delays used to solve timing and trigger order problems are nearly always a "code smell" IMHO, and there usually is a way to order things correctly or, as here, to use handshaking with asynchronous processes.

[trogluddite]

A quick demonstration of the above...

before_after_preset.fsm

(532.45 KiB) Downloaded 892 times

[Spogg]

I did experiment with the before and after preset change, to no avail.

I agree that my solution is inelegant but those who know me well realise I’m a pragmatist.

As I recall (it’s been a few days!) it’s necessary to select a column then a row. It worked correctly from the preset manager but not when a DAW song is reloaded.
If there was a way to make sure that the PM and the DAW reloaded in the exact same sequence that would be even better.

When a song reloads I don’t think you get the triggers from the After and Before preset change. So I had to make use of the After Load prim with a small delay.

Cheers

Spogg

[trogluddite]

I agree that my solution is inelegant but those who know me well realise I’m a pragmatist.

It certainly can't always be avoided (and always more tricky when it's someone else's schematic, of course). As an easily searchable thread title for folks having similar problems, this is a good place to leave an example of canonical usage anyway, even if it's not a guaranteed fix.

When a song reloads I don’t think you get the triggers from the After and Before preset change.

Possibly another one of those things that not every host handles the same way (FS itself doesn't trigger them upon loading, but wouldn't need to as there's no "host project" data to load). Further testing revealed that loading a song into Reaper sometimes triggers them not just once, but three times! Here's my test schematic, in case anyone is curious about their own host...

preset_load_order.fsm

(262.91 KiB) Downloaded 898 times

[EDIT: Just export the top level module as a VST plugin; the display will show the triggers when the plugin is loaded into the host - there aren't any controls to tweak, as the knob is just to ensure that there's some preset data present.]

[Spogg]

That’s a remarkable thing you made there, but I’m not sure how to use it in Reaper.

I was looking for the trigger input to the Ruby Logger but there was none. The cleverness is beyond me but I assume there is some sort of "globality" involved. I remember tulamide once showing us how one Ruby edit can influence another. Spooky action at a distance as Albert would say.

Cheers

Spogg

[trogluddite]

I’m not sure how to use it in Reaper.

Yes - I should have included some use notes!
Just export the top-level module as a VST plugin (hence the dummy audio inputs/outputs). When the exported plugin loads into the host, the display will list the triggers as and when they happen (the knob is just to ensure that there is some preset data present).

I assume there is some sort of "globality" involved

Spot on! Ruby's global variables and constants are visible from everywhere (even across multiple schematics within FS). If you can get hold of a RubyEdit's "self" or "@this" reference (into the global $TRIGGER_LOGS here), you can call its methods directly without having to use events sent via inputs (unfortunately, it's not easy to guarantee what order the RubyEdits will be initialised in, so there's a bit of other juggling needed which makes the code less easy to follow). It's a sneaky trick, but very handy for tools like this one, as it's not subject to the "wireless visibility" rules.

As is usual for me, it's yet another example of a half-finished project - I keep meaning to turn it into a more user-friendly debugging tool for the toolbox, but never get around to it!