I have a customer who uses WaveLab 11 with Apple Silicon Mode.
His older Montages were made with VST2 Versions of my plugin (on non Silicon WaveLab).
When he loads the project in the new Apple Silicon Wavelab, it seems WaveLabs doesn’t map the old VST2 instances to the new VST3, he have to manually select the plugin form a list, and all settings are gone.
So VST2 is not supported anymore, WaveLab should automatically choose the VST3 version of the plugin.
VST3 Version of my plugin is configured to be compatible VST2 (uses JUCE_VST3_CAN_REPLACE_VST2-Flag from JUCE Framework) I tested this successfully with other hosts (incl. Cubase 11/12).
Is this automatically replacement of VST2 known to be working in the latest WaveLab Version, or is this a bug?
PS: Can this somehow forwarded to the Wavelab Developer Team, I have the customers montage here, so we check what’s going on.
Cubase was able to automatically replace the VST2 plugin with VST3 version, so I guess this is bug in WaveLB (Saved with the VST2 Version of the plugin in Cubase 11, loaded the project in Cubase 12 with VST3 version of the plugin, same state was applied)
In WaveLab, there is no automatic conversion from VST-2 to VST-3. This is not supported, simply. But of course, as mentioned in the original mail, this can be done manually but the user.
I doubt that the hosts that support automatic conversion can convert the plugin settings from VST-2 to VST-3 reliably (when there are private parameters). Hence there will always be manual tweaking at the end.
no automatic conversion from VST-2 to VST-3. This is not supported, simply
The result, of course, is that all customers who switch to Apple Silicon lose their entire vst2-plugin settings. These customers then contact the plugin manufacturers and create support effort.
You may say the solution is to switch to the Rosetta-mode, but then again, people will remain use the VST2 versions, and depend to rosetta forever (and apple may cancel rosetta at some point)
If Steinberg wants the people to move to VST3, there should be a simple way to make this transition as smooth as possible.
I doubt that the hosts that support automatic conversion can convert the plugin settings from VST-2 to VST-3 reliably (when there are private parameters). Hence there will always be manual tweaking at the end.
As most juce-plugins, my plugins store every parameter also in the binary state, and correctly restore the parameters 100% exactly.
Also, last-time I checked it, the automation was restored correctly in Cubase and Studio One when switching from VST2 to VST3.
What I find amazing is that Steinberg has provided a way to provide upward compatibility.
But its surprising that a Steinberg host itself doesn’t support this.
I would reconsider the matter.
For now, I will recommend customers to use the Rosetta version.
As a WaveLab user, I’ve been using VST3 (wherever possible) for a decade for this exact reason.
It was implied awhile ago that VST2 will be dead someday and we are getting to that time period now.
This is also why I weaned myself away from plugins that never added VST3 versions, such as UAD and a few others. It’s my opinion that there has been plenty of time to make VST3 versions so now is not a time to complain.
I don’t remember specifically but when Pro Tools changed from RTAS to AAX, did Pro Tools transpose the settings?
In the meantime, Apple Silicon users can run WaveLab 11.1 in Rosetta mode so VST2 plugins become available, for now…
Concur completely with Justin. It’s not Steinberg’s responsibility to automatically make changes to any user project files.
Even if I was a Mac user and was presented with this scenario - I would never allow a vendor to make arbitrary plugin substitutions to my work - regardless if “they” (vendor) thinks its a good idea.
Furthermore - Steinberg has very clearly told the whole world that VST2 is disappearing and to get on the case and consider VST3 where applicable. That’s why I have done as Justin has - and dropped VST2 wherever I could - years ago.
But that change (VST2->VST3) is on the user to figure out and to manage.
I am seriously doubting this as well - you would have to ensure that the Cubase 12 test is done on a separate machine with NO VST2 plugins installed whatsoever for this to be even remotely possible.
Finally- I am a Studio One user and can confirm it does not automatically do any VST2->3 substitution that I can see. If I have a VST2 in a project , delete the VST2 plugin from Studio One and then reopen the project - even with just the VST3 version of same plugin installed - Studio One immediately complains about a missing plugin.
First of all, Steinberg somehow unified all forums and merged the developer forum with their customer forum. I intentionally posted this in the VST3 Developer sub-category (somebody changed it to wavelab, again)
can confirm it does not automatically do any VST2->3 substitution
This is an opt-in from the plugin developer perspective, its a possibility. Both Cubase and Studio One (not tested other hosts) support it, last time I checked it. If the VST3 use a different ID it does not work.
Anyway If the current situation is Wavelab/Steinberg desired user experience, I am absolutely fine with it.
I actually wanted to report the behaviour to Steinberg developers, because I thought this is actually a bug in WaveLab because the transition doesn’t happen automatically (like in Cubase), I wasn’t aware this is intentional. If you are happy with it, great! Others have definitely issues with it (as I told above)
Is there an easy way to tell if a plugin is VST2 or VST3? I seem to remember this question came up a while back but I cannot find any info on it. Thanks in advance!!!
Thanks for the info. I spent some time yesterday putting the VST2 dlls into a seperate folder which I will keep on my NAS. Appreciate the help as always…