Presets and Multiple Instances

[syntonica]

Working on the preset management system for my plug. Ugh. I know, and I am kinda stuck.

My biggest concern is multiple instances and having one instance possibly clobbering another. I'm currently using a singleton as a pasteboard to copy data to other parts of the same instance, or to another instance. If I use this same logic with preset management with possibly a lock to let instances know something is in use elsewhere, is this really bad juju? Or, is this the done thing? Again, with a mutex lock or semaphore, I suppose separate instances of the preset management class would work as well. I'm just trying to get a feel regarding the current thoughts on this kind of programming practice and avoid unnecessary disk reading/writing. I want to avoid using something like sql to manage my presets.

Also, regarding state information that the host stores for an instance, is this data just strictly the name (or preset number) and plugin setting data? Does it store anything more, or do I have to go to using chunks? As I understand it, these are just BLOBs of arbitrary format and up to the plug to feed to the host and read back?

[Guillaume Piolat]

Also, regarding state information that the host stores for an instance, is this data just strictly the name (or preset number) and plugin setting data? Does it store anything more, or do I have to go to using chunks? As I understand it, these are just BLOBs of arbitrary format and up to the plug to feed to the host and read back?

From what I understand, what a VST host stores for each insance is:is:
- the whole state of the preset bank, including names.
=> When using chunks: a chunk for each preset,
=> When not using chunks: Paramaters values mapped from 0 to 1. It's not only a preset index.

Because custom preset systems rarely match the VST preset model, I believe it is required to use chunks whenever you want things that don't map well to 0 to 1 (eg: strings). In many plugins, only the internal preset system is used and no preset is exposed.

Meanwhile, an AU host only use chunks, I think it does save the whole bank too.
Not sure for other formats.

Considering your plugins may well be in different processes (bridging), I'm not sure why you would want mutexes or semaphores.

[syntonica]

Thanks, Guillaume.

It's just that considering a bank of presets is a database shared by multiple instances of a plugin, values are going to get clobbered. Having dealt with this before using an add-on database, it's not a road I wish to go down. I prefer simple. I think adding a flag (sorry if I use the wrong term sometimes. I am self-taught in programming and don't often have the opportunity to discuss programming!) into a preset that says "This preset is in use elsewhere. Do you really wish to save this new data?" is the simplest solution and let the user deal with the complexities.

Given this, I'd like to handle all the presets myself and tell the host there's only one, like many other plugs do. I've just been trying to see how they do it.

[PurpleSunray]

Do you really wish to save this new data?" is the simplest solution and let the user deal with the complexities.

Add a version control system.
It's one of the tools I miss most when switcing from software dev role to music producer role: a version management system.
Something like a svn or git, not for for text file, but for plugin presets.
With a nice graphical diff-tool that shows what has been change between versions, merge two presets with confilciting settings into a new one, restore old .. branch off for a new track .. ect pp

[syntonica]

And those work so well for programming...

I'm still waiting for any arguments about NOT making preset management a singleton. I think a flag with In use and Changed will be fine to handle multiple instances and the rare preset collision.

I have to start teasing out some code since all my classes seem to be reaching into each other's pockets right now. Now that I (mostly) understand what I'm doing, it should be easier.

[Mayae]

And those work so well for programming...

I'm still waiting for any arguments about NOT making preset management a singleton. I think a flag with In use and Changed will be fine to handle multiple instances and the rare preset collision.

I have to start teasing out some code since all my classes seem to be reaching into each other's pockets right now. Now that I (mostly) understand what I'm doing, it should be easier.

Well are you really going to make destructive presets the default? Usually the presets are read-only, when you load one you can make any changes you want in your instance without it affecting any other instance. If you want to overwrite the default instance, you can choose to do so manually via some menu.

[syntonica]

I think I will have the "working preset" as a copy in use. But if it changes, it will ask if you wish to save and then, if in its original slot, verify there are no other instances of that preset open. As well, I won't have to worry about one instance changing things in the background with no other instances knowing.

[martin_l]

I am thinking about the same issue at the moment. Clearly, there are many approaches out in the wild already. Those who hold the whole bank in memory and store it with the project (standard VST approach) and those having a database (sort of) on disk (for instance the Arturia plugins).

If you assume that an given instance of an instrument only plays one patch throughout a project, it does not really matter what you do, as that patch will be stored in the project in any way.

The problem starts when you allow program changes e.g. through MIDI. In order to be fully consistent, you would have to store the whole bank with the project (which has the side effect that it can lead to HUGE undo-history files).

As program changes via MIDI is important for life performances, I definitely want to enable that. My current thoughts are:

• Keep a data base of patches on disk
• The plugin has a bank of programs (usually 128).
  
  • On first load this bank will be filled with a default selection.
  • The user can (via menu) fill that bank by choice.
  • Program Change will select from this bank.
• The internal bank is stored with the project.
• The user can save patches from the bank to the global database, with the choice to either overwrite or save as new.

I do think some Arturia plugins use that (e.g. Matrix 12V) but I need to check exactly how they behave across different projects.

Would such approach make sense?

Cheers,
Martin

[syntonica]

I finally went with a working preset and a singleton bank shared by all instances and will just let the end-user worry about saving their working presets into the bank if they have changed. I'm not too keen on the DAW storing entire banks. I think just the preset in use is plenty as you don't want to open up an old project and accidentally start storing old presets all over your new ones. As long as the ones in use are saved for posterity with my project, I'm a happy camper.

I suppose you could go all MySQL on things if you wanted a more robust patch browser able to search, tag and sort. But I chose simplicity over utility. I try to avoid dependencies where I can. It's bad enough trying to keep up with language dependencies! Right now, the minimum OS for my VSTi is 10.7, and that's because I am using C++-11 got a couple of conveniences, which apparently refuse to compile/run for 10.6 because... Apple.

However, I'm still in the learning process and have been cramming C++, Objective-C, DSP, VST and am about to throw AU and Windows onto that pile, as well. My follow-up VSTi will be lean, mean AND full-featured! As soon as I get an idea for what I want to do next...