Does Wavelab 11.1.10 Silicon automatically replace VST2 with VST3?

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.

What are you talking about? Silicon WaveLab?

I changed the category to Wavelab…

I posted this in the Steinberg VST3 developer community. Please revert your change.

BTW If try to reconstruct the issue with my own generated VST2 Project, WaveLab Trial Version simply crashes.

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed::  Dispatch queue:
0   libsystem_kernel.dylib        	       0x1a3ab6d98 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x1a3aebee0 pthread_kill + 288
2   libsystem_c.dylib             	       0x1a3a26340 abort + 168
3   libc++abi.dylib               	       0x1a3aa6b08 abort_message + 132
4   libc++abi.dylib               	       0x1a3a96834 demangling_terminate_handler() + 52
5   libc++abi.dylib               	       0x1a3aa5ea4 std::__terminate(void (*)()) + 20
6   libc++abi.dylib               	       0x1a3aa5e2c std::terminate() + 44
7   WaveLab Pro 11                	       0x101becb50 0x100708000 + 21908304
8   WaveLab Pro 11                	       0x100acc324 0x100708000 + 3949348
9   WaveLab Pro 11                	       0x100a63ac0 0x100708000 + 3521216
10  WaveLab Pro 11                	       0x100fd6c68 0x100708000 + 9235560
11  WaveLab Pro 11                	       0x101017e5c 0x100708000 + 9502300
12  QtCore                        	       0x104fb4540 void doActivate<false>(QObject*, int, void**) + 1016
13  WaveLab Pro 11                	       0x1022030e8 0x100708000 + 28291304
14  WaveLab Pro 11                	       0x100fe5e6c 0x100708000 + 9297516
15  QtCore                        	       0x104fac80c QObject::event(QEvent*) + 596
16  QtWidgets                     	       0x103e3b570 QWidget::event(QEvent*) + 4132
17  QtWidgets                     	       0x103eceffc QFrame::event(QEvent*) + 56
18  QtWidgets                     	       0x103e04838 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 292
19  QtWidgets                     	       0x103e05bd0 QApplication::notify(QObject*, QEvent*) + 548
20  WaveLab Pro 11                	       0x102006b00 0x100708000 + 26209024
21  WaveLab Pro 11                	       0x1009bfb1c 0x100708000 + 2849564
22  QtCore                        	       0x104f83dc4 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 208
23  QtCore                        	       0x104f85088 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 864
24  libqcocoa.dylib               	       0x10642a2f0 QCocoaEventDispatcherPrivate::processPostedEvents() + 312
25  libqcocoa.dylib               	       0x10642a9b0 QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) + 48
26  CoreFoundation                	       0x1a3bb9044 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
27  CoreFoundation                	       0x1a3bb8f90 __CFRunLoopDoSource0 + 208
28  CoreFoundation                	       0x1a3bb8c90 __CFRunLoopDoSources0 + 268
29  CoreFoundation                	       0x1a3bb7610 __CFRunLoopRun + 828
30  CoreFoundation                	       0x1a3bb6b34 CFRunLoopRunSpecific + 600
31  HIToolbox                     	       0x1ac7f6338 RunCurrentEventLoopInMode + 292
32  HIToolbox                     	       0x1ac7f5fc4 ReceiveNextEventCommon + 324
33  HIToolbox                     	       0x1ac7f5e68 _BlockUntilNextEventMatchingListInModeWithFilter + 72
34  AppKit                        	       0x1a671e51c _DPSNextEvent + 860
35  AppKit                        	       0x1a671ce14 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1328
36  AppKit                        	       0x1a670efe0 -[NSApplication run] + 596
37  libqcocoa.dylib               	       0x1064297c4 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 1768
38  QtCore                        	       0x104f7fe9c QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 524
39  QtCore                        	       0x104f843f0 QCoreApplication::exec() + 132
40  WaveLab Pro 11                	       0x1009acdc0 0x100708000 + 2772416
41  WaveLab Pro 11                	       0x1009a9c98 0x100708000 + 2759832
42  dyld                          	       0x1033c908c start + 520

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)

It’s a question related to Wavelab. I doubt that you will get an answer from PG in this case…
He is reading the Wavelab forum very carefully.

But it’s up to you.
If you know it better…

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.

Thanks for the prompt clarification.

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.

So I am not sure what you are seeing.


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)

Thats all I have to say, good night!


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!!!


Not stupid Q…

Go to…

File > Preferences > Plug-ins
Find tab “Organize”
press “Expand”
and scroll to
File Name
and you should see VST or VST3 in path name for each plug-in

regards S-EH

at the dropdown where you add plugins, you see a symbol indicating a VST3 plugin

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…