Can Steinberg work on the problems with VSTs and WL and do it soon?

More and more problems with VST3 plugins and WL.

Since Steinberg “invented” the VST plugin it would seem that any of their programs should not have problems with VSTs.

I can use all of my VST plugins in Audition, Reaper, Samplitude and Sound Forge and even video programs like Black Magic’s Da Vinci BUT I cannot use some of them in WL. I really don’t understand the problem???

IMHO, this VST problem has been going on for years and should be fixed before any other “updates” are considered.

1 Like

It all comes down to plug-in developer testing and if they can devote resources to making their plug-ins work correctly in WaveLab, but I have suggested that Steinberg do more outreach to developers of mastering focused plug-ins to help advocate for better testing and support of WaveLab for some of the more popular and useful ones.


BUT!!! Why does WL have so many problems with VST plugins??? If Steinberg created VSTs then shouldn’t their programs work with them??? all of them??? What is it about WL that is so different from other mastering programs??? FWIW

1 Like

I think @Thomas_W_Bethel has a point actually.

While it seems to be the case that even high end coders and developers need to test their plugins in WL, I have to say that even that no longer seems to be an assurance of complete compatibility. Recent cases in point in my world include DMG and Voxengo … both of which ‘worked’ (and still do) in WL 11.2.

Further illustrating this was your list in another thread of only about 12 developers that were prepared to allocate scarce resources to WL testing and adaptation (although there are probably more).

A few versions ago, that list was almost certainly much longer. Waves for example no longer seem to support WL (*18bifhi*_up*MQ..&gclid=Cj0KCQjwwYSwBhDcARIsAOyL0fgmDAyf8Nl4A9aWYfh_YFQTOoaqFNW15MoqhRtY_QIeTPL1ymoR47AaAtGHEALw_wcB#version-14*18bifhi*_up*MQ..&gclid=Cj0KCQjwwYSwBhDcARIsAOyL0fgmDAyf8Nl4A9aWYfh_YFQTOoaqFNW15MoqhRtY_QIeTPL1ymoR47AaAtGHEALw_wcB#version-14.12 … but these are supported and even work in chronically under resourced Sequo*a).

My genuine concern is that this list will become progressively smaller and smaller as the ‘why bother’ factor for developers starts to creep in every time there is an update hurdle to overcome.

I completely understand that WL is not Avid, but this is also the point: if WL is unaccommodating to top flight, well coded plugins the economies of scale just won’t work for typically small plugin developers where it’s all about allocation of resources and funds.

Anyway … this is not my problem and things are what they are but I make the observation that moving forward is probably a two way street.

1 Like

Well stated. Maybe instead of coming up with “a new and improved” WL the developers should tackle the VST plugin problem once and for all…??? More and more mastering engineers are finding out how GREAT Wavelab for mastering but then have problems with not being able to use their favorite VST plugins with WL. Not a good situation.

There have been ‘issues’ with plugin incompatibilities with WL for many years but the problems are invariably on the plug-in developer side. IMHO it might be unrealistic to expect that SB should allocate resources to sort out problems caused by other developers. Personally, I feel that Steinberg doing more outreach to developers of mastering focused plugins as suggested by @Justin_Perkins should be enough.

My own experience is that any plugin which had issues with Wavelab has always been found to be faulty on the plugin developer side. Any reputable developer I have contacted with regard to a problem has always corrected the issue fairly rapidly. So maybe I’ve been lucky but zero issues here. And TBH if a developer can’t be bothered to test in Wavelab then I simply don’t use their plugins.

@Thomas_W_Bethel what are the VST3 plugins you are referring to which have issues in Wavelab 12?

Yeah. I mean, I’ve done my fair share of reporting issues to plug-in developers to fix issues with their plug-ins in WaveLab over the years. It led to beta testing for over a dozen plug-in companies at one point in time. I don’t have time for that these days.

These days, I have a core group of plug-ins I stick to that I know I can trust in WaveLab and if a new one comes along that I really want to use but has a WaveLab issue, I reach out to the developer to see if they’re willing and able to fix the issue so it can be used in WaveLab.

I have a rendering test montage saved where I stress test certain things before I even consider using a new plug-in on a real mastering project.

There are a handful of plugins with known issues I’d like to try such as McDSP but I just don’t have it in me to go through the process of reporting stuff and hoping it gets fixed. It could just be another NUGEN situation where I spend a bunch of time reporting stuff only to never see a valid fix.

I would say that an easy majority of plug-in developers I reach out to these days are quick to respond and fix issues, and it’s usually the smaller one-person ones. It’s the bigger companies that seem to have too convoluted of a support/development team to really focus on things like this and sometimes are uninterested or unable to fix any WaveLab related bugs in their plug-ins.

All that said, if I were Steinberg I would provide better documentation and help that encourages plug-in developers to code close enough to VST3 spec that we don’t have so many 3rd party plug-in issues in WaveLab.

It’s usually the same basic issues:

  1. No Processing On Rendered Audio, But OK on Playback
  2. Audio Fade-In or Glitch at Start of Rendered Audio
  3. GUI Issues
  4. General Performance Issues/CPU Hog

I don’t see how those issues can be avoid without explicit testing in WaveLab which is clearly not a priority for all plug-in developers and they just assume that if their plug-in works in Cubase it should work in WaveLab.

The circle of blame and expectations just keeps on going.


My point is if it works in most/all of the other “mastering/recording” DAWs why doesn’t it work in WL??? There has to be a reason that a plugin does not work in WL if it works elsewhere…What is that reason???

You might not like hearing this, but there are no known bugs in WaveLab concerning the VST-3 implementation. In other words, there is no known case where a plugin doesn’t function correctly in WaveLab due to an error in WaveLab’s VST-3 implementation. I’m still waiting for a plugin developer to report something along the lines of: “The VST-3 specification states the host should do this, but WaveLab does it incorrectly.”

If a plugin doesn’t behave as expected with WaveLab, I have no way of knowing what’s happening inside the plugin. Therefore, the only resolution must come from the plugin developer.


I believe what you are saying is correct. I just find it hard to understand why a VST plugin will work in every other DAW except WL. There has to be a fundamental flaw in the implementation. If the VST plugins works in 4 or 5 other DAWs then something is inherently wrong with the way WL handles VSTs. The question is why???

I have loved WL since version 1.6.2 and still think it is the best mastering/restoration software available and I use it everyday. I just wish it could handle more VSTs from different software developers. FWIW

1 Like

That’s a pretty strong generalization. Plugins have bugs in other DAWs too. You don’t see it as much in the big ones like Pro Tools, Logic, & Cubase because they are more heavily tested and reported on but the lesser used and lesser tested ones tend to have more bugs due to lack of testing and resources.

Ask anybody that has used Sequoia, SoundBlade, SADIE, Pyramix, etc. Those are some lesser tested/reported DAWs and prone to a similar amount of 3rd party plug-in bugs as WaveLab. It doesn’t matter that Steinberg invented VST, it depends on how the plug-in is coded and if it’s tested in a specific host or not.

Even REAPER which on Mac can host AU and VST versions can have a situation where the AU version is OK but the VST version is buggy or vise versa.



I very much appreciate you clarifying this. I really do.

That completes the picture for me.

Thanks again.

I’m pretty heavy on Waves plugins here, Paul, and without issue in WLP12. Izotope, as well, and I recall they weren’t tested/approved by iZotope in WL in days past. I use UA, UVI, Sonnox, Sir Audio, Liquid Sonics, Voxengo, Baby Audio, Melodyne/Studio and a few other brands, too. Maybe I’m just running with main stream plugins but I was actually thinkng that the VST3 architecture is working really well, in Cubase and WL.

Thomas, if you’ve got a VST3 there that doesn’t work in WLP12 and it has a trial download, could you tell me which one it is? I would be happy to try it here and report back.

Hey … my comments were intended to be a general observation in nature.

Those comments are also redundant in the context of PG’s explanation.

For the record, I too only use a handful of fully supported plugins most of the time: DMG, Sonnox, Voxengo … I also have another half dozen or more different limiters as well but they all seem to work flawlessly with WL

1 Like

What plugins are you referring to that are crashing? I’m on Windows 10/11 using Cubase 13/Wavelab 12. So far I’m using Acustica Audio, Slate Digital, UAD, IK multimedia, Waves etc.


The plugins from various manufactures but right now I am having problems with NUGEN plugins. This is a long running problem with NUGEN plugins going back as few years.

FWIW, I’ve never had a real problem with plugins not working in WL. But, I’m not using Nugen or anything all that much out of what I’d call the ordinary (Fabfilter, TDR, Tone Projects, iZotope, UAD Native, Klanghelm, Pulsar, Sonnox, Brainworx, etc.).

I actually did have a problem with Sonnox ListenHub loading other plugins when I tried to use it, but it didn’t work standalone either. So, that wasn’t a WL issue.


I’m happily switching from a very long time with Sequoia to WL12 for mastering and the move is nearly complete. WL really is making my mastering life a whole lot easier.
But the VST3 issue keeps Sequoia as an alt. DAW at the moment just so that I have the choice: some that work in WL do not work Sequoia (which is now also randomly changing settings as playback starts) but there are now two, fairly central to my work - Tokyo Dawn Nova GE and Schwabe GoldClip which work fine in Sequoia but are crashing WL every time. TDR is odd as it worked last week on a full project but is now crashing as soon as it’s accessed. I’ve notified the plug-in developers but as Sequoia works I suspect that they’ll suggest pointing fingers elsewhere to begin with.

That said, WL seems to me to be more stable generally than Sequoia - and speedier and smoother too.

1 Like

Just a positive update on those two rogue plug-ins: Schwabe got on the case and have release V1.2.4 which fixes the GoldClip issue, and TDR Nova GE somehow woke up and got back to work after I rolled back to the previous version and then forward again to the current version. All good.


Hi there,
as being said, the depedency for correctly working 3rd party VST3 s inside Wavelab is directly connected to the VST3 vendors and their compatibility with the host. We always recommend to the customers to have the latest updates for each 3rd party plugins installed to make sure that the version runs without problems…


1 Like