Automatic reloading of previously used settings

[trogluddite]

Returning to the original request: it seems to me that part(s) of the specification may be missing or ill-conceived (for VST plugins, that is - the concept is sound for an executable).

Let's say I create a new project and insert the plugin, thus loading the "last used" settings. I now tweak these settings to better suit the project and save it. When I reload the project, should I expect the "per project" settings to be honoured; or should the "last used" settings be loaded (which may have been changed during work on another project in the meantime)?

Likewise, when loading a project, the plugin's settings are normally restored from the project file; if we are honouring "per project" settings, should these now be saved as the "last used", or should that happen only if I subsequently change a setting, or only when I explicitly request it, or at shutdown, or not at all because this isn't a "new" plugin instance?

The possibilities multiply if there might be multiple instances in the same project, maybe some "tweaked" and some not. How do we define "last used" if we tweak more than one of them? If we're saving at shut-down, can we trust the host to close the instances in a reliable order?

If the "last used" settings are intended for a plugin which is some kind of "global" processing for an entire studio, for which every project will use a single instance with the same settings (matching between listening environments, say), this would be no problem - just reload the current settings from disk every time the plugin starts up, and save the settings either on every change or at shutdown (a situation for which DaveyBoy is doing a grand job.)

However, if "per project" settings are to be honoured, the plugin will need some way to tell whether it is already part of a project or is a freshly added instance, which there's no built-in way to read AFAIK (not an FS limitation, just how VST works)*. The only way that I can see would be by preset number, so that, say, preset one is always the "last used" and has the current data re-loaded whenever the plugin is started up - but you would have to be sure to switch to a different preset before making any "per project" tweaks.

I can see the attraction of auto-loading to ease project setup, but the cost may not be worth it if we have to change how presets typically work such that there are other inconveniences, even just the need to remember that this plugin is an exception to the rules (an open invitation for unfortunate accidents!)

(* EDIT: I think a "new instance" test may be possible in a roundabout way, but it depends on how triggers from the preset manager are handled at startup and project loading - I'll have a little tinker; maybe possible, maybe not).

[trogluddite]

Re: the last edit in my previous post. A simple "new instance" test doesn't seem likely. In Reaper at least, the preset manager always produces "before/after preset change" triggers when a new instance is instantiated just the same as it does for one loaded with the project. A fiendish method using a "secret" VST parameter as a "modified" flag might have an outside chance - but I doubt that it would be very pretty, so I'll leave it at that!

I think the only viable solution would be a new Ruby-based preset manager...

As a keen Rubyist, I would love to be able to write code like...

Code: Select all

current_value = presets.current["my control"]
presets[2]["my control"] = 0.5
presets.save_bank(filename)


For the currently loaded preset, this can be done already in principle (I've experimented with something similar for managing MIDI bindings). However, as you said earlier, it requires modifying every single control containing a VST preset parameter. If FS could natively expose the data structure as a Ruby object, that would be fantastic; but I suspect that it would be rather a lot of work for MyCo!

[Spogg]

Thanks for looking at this Trog.

I have a kind of solution now which Johan is evaluating. If it’s a success I’ll post here. If not I’ll keep quiet!

Cheers

Spogg

[trogluddite]

Thanks for looking at this Trog.

No problem; it's something that I've long had an interest in - I've always wanted an easy way to load "global" configuration data that integrates well with the preset system. That, and I only just realised that I've been confusing myself by conflating two threads about similar subjects! (see the other thread for further comment about VST host's handling of Preset Manager triggers).

[Spogg]

This was what I came up with.

The user will click the SAVE STATE button.

After opening the plugin in a new song, if the user wants the previously used settings, they would click the LAST STATE button.

The system saves the whole current bank to the file Banksave.txt which is located with the plugin or schematic. This contains all the current settings for the synth and is over-written every time SAVE STATE is clicked.

Cheers

Spogg

[billv]

G'day Spogg...nice hack...seems to work just like you said..well done...

[Spogg]

Thanks Bill.

I was inspired by your original version to look into file-related prims. I thought Ruby would be the only way before.
There’s always something new to learn with FlowStone.

Those fires in Australia seem pretty damn awful mate. I hope you’re ok…

Cheers

Spogg

[billv]

Those fires in Australia seem pretty damn awful mate. I hope you’re ok…

We have a lot of history with fires, but these ones are pretty bad.
Some mornings you wake up and there's just smoke everywhere, really thick blankets of smoke.
Just like the fog on a deep winter morning, really thick fog, where you can't see nothing,
like a scene out of a spooky movie.