Stillwell Audio Plugins are NOT compatible with Wavelab!

So some of the Stillwell plugins cut off the first 50ms of audio in real-time and rendered audio. When I contacted their tech support, they said that they’ve tried to contact Steinberg/Yamaha over the years for assistance and requested NFR copies of the application so that they could test with it. Steinberg/Yamaha apparently has just ignored these requests which is a real bummer because the Stillwell stuff kicks major ass… just not in Wavelab, which has me scratching my head in frustration and wondering if I need to find an alternative to Wavelab?

Maybe we could start some kind of GoFundMe account so that Steinberg/Yamaha can afford to throw a couple NFR licenses to them and help their developers make their plugins compatible. I mean, if I can get developers to GIVE little ol’ me free NFR licenses (and I’m just a measly engineer), maybe Steinberg could do a solid and help out the small developers who just want to test their products. Just a thought…

From Stillwell:
"I can’t tell you why other plugins work the way they do - I don’t have their source code. I also don’t have Wavalab because Steinberg / Yamaha has NEVER responded to our requests for NFRs over the years - never said “NO”, they just don’t respond at all. Without a copy of the software, it’s EXCEEDINGLY difficult to troubleshoot an issue.

The number of people that have had issues with Wavalab over the past seven years is pretty minimal - I understand that’s a problem for you, but from our standpoint it doesn’t make a whole lot of economic sense to buy several copies of something (one for every developer and tester) to support a relatively small number of users. Most DAW vendors are happy to trade NFRs (Not For Resale copies)…lets us test against their software, and lets them test against ours."

Orangeoctane, can you say which plugins are doing this, and have you tried doing the same in other programs? I agree Steinberg should respond and give them copies of Wavelab, but I know of only two cases (TC and DMG) in the past where a small amount of audio was cut off the start of renders, and in both cases it happened in other programs too and nobody noticed, and was then fixed by TC and DMG without having anything to do with Wavelab. You or Stillwell might want to try it in another program with the VST plugins first.

Event Horizon is the one in question.

I’ve also experienced an issue with Sonimus Satson Channel where it applies a 50ms fade in at the beginning of the file when it gets rendered.

It’s completely noticeable to the point where I can’t use those plugins.

Your problem, like other problems, may be caused by something a plug in company wrote me as an explanation about functions of their plug ins not working in WL9Pro:
"Wavelab: Sadly Wavelab lacks sample-position reporting which is required pretty much in all of our plug-ins."
Personally I have now several plug ins I use for mastering or sound design I cannot use or not use reliable in WL9. This all starts to make me more and more angry. I’m also fed up in reporting and describing problems - I paid for the software and don’t want to be a tester. It looks like there is a lack of full and/or correct VST and VST3 implementation in WL9.

Is that true? And uncommon? Something to be changed?

True / Untrue?

sample position? What for? The plugin simply has to count the number of samples it gets.

Do you have an official forum for plugin developers trying to make their plugins work in Wavelab?

I informed the particular plug in maker about your answer. Hopefully they chime in here.

I know I say this all the time, but I think that most developers (especially the small ones) only test their VST builds in Cubase and don’t have the resources to test and support WaveLab very well. They assume WaveLab is the same because Steinberg has their name on Cubase and WaveLab.

This combined with the fact that WaveLab seems to adhere to some strict VST guidelines or specs that may give developers some troubles seems to have resulted in what appears to be more 3rd party plugin issues that you would normally expect from a DAW.

Some additional tools, testing, or VST forum for plugin developers to help “get it right” would be excellent.

Well, for VST3 devs, there’s already this:-
https://sdk.steinberg.net/viewforum.php?f=4&sid=ee284df17659316a048434555fd45b03

Plugin devs should grab a copy of the new ‘VST Scanner’ tool (see top post in above forum), to check their builds - it will scan/analyse both VST2 and VST3 editions for errors/compatibility. If they are not aware of the new tool, for whatever reason, we (users) could do our bit to help alert them… (perhaps this is something coming to all of us anyway, built in to new updates to Cubendo and Wavelab later this year…?)

I can imagine the complication of sending out an NFR copy of WL to every single plugin developer out there - so Steinberg has to be selective to a degree. The new VST Scanner tool seems a good solution to this need.

Bob.

Scanner tool would be an easy fix for developpers, pass the tool first, if there are then still issues then engage with steinberg.
Also, IMHO, if you sell €35,00 plugins, you should invest in the daws you communicate to support.
An NFR is for promotional purposes, if you make money with WL, you just need to buy it.

Ok; but my view is NFR’s are also sent out to 3rd party devs, for testing/compatibility of their utility/plugin/instrument with the Steinberg product - hence Stillwell’s request(s.!) to Steinberg mentioned in the OP.

(BTW - I should have also noted, the scanner tool mentioned in the forum above lists Cubase and Nuendo; not WL)

In the description, is it saying it only catches plugins that crash? Or would it do more, like detect whether the 50ms problem in this thread is the fault of the plugin?

Good point - I don’t know; maybe not.

Now I’m thinking, would the forum even be a good place for the developer to post the question…? Since the plugin appears ok with other hosts, is it simply a need to check/debug/experiment with builds, against WL - and so, we’re back to square one… :wink:

I have tried the Stillwell products. At one time I thought they might be a good way to save some money on plugins. I also like the idea of supporting a plugin developer that is competing against the bigger companies, sure. But then I thought about this and came to a realization: A bigger company has more R&D ppl, and more ppl committed to making their plugins work on every available host. I’ve tried at least four small company’s plugins, spent my $$ - and watched them fail in one way or another to live up to their promise. Typically they have a nice GUI, yes, but honestly they do not have the internals worked out, no, not like a bigger company like Waves does. So Waves is a big one for me, as is iZotope. I am not alone in my thinking either…

To puma and anybody else listening, you have the 1T HDs which are large, yes, but you will find that having your OS and DAW software (and all other programs) on an SSD HD will improve things incredibly. Even with my dated PC, while running an SSD for Drive C I can fly through a recording project mix down with many many plugins running. When using a typical HD this was not the case.

orangeoctane, I don’t know why we’re getting different results, but I don’t get any cut-off audio in renders with Event Horizon. My renders have correct audio right from the very front edge of the file.

But I do find a problem with the VST3 version of the plugin in any version of Wavelab.

This is what I get, with Event Horizon 3.0.3:

Wavelab Event Horizon VST2: ok
Wavelab Event Horizon VST3: audition is ok, but the effect is not included in the render.

Reaper Event Horizon VST2: ok
Reaper Event Horizon VST3: ok

Maybe they could demo a version of Wavelab or Elements to try to find out why it’s different in Wavelab and Reaper, and to try to reproduce your cut-off audio.

If this is an defined API request in the VST interface, why not simply implement it? Presumably it is as easy within WaveLab as you suggest it is within a plugin.

Paul