Handling saved state for new plugin versions

Audio Plugins
1

I am developing an application which hosts plugins, and for persistence stores the opaque plugin state as part of the project file.

This works just fine when loading the project file on the same system from which it was saved. But I wonder what happens if it’s loaded on a system where the plugin has a different version installed. There’s no way that I can see to assure that the saved plugin state is compatible.

Grateful to know how others handle this - is there a common pattern for this situation?

2

That’s really up to the plug-in to handle correctly. Only the plug-in knows how to load and save its own state.

1 Like
3

Well that’s what I’m wondering - I guess I just need to handle if a plugin fails to load when passing it the stored state, re-initialise it and inform the user.

4

Current Plugin APIs as I know pass a ptr to a binary object for the plugin to read or write.

You as the host is just the proxy. As stated the plugin side should take care of storing or loading their data while you (the host) only in charge on when to load/save and keeping blob provided by plugin.

You have no way as far as I know with current APIs for the plugin to tell you what it decided to do.

Except of avoiding external code crashing your DAW (sandbox process) I’d avoid guessing the load state which is on the plugin side.

Some formats provides a Boolean of load/save result (eg CLAP) you can consider supporting but it’s still depends on the plugin side.

5

Restoring a plugins internal state (and handling failure) is not the DAWs responsibility. It is the plugins.

6

Sure, but I need to do something if it fails. I guess something like identify the recall failure, bypass the plugin and alert the user.

7

unless the corrupted state crashes the plugin, you wouldn’t even know that something didn’t work. the plugin then likely just loads in default state or gets some details a bit wrong

1 Like