I work on a plug-in that can host other plug-ins and have just come across an issue particular to hosting Waves plug-ins.
When my host plug-in is restored from a DAW session it has been saved in, it tries to re-load it’s own hosted plug-in from the DAW’s session data where I have stored the juce::PluginDescription (along with all the parameter values etc.).
The problem I am having is that if a Waves plug-in, say Waves EV2 is part of a shell with a PluginDescription::fileOrIdentifier like WavesShell1-VST3 15.10_x64.vst3 and this file name is stored in the DAW’s session data, and a user updates to Waves 16 with a new file name e.g. WavesShell1-VST3 16.10_x64.vst3, the juce code inVST3PluginFormat::createPluginInstance will fail to load the plug-in because the file name has changed.
This is not a problem with most other plug-in manufacturers as the file name generally stays the same when the plug-in is updated.
I have 2 questions about solving this problem:
-
Has anyone else who works on a plug-in host come across this issue before and come up with a reliable solutions. My first instinct is to try iterative string manipulations to try and find a file which does contain the plug-in I am looking for, but this seems a bit rough and prone to errors.
-
Does anyone know how the Waves plug-ins are ordered within the shells, will EV2 always appear in in the same shell e.g. 15.10, 16.10 17.10 etc or if the user only over has one Waves plug-in EV2 will it appear in 15.0, 16.0, 17.0 etc.
Any guidance on this issue would be very gratefully received ![]()
