This is more a request for confirmation than anything. I like to save plugin presets using the GP wrapper. Saves starting from scratch every time I use the plugin in a different rackspace.
I just set up a gig. I put in a reverb plugin, Nexcellence by PSP. There are VST and VST3 versions of the plugin. I added the VST3 version to a rackspace. Modified it to my liking and saved it as a preset using the GP wrapper. So far so good.
The VST3 version of the plugin takes quite a while to open, so I decided to remove it and added the VST version. I opened the preset browser to add import the preset data into the plugin. The preset file I saved when using the VST3 version of the plugin had disappeared.
Now I suspect that for very good reasons, GP saves presets for VST and VST3 separately. It is very rare that I switch from a VST3 to a VST version of the same plugin. Can I assume this behaviour is normal? I probably answered my own question…but thought I’d check.
Please forgive me for asking what must seem obvious. I should add that I checked for previous comments.
VSTs and VST3s are totally different formats. You cannot load the state of the former into the latter or vice versa.
Your saved plugin state is not gone, it’s just that we take into account the kind of plugin being saved to determine the location where we save state so that things don’t get mixed up. If you inserted your VST3 plugin again and tried to load its state, you’d see the originally saved state in the file system.
Yeah, I came to the conclusion that the state of the two formats would not be compatible. Now for effects plugins with relatively few parameters, this is not as much of an issue. However, say I create a B3 emulation (choose the plugin); there will be a lot of parameters that need to be (re)set.
I copied a rackspace and changed a B3 emulation from VST3 to VST. As you pointed out, I was unable to load the VST3 preset that I had created. OK. But I was able to import its state which I had saved in the plugin’s internal routine.
As you would know far better than I, most plugins are able to save their states internally; and are able to load those states into a VST and VST3, plugin. I am not suggesting you could do the same
Perhaps this is all just a result of my own stupidity (well not maybe), but it might be worth writing a blog entry. In it, you could suggest that, where there are plugins of both VST and VST3 versions, and there’s a chance of migrating from one to the other; the folks should save the state of the plugin using the plugin’s internal file system, so that if they had to change the format, they wouldn’t have to start over with parameters. They would be able to import the plugin state using the internal routine and then save the gig and/or save the plugin state in the wrapper.
Your product is as good as it gets, and so are its developers. Thank you for taking care of us.
