Allow Generic Editor when plugin could not be found

Unfortunately when some plugin developers update their products backwards compatibility in Cubase is lost. As I understand it, it boils down to a change in plugin VST ID which results in Cubase seeing the two versions of the plugin as two unrelated entities.

I would like to suggest the ability to open the not found plugin with the Generic Editor so the user at least can manually recreate the plugin settings in the updated version. This should be technically possible since Cubase stores all the plugin parameters in the project file.

1 Like

Hi, I don’t think that is technically possible. While Cubase does save plugin parameters on session save, it is only the raw values, and not the parameter names or any other info that would be necessary to show a generic editor.
Most third party plugins will probably save their state as a chunk of memory anyway that only they know how to interpret, the host has no chance of knowing what it what.

Hi,

How could Cubase know the parameters, which should be available in the given plug-in, if the plug-in is not there?

Cubase stores the VST Parameter values for every plugin in a project.

I think you’re wrong. You can save a .vstpreset file from a plugin that is missing. Part of the .vstpreset file includes the parameter names and “raw”/normalized values.
Even if the parameter units are lost, displaying the normalized value would be better than nothing.

You are right in the case of very simple plugins that just directly save their limited set of vst3 parameters in order. But this will be pretty much only Steinberg’s own Effect plugins. All other plugins, even Steinbergs Groove Agent, don’t do that but store a memory chunk that only the plugin itself knows how to interpret (because they need to save additional data like gui states, maybe file paths or whatnot which is not representable with vst3 params). Just have a look at some vstpresets from third-party developers, and you will see xml data, binary blobs or json data. No way a host can interpret that.
Edit: Actually, I am pretty sure the parameter names you see in the vstpresets of Steinbergs effect plugins are written by the plugin, not by the host in any way. The host just passes a pointer to a Stream object and happily will persist whatever the plugin decides to write to that
https://steinbergmedia.github.io/vst3_doc/vstsdk/classSteinberg_1_1Vst_1_1SingleComponentEffect.html#a244b615a88bc3b9ef68b30ba63fcb662

I only tested with 3rd party plugins and half of them stored parameter names in human readable format. It seems to me, some of what you’re writing at this point is only guesswork.

My FR still stands. If you think it’s a bad idea, that’s fine. Don’t vote for it.

i think this is a good idea to display a generic editor view who shows the stored values (if there are any), also seeing the preset name of the original preset that was used would be a good starting point to recreate.
but i have no idea if and how this is technically possible or not, but you have my vote for it :slight_smile:

1 Like

I think plugin devs should think very hard about changing this small value. And if changes to the plugin necessitate a change in ID then perhaps they should change the file name also, so that it can co-exist with the previous version.
How hard is that?

2 Likes

I agree. I honestly don’t know if the problem manifests itself differently in other DAWs and that would be a reason it is getting overlooked.
Nevertheless, it’s an issue I’ve run into countless of times over the years and it’s a proper pita every time.
I don’t think it would be very hard to implement some mechanics that would ameliorate the situation when it inevitably does occur.

1 Like

I don’t think it is a bad idea, I am just pretty convinced that it is not technically possible. And that is not based on guesswork, but by a) looking at several .vstpresets and noticing how massively differently the data inside those looks and b) reading the VST3 SDK (and some plugin source code) and understanding how the setState() and getState() methods work.

I fully agree though that the problem with missing plugins is a PITA. I have several Plugins where I need to still keep the VST2 version because the VST3, even if it is the same release version, is not able to replace the VST2 automatically. This is most often an oversight of the plugin developer, because the method for doing so has been in the VST3 SDK forever.
In such a case, Cubase could offer the replace the missing plugin with a new one selected by the user and call the setState-method with the saved session data. Maybe it works, in the worst case the plugin and Cubase crash :grin:
But my guess is that Steinberg won’t do anything about it and claim that it is simply the responsibility of the developer.

1 Like