Sometimes older projects which have used JBridged VSTs, or even VSTs that are named differently lose the settings if you replace it with a new VST the normal way.
Just like looking for missing media, it would be very nice to be able to replace it with the same VST as shown in the plugin list.
ie PLUGINname_x64.dll not found could be replaced with PLUGINNAme.64.dll or if it’s just named PLUGINNAme.dll now while keeping the settings.
Some really old WAVES, Kontakt plugins which didn’t have 64bit versions which now do have 64bit versions were used through JBridge. I need to replace these with the newer 64bit versions without losing the presets/parameters…etc.
yeh, would be Handy if we could draw automation lanes WITHOUT assignment to any plugin Parameter and later (re)assign it, opening up the possibility to preserve Automation data on deleting/replacing a plugin instance.
however, replacing plugins while keeping Automation can currently be done by adding the new plugin instance, then copying Automation data from the old to the new plugin Parameters, then deleting the old / replacing with the new plugin.
I’m guessing this would be a possibly tremendously difficult task to accomplish. At the very least each plugin would probably have to be verified to have the same parameters working the same way. As soon as one of them isn’t working the same way it’s a potential problem. So then the question is how would Nuendo know that the parameters are actually the same. Just based on name? I obviously don’t know enough about programming but I would guess that might not be enough and I’m guessing there’s more to a plugin’s “identity” than its name.
So I think this would just be very difficult to accomplish. I don’t oppose it though.