Despite other hosts on the same machine having no problems with the same plug ins in VST format, WL9Pro keeps crashing on many plug ins with 9.0.35 on OSX 10.11.6. I just got the newest version of Exponential Audio Phoenix Surround 2.02 and WL crashes just by hitting play with it. SIR StandardClip shows redraw problems when the GUI is over 100% resized.
There are so many problems with WL9Pro and plug ins I cannot keep track anymore. I must have nearly 800 plug ins (all legal of course) and use probably around 100 regularly for sound design, restoration and mastering purposes. Many fail in WL9Pro. WL9 is a very unstable platform for me - and I cannot get it running smoothly in OSX. I have two more licenses of WL9EL on a Win 7 and another Mac with 10.11.6.
Not having the massive problems you are having but WL 9 does seem to have a lot of plugin problems. WL does not seem to play nicely with external plugins in general. GUI problems, plugins that don’t start correctly or stutter etc. etc. yet those same plugin work well in Samplitude, Sound Forge and Adobe Audition so I assume it is not the plugins that are the problem. I have friends who use CUBASE and they don’t have the same problems. Maybe the WL team should have a meeting with the CUBASE folks and find out where the problems are…Just a suggestion.
Thank you, Thomas. You describe exactly how it goes here. I was very positive when WL9 appeared with the new GUI, except it lacks full surround capabilities, but I always hit walls with it when using plug ins with WL9Pro and got tired to report everything - it would have been the duty of the beta testers to do this. And it is always the same game: PG directs to the plug in developers, claiming he is up to the specs, they’re doing something wrong. If that is true, then I accept them doing ‘wrong’ as the plug ins are running fine in other hosts, even from Steinberg. I’m a very good Steinberg customer I think, having Nuendo, three Cubase installations, three WL9Pro/LE and two Halion licenses. WL9 is always problematic with plug ins at some point: lagging reaction with plug ins (on a MacPro!), blank windows, crashing, like recently with Phoenix. All the same plug ins run fine in Neundo and Cubase on exactly the same machine! The most stable WL ever is still WaveLab 6, which I run on my Win 7/64 machine alongside my Macs. And because of WL9 fails I always went back to other editors to get the jobs done. I’m very disapointed with the WL9 situation as it is right now.
Yes, I too am not thrilled that some Slate plug ins do not work right in WL, but they work just fine in Logic Pro, Twisted Wave, etc.
This has become an epic battle. I’ve ended up becoming a beta tester for at least a half dozen plugin developers because of issues I’ve reported with WaveLab. The blame game is annoying. In all the reporting I’ve done, only a few times has a party owned up an acknowledged and fixed the issue. Before WaveLab, I came from Pro Tools world where plugins were basically 99.9% stable IMO. I can’t even think of one recurring plugin related issue in all those years.
I’m not sure what the deal is with VST but something isn’t right, or as good as it can be. Do we need VST 2.4 and VST3? How about just VST “Stable”? LOL.
I’ve had a long-time issue with certain plugins causing a crash during or at the end of a render process. I’ve spent hours and hours and hours providing PG and plugin developers with a directly reproducible case and I can’t. Every time I try to avoid a plugin suspect of causing the crash, a new plugin still instigates it.
I really think one main issue why we have plugins crashing WaveLab more than Cubase is because WaveLab has clip plugins, as well as track and montage master etc. In most DAWs, you only have track plugins and not clip/item plugins. When I use the same mixture of plugins only inserted on the montage output, I never see this render crash. As soon as I start inserting plugins on a few clips, then I often see crashing durning or at the end of a render process.
I’ve actually restructured my workflow around some of these rendering crashes and other minor rendering issues. It has helped but sometimes I wonder how great it would be if we didn’t have to dance around numerous plugin bugs update after update.
Lucky for me, most of my work is done in REAPER with plugins and analog gear, and I’m just relying on WaveLab for final sequencing, a final limiter and dither in the montage output section, and then all the PQ coding that WaveLab is so great at.
Now and then I end up mastering a project 100% in the box in WaveLab and that’s when I’m more likely to see a crash.
I wish WaveLab for Mac would offer AU and VST support like REAPER does because then you at least have a chance to install AU versions when VST versions fail. Maybe that would help.
I’ve said it before, but I think for most plugin companies, they don’t have the time and resources to fully test WaveLab so they test Cubase only and assume that WaveLab will be OK if Cubase is OK because Steinberg makes them both which all of us here know is not true.
The GUI issues and magnetic mouse issues are also curious. I know basically nothing about software coding but it seems like you’d almost have to try to purposely have so many GUI related issues.
I wish something about the VST integration of WaveLab could be rewritten to provide more stability. I don’t care if it’s technically the fault of the plugin, or WaveLab…but why is it so hard to figure out what the problem is time after time.
Anytime I see a new plugin, I give it a 33.3% chance of actually working correctly in WaveLab. Most times, especially with the smaller plugin developers, there will be either a GUI issue or the issue where the plugin works on playback but doesn’t work on rendering processing…or in the case of NUGEN, just trying to open the GUI will crash WaveLab.
The bottom line, WaveLab is way more sensitive to 3rd party plugin discrepancies than any other DAW I’ve heard of. If it can’t be improved, maybe Steinberg can make a VST compatibly tool that plugin developers can effectively use to stress test their plugins to find simple or deep issues. I think us WaveLab users have done their fair share of beta testing.
Thank you, Justin P, you sum it up very nicely. And I haven’t even dared to use something else than the master insert plug ins. WL9 gave me so many problems that I don’t even go further than simple file editing with it. The biggest benefit I got so far is to use the interconnection of WL with Cubase and Nuendo. But I’m afraid to use most plug ins then. I’m so fed up with these problems. WL9 is really not up to the tasks.
Would it be fair to say that these issues predominately appear on OSX?
In a word NO. I have them with Windows 7 Pro as well.
There is something inherently wrong with how WL handles VST plugins. It has been with users for years.
Since WL and CUBASE are both Steinberg products it would seem “natural” to me that the developers of both would work together to find the cause of the problems in WL. It seems that is NOT the case and they work independently and seemingly never work together to solve the problem. I love WL and have used it since version 1.6 but the plug in problem drives me crazy. My NUGEN plugins run fine in my other DAWs but sometimes work and sometime don’t work in WL.
Maybe it is time for the “big wigs” at Steinberg to get involved and get this problem solved once and for all. it has been going on way too long. FWIW
I think the issues run as deep as authorizing plugins as well. On my Mac, sometimes a plugin that was working fine will just randomly be missing from the plugin list and sometimes forcing a rescan will find it again, or sometimes I just have to reinstall it for WL to detect and load it again.
On my little Windows test PC setup, I gave up really trying to use it for anything WaveLab because with most of the FabFilter stuff, only the VST2 versions appear. VST3 appeared for a brief time after initial install but for the life of me I can’t get VST3 to come back. It’s a mess.
It’s frustrating because WaveLab is so great at many functional/workflow things but it is certainly not friendly to most plugins that are 3rd party. It’s not secret and it seems to be a long term issue at this point.
What a smooth experience in contrast is the upgrade to Cubase 9 Pro I just did. From all my many plug ins only a very few were black listed and I have the choice to use them nevertheless. All plug ins I tried (VST 2 and VST3) are running fine, old projects I load work without a hitch so far. Maybe WaveLab got to complex for a small developer team?
Do you get crashes with Steinberg plugins? We never do.
IMO, the problem is that certain plugin manufacturers don’t test enough their plugin with WaveLab.
I don’t say WaveLab has no bug. But very rarely I see a crash dump that shows an error inside WaveLab.
I know this won’t help you. I just want to state my position.
Maybe part of the solution, would be to provide plugin manufacturers, a kind of “WaveLab plugin stress framework”.
Philippe
Maybe, no need to bust a gut - was there ever a policy of SB supplying NFR copies of their product(s), to 3rd parties for testing/compliance purposes…? Perhaps the dongle was a problem…? Couldn’t there be a special Soft eLicenser edition supplied, to make it easier/attractive, in accommodating this situation…? It sounds ideal, if it ever existed…
Or, there’s the ‘VST Scanner’ tool I read about, already available to 3rd parties; is WaveLab not part of (or compliant) with this program…? I believe it accommodates both VST2 and VST3 built plugins/instruments… but, I’m not an expert of course… 
Just throwing out some ideas…
Cheers,
Bob
I never had a Steinberg plug in crashing - which shows that Steinberg plug ins run extremely reliable in Steinberg products here. As a massive Steinberg user I never used e.g. the AU version of Halion. But I don’t know what this could prove? We’re talking here about many plug ins which run fine in other Steinberg products (and even non-Steinberg hosts), except Wavelab 9 Pro. This is the problem, not if Steinberg plug ins run fine in Wavelab.
And if developers don’t test enough their products with Wavelab, what is the problem? Pure lazyness on their side?
In my cases, and I reported this here in the forum, developers do test their plug ins with WL. One answer I got was: “Sadly Wavelab lacks sample-position reporting which is required pretty much in all of our plug-ins”. So, why not just implement “sample-position reporting”? Now, what can I as a user do except informing the host developer, the plug in maker and present the bugs in question? I’m not getting payed to do this, I payed for the software I use for my work. The world is not centered around Wavelab and its problems and who is to be blamed.
FWIW, I rarely ever use the Steinberg plugins so while I’m sure they’re pretty stable, it’s not quite a fair comparison to me. I do try to stick to just a few of the main 3rd party plugin vendors as to avoid further issues, but I still see regular crashes when using a combination of FabFilter, UAD, iZotope, DMG, Sonnox etc. GUI/magnetic mouse issues tend to be with some of the smaller plugin vendors.
I think a serious initiative by Steinberg to get plugin venders to stress test their plugin for WaveLab would be good for the future reputation of WaveLab software. This, combined with a reevaluation of WaveLab and why it sees much more plugin issues than Cubase and other DAWs could really be a big help so we all spend less time dealing with plugin issues, reporting them to developers, and discussing here.
Agree 100%.
Sounds like a great idea.
General note
IMO it might be considered unreasonable to assume that the developer(s) of Wavelab should take responsibility for the testing of all the plug-ins that might possibly be used in the program (there are too many). Logically this has to be down to the developers of each plug-in. If they had an incentive / tool like like the above mentioned ‘plug-in stress framework’ this could make stress testing a whole lot easier.
FWIW almost all the problems I have had on Wavelab (PC version) have been with VST3 versions of the plug-ins. When I rolled back some of these to VST 2.4 the problems disappeared.
[quote=“Thomas W. Bethel”]In a word NO. I have them with Windows 7 Pro as well./quote]
Thank you … the only reason I asked was that it appeared this was starting to look like a “pattern” in signatures.
I am unable to make a constructive contribution because my regular combination of plugs … DMG Equilibrium, Sonnox and Voxengo Elephant never seem to cause any issues. Current version of WL Windoze 7 Pro (32 bit). There was a former issue with DMG Limitless in VST3 version only. But this was traced directly to that version of the plug and not WL.
Steinberg’s plugins rarely have any problems running in WL but one would expect that outcome. It seems to me that there is a basic problem to be solved. Why 3rd party plugins run OK in other Steinberg products but not in WL. It amazes me that the WL team and the CUBASE team don’t sit down and figure out where the problem is and fix it. This has been going on for YEARS not just with WL 9. I think the world of PG and what he has given us as a mastering DAW. I use it every day and it makes me money. I think it is time for someone to look at the problem with a different perspective and find a solution. Maybe thinking outside the box is the way to solve this problem once and for all. This has been going on for way too long.
MTCW
IMHO part of this is already known, and just down to the basic fact that the plug-in developers test in Cubase and Nuendo but not in Wavelab. Agree, a better solution is long overdue and it is strange that Steinberg developers do not streamline the code so that if a plug-in works OK in Cubase it will also work OK in Wavelab. There are probably technical reasons why this is not possible… but perhaps there’s a way of making WL conform a bit more with the way things are handled in Cubase. IMO in the long term the new and more strict plug-in sentinel introduced in Cubase 9 (https://helpcenter.steinberg.de/hc/en-us/articles/207348390-Plug-in-Sentinel-for-Cubase-9) may help reliability of plug-ins in Wavelab, since suspect plug-ins are rejected by the program and put on a blacklist, so any developers testing in Cubase will have to make sure their plug-ins pass sentinel. I’d even hazard a guess that right now, the majority of plug-ins which pass sentinel will also work without crash issues in Wavelab.
The above mentioned ‘plug-in stress framework’ may help… or how about a plug-in sentinel for Wavelab? Or perhaps a specific step-by-step stress test in Wavelab which tests the plug-in in the Master Section and in the clip, track and master montage sections, and in all of them at once, both for playback and rendering.
Almost more viscious than plug-ins causing crashes is when a plug-in does not render correctly, as this can easily go unnoticed and cause chaos (for example, you may happily believe that your EQ has rendered correctly over the whole length of the audio file but, in reality, it has not been included in the first couple of seconds).
Fabfilter EQ has always crashed Wavelab in OSX, on my system…
Maybe this isn’t your issue, but the Fabfilter EQ (and Multiband Compressor) VST2 have a known crash problem in Wavelab on Windows and Mac when used on montage clip, track, or montage master. But the VST3 versions of the plugins should be ok in the montage.
The VST2 versions will be ok in the Master Section, but will crash in the montage. The VST3 versions should be ok anywhere.