I’m not going to say that Steinberg is doing something wrong, but it seems like there is an opportunity to somehow disseminate and reinforce whatever extra information is necessary for developers to avoid the increasingly “common” issue of their plugins applying a 30ms fade-in on rendered files.
I can recall about 8 developers over the years that have had this problem with their releases. Yes, I get that they probably didn’t test it in Wavelab (so shame on them), but in the end, it harms the end-users trying to do work. I can recall in the last 3 months, 3 developers who have this issue including Softube (which isn’t some small boutique developer), Leapwing and now Mathieu Demange’s RX950.
I would like to encourage whoever at Steinberg is creating the SDK to PLEASE emphasize that Wavelab requires different coding for VST plugins to be compatible.
I do not agree that “devs” are having trouble with plugins in WL - I see it the other way around.
Wavelab has always been some sort of oddball host - always doing it’s own thing and causing issues - when the same plugins within other hosts (Like Studio One over here) exhibit no issues whatsoever.
This has been discussed at nauseum in here but PG will ultimately defend WL (and usually blame the third party developer) when another report of a shaky plugin appears.
I also find it massively ironic that the Steinberg VST plugin engine/framework used within Cubase and Nuendo - which are certifiable as being rock solid (I never had a single issue with any plug - EVER when I used Nueudo) is inexplicably not used within WL. Or maybe be it is - and it has been crippled by some development requirement.
Whatever the case - I am certain that PG can ring someone up in the Cubase/Nuendo dev crew and ask them how to stabilize this thing - or simply use their engine and end this nonsense. I mean they are all under the same company banner and surely some discussions could happen?
While I love WL - I do not understand how this keeps going on and on, version after version, year after year.
You seriously think PG wouldn’t have done so if it was that easy? I don’t know the inner workings of WL, but apparently it is more demanding of the plugins, whether it’s due to stricter adherence to the standard (and other DAWs being more lenient) or some other reason.
I think that it is definitely the plugin developers. Waves and iZotope are large companies and they work fine in WL.
Here’s a better question? Is there a fee that a developer has to pay to incorporate the VST3 algo or is it just software writing technology that they lack?
Currently, I am aware of only one plugin manufacturer with problems (Acustica), and apparently they don’t want to take the time to even try to test if the problem could be on their side.
I do understand your point of view. It seems logical.
However, not all plugins work in Cubendo either. Take Izotope RX for example. There have been and still are issues. And I’ve seen issues with a number of other plugins in the new DOP window. In my opinion, the outcome looks different because developers are likely to jump quicker if they think their plugins have an issue in Cubase or Nuendo because they see these DAWs as major players. Wavelab’s requirements are somewhat different but some developers may not even think these worth considering. I think the general idea is of course that developers should adhere to the VST specification and probably other programming constraints.
I am merely thinking out loud here. Maybe PG and Steinberg never talk. Maybe the Cubase/Nuendo guys don’t share code. Maybe WL’s implementation of the VST plugin pipeline is drastically different.
And I am not implying that every plugin ever made will work in Nuendo/Cubase. I do know that of all the plugins I own and use - none had ever given me problems in Nuendo (and this was back in v5) while some continued to give me gears in WL (v6/v7 era).
Here in 2018/2019 - I use a standard stable of bigger name plugs (UAD, iZotope, Nugen, Waves etc) and I can say that not a single one has given me any grief in Studio One.
And it’s not hard to poll the forum here on a regular basis and see that plugin handling (historically) in WL remains an issue - despite PG’ comment that Acustica is the only outlier as of today. While - at the top of this thread - the OP is naming at least 3 other developers by name - indicating they may have a problem.
My take - for the price of WL, the market it serves and the maturity level of both the product (and the Steinberg VST spec) - having continued reports of plugin problems within WL seems to be a bit odd to me.
One would think after 15 or 20 years of hard development - WL would be the standard when it comes to multiple ways to handle even the most poorly coded plugins gracefully.
I do not know why - or whether it’s easy, hard or otherwise.
At the end of the day - this is about gracefully handling. If a plugin has a problem - WL would be much better off stating in a clear message - exactly what the problem is (in VERY clear text) and then carry on.
But the useless messages like “Wavelab has encountered a problem” or the program crashes or locks up or any number of other ugly end points - should be avoided at all costs.
I know I would be very very annoyed to be in the middle of important work only to have WL shut down midstream due to non-graceful error handling.
I know absolutely nothing about coding software but it would be great if Steinberg could make a tool for plugin developers to test their plugins in order to make sure that every deep and dark crevasse of the VST coding format spec is adhered to so we don’t end up with so many 3rd party plugin issues.
I make the observation that the world of mastering is small … when measured against production and mixing for example. In that larger world PT is ubiquitous.
Plugin developers have limited resources and it makes sense for those developers to allocate those limited resources to where the ‘big’ market is (and that’s not the esoteric world of mastering).
When the smart plugin developers code something specifically aimed at the small world of mastering, they typically ‘work’ with WL. And if they don’t, it usually means they also aren’t working in other mastering specific apps and the developer tends to get on to things pretty quick. At least that’s been my experience.
Where we have plugins that are really aimed at the general production and mixing market … but might just happen to be also useful for mastering … well it’s not unexpected that they allocate most of the resources to PT compatibility … with mastering DAWs a distant second. This is neither good nor bad … it’s just the market realities.
Definitely. I think this is clear. There is only so much time in a day and only so many resources so I get the feeling that most plugin developers simply test Pro Tools, Logic Pro, Cubase, and call it good. They assume if the plugin works in Cubase it should work in WaveLab. Relatively speaking, the WaveLab user base is relatively small so they don’t have much to work off of. I hear that Soundblade is really buggy with 3rd party plugins and that Sequoia can be too.
Aside from that, I’ve had a few plugin developers tell me that they really struggle with the VST3 format in particular.
I believe it because some good plugin companies like UAD and Tokyo Dawn Labs are still VST2 only. They don’t have a VST3 version yet. There are a few others too and Sonnox has only been VST3 for a relatively short amount of time.
Anyway I think this is true because in my 10 years of heavy Pro Tools use from 2001 to 2011, it never once crossed my mind to be a beta tester for any plugins or DAW. It all just worked day in and out.
After starting to use WaveLab ~2011 or 2012 when it came to Mac, I am now on the beta team for MANY plugin companies because I was one of the few taking the time to report WaveLab issues in detail so they could try to solve the issue(s).
The plugins I like to use in WaveLab are pretty rock solid but when a new plugin is released, I’m more surprised when it works right away and I’m not very surprised at all if it has a bug in WaveLab…be it GUI, fade in on rending, render crashing etc.
Stillwell, Sonimus, Kazrog, Softube, Leapwing and Mathieu Demange have all fallen victim to the “30ms fade-in when rendering” issue. Softube had to be shamed on Facebook for them to address the problem on their $500 offending Weiss plugin. But maybe there is some kind of FAQ for the SDK that addresses this specific issue since it’s affecting more than just one or two developers. It doesn’t seem to take long for developers to fix it once they know but how amazing it would be if it could be avoided in the first place. It’s not a compatibility issue - just a bug that requires them to tweak their code.
Stuff like Acustica is another subject altogether - I’ve given up on them (but how nice it is for them to send me 35% off coupons every couple of weeks for plugins that if they actually worked, I would have spent the money on).