With ML8000 in the master chain, everything it’s running fine until I try to render.
Click on render → popup (see pic attached). To get rid of it, you have to click on "OK - - and the rendering process does not start.
Even after restarting WL, and restarting the systrem, → it’s not possible to render the file!!
The VST3 version of McDSP ML8000 crashes WL 9.5.30 on my Mac too. WL just disappears, crash report is showing up. The VST2 version seems to work fine.
McDSP Filterbank was the first 3rd party plugin I ever bought, it came in a DVD style case. It was better than the stock Pro Tools EQ for sure.
Sadly, McDSP probably falls in the category of smaller plugin developers that do not test their plugins in WaveLab and are subject to common issues that other 3rd party plugins seem to have when they work OK in Cubase but fail in WaveLab.
It’s unfortunately, but usually the fix needs to happen on the plugin side rather than WaveLab and the plugin developer will probably point the finger at WaveLab or VST3 in general.
WaveLab Elements 9.5.25 here failed to start the rendering process if any Acustica Audio plugins were loaded, does anyone know if this is still the case?
You always jump in to defend the Wavelab side, no matter what. I smell some trolling here. McDSP plug ins are of very high quality, working fine in Nuendo/Cubase and other applications. As if WL is the holy grail of VST3 functionality and “smaller plugin developers” are idiots or sloppy. I bet there are much more McDSP users than Wavelab users. WL Pro 9.x is prone to plug in problems since the beginning.
I made McDSP aware of this thread and asked them to jump in here.
I didn’t say that Colin from McDSP is an idiot. It would be interesting to know if he’s thoroughly tested his plugins in WaveLab, or if he only tests Cubase and assumes that is good enough which is clearly not the case.
I know absolutely nothing about plugin coding so I’m in no position to call a plugin developer an idiot.
I’ve had plugin issues fixed by the developer, and I’ve had some fixed by PG/Steinberg. I don’t take sides, I just want things to work.
In a majority of cases, the fix needs to happen by the plugin developer.
The saga continues … other McDSP VST3 plug ins crash WL Pro 9.5.30 in the same way, like AE600 or 4040 Retro Limiter …
I have analysed the problem, which happens to be internal to the McDSP VST3 version.
This company will be contacted.
Before some people say it works in other DAWs: unlike other DAWs, WaveLab renders in a different instance, to achieve a better workflow (continue editing while rendering), or multi batch processing. The problem happens during that stage.
This is a setting problem, and the VST-2 setting system is different. The problem only happens on the VST-3 version.
This is what I could analysed.
This is a key piece of info that more plugin developers need to know. I can think of quite a few plugins that had this issue when I first started using them in WaveLab but the issues was eventually resolved with a plugin update.
This is a key piece of info that more plugin developers need to know.
FYI:
- This is something perfectly legal
- WaveLab is doing so since version 1.6
This is indeed a workflow plugin designers need to test.
Philippe
Yes, I didn’t mean to say it wasn’t a valid workflow (I know nothing), but it seems to be a piece of info that many developers don’t take too seriously as it’s one of the main issues I see with 3rd party plugins when they are first released. So many some more clear documentation can be made about it.
Here’s a summary of what I normally see:
- Plugin works on playback but doesn’t process audio on rendering
- the first 50 to 100ms of audio is faded in when files are rendered (DMG and Softube had this but fixed it)
- Blank, black, or weird GUI though this seems to have gone away recently
- A hard crash when trying to render audio (Kazrog KClip 3 for example and apparently Acustica too)
- High CPU/latency plugin chains have glitchy dropouts at the start and/or end of the rendered audio, and sometimes on playback too. (Leapwing DynOne had this but I think they just fixed it in version 2).
Other recent issues are mono audio files and certain (if not all) non-Steinberg VST2 plugins have really jittery and unusable audio playback.
The sticky mouse/controls issue seems to have gone away.
Here’s a summary of what I normally see:
At this time, I recognize a WaveLab problem with the VST-2 plugin processing of mono files, for plugins that can’t handle 64 bit samples. This was fixed today and I hope a WaveLab 9.5.35 can be provided soon.
I have yet to try to the Acustica Ruby plugin, but I did not see any demo on their site. Steinberg will have to get in touch with them asap. Then the problem can be analysed to know the origin of the problem.
I am not aware of any other problem on the WaveLab side.
This is kind of what I was eluding to in that the entire Acustica experience IMO was not very user friendly. When I tried it, the demo versions were separate from the real versions and if you wanted to buy a plugin, you couldn’t just authorize your version and keep working, you had to install a new full version and start over, and the download process for Ivory 3 and all it’s models was not ideal.
After all that, the plugins had such poor performance in both REAPER and WaveLab on a 10-core iMac Pro with 64GB of RAM, it was the one time I can remember asking for a refund for a plugin. Because of their silly demo policy I gave Acustica the benefit of the doubt and bough Ivory 3 without demoing so that’s why I had to ask.
Maybe if you contact Acustica they can get you good working versions more easily.
I could have been such a “someone”. If this is so crucial Steinberg should have added this as a strict necessity to fulfill in VST3 specs, no matter which app is considered. You could have communicated that also much earlier.
No, not fully - I experienced it yesterday with VST2 versions of McDSP plug ins and some other I cannot remember now. Have to do more observations.
But the test chain I made the video from with all the sticky mouse ‘traps’ and delayed EQ band changes behaved nearly normal now. There is some progress with the same plug ins - despite all the rejecting of problems at first and pointing solely to the plug in developers.
NUGEN is another plugin developer that last I tried to use wasn’t very friendly with WaveLab. Lots of crashing from doing basic things. Mostly unusable. I was actively in touch with their support and getting some beta versions but ultimately they didn’t seem too interested in supporting WaveLab officially and I slowly stopped using their stuff in WaveLab.
I would think that with NUGEN plugins being so mastering/broadcast focused and WaveLab being one of the more popular cross-platform DAWs for broadcast/mastering that there would be a desire to have a better relationship from both parties but it’s been a solid year before I have tried NUGEN in WaveLab so maybe somehow the issues were cleared up.
I have been telling that information for many years, nothing new 
And the VST-3 specs allows this (VST-2 also). And I would say that 95% of the plugins are ok.
Not nitpicking, but I can only remember you were stating that WL uses something from the VST3 specs, but not specific what. I have over 1000 plug ins now (legal licenses of course - not that somebody gets the wrong impression) and a few hundred may be used in WL - a few dozens often and around 20 are maybe my go to plug ins. I cannot confirm the 95% being ok. There were many problems and the sticky mouse cursor still shows up here and there. I would estimate around 50% without any problems or side effects.