The problems you’ve described are (mostly, if not entirely) not WaveLab’s fault. We’d love to hear other additional reasons WaveLab is problematic for you, as it could help get the issues resolved quicker.
Many of the issues described across these forums are similar to the ones you’ve reported, and are easily resolved by users themselves. The remainder are usually fixed by PG fairly quickly. I’ve not seen a true bug reported left unresolved by PG, unless he decides to leave it as a documented “known issue.” If you can list additional bugs you’re seeing, let’s tackle 'em one by one in a reasonable way.
Sweeping, generalizing statements about software aren’t helpful. “Apple iTunes is problematic and needs to be fixed. It has many issues,” for example, wouldn’t help Apple improve its product. You need to be specific about the actual problems affecting your work.
For example, your approach to helping report the Acustica bug is entirely reasonable and correct. Either Acustica or Steinberg needs to resolve the issue. That’s productive.
But most of the issues reported in this thread aren’t real issues.
I agree that Steinberg could do a better job with training and staffing for support. That’s certainly an area where Steinberg could improve.
If Steinberg has an answer or solution… we should know about it!! All of us. For example, the solution you claim, should/could have been emailed to me (by now) many days ago when I contacted Steinberg. I should not have to ‘trust’ YOU (at this point), to get a real (verified) answer to this issue.
If there is a solution it would be posted in the many places I’ve looked. And the program should address these things in ways that users do not have to dig into files and ‘fix’. That’s not right.
I am also a WaveLab user who experienced similar issues (plugins not showing up as expected) over the years. I finally took the time to figure out what the problems were, and 100% of them were due to my own plugin configuration practices. Once I cleaned up my plugin folders and ensured that plugins were where they needed to be, I haven’t had a single “missing plugin” issue in the years since, except when security software caused problems.
There are two basic issues you’re reporting:
You expect all plugins to be used by WaveLab and none to be ignored.
Some plugins are causing WaveLab to crash and/or exhibit other problems.
For #1 above: This is unreasonable. WaveLab should ignore some plugins due to being non-64-bit and/or not being up to specification. (Or, in the case of components like Waves’ WaveShell or iZotope’s iZ .dlls, they’re not meant to be used as plugins.) So it’s a non-issue.
For #2 above: Yes, these reports are valid and need to be investigated. Over the years, when WaveLab fixes are needed, PG has reliably provided fixes quickly. The issues need to be clearly documented so he can fix them.
Most of the people over the years reporting the “issue” as described in #1 above are also describing situations where they’ve contributed to the “issue” themselves by not configuring plugins correctly. This includes me - I also encountered these issues until I sat down one day and fixed my plugin folders.
And for the people reporting issues related to #2 above, the fixes are usually provided quickly. You just have to be specific.
So, you did all that, and Steinberg hasn’t verified and put it into the user knowledge base?! Come on.
Heck… if that were the case, I would have welcomed being pointed to the same, and been provided a procedure to resolve this. If that exists, I’d be satisfied (and very much so).
cefshah, please know that I’m genuinely trying to help here and not just antagonize you.
There isn’t a solution because there’s nothing (or little) to fix. It’s how WaveLab is designed. I didn’t find a notable “solution” as much as I simply cleaned up my plugin folders and ensured I didn’t have multiple (or out-of-date) versions causing issues. It’s a basic thing that many audio professionals do as a part of their system maintenance.
Let me give another example. Let’s say that you bought a blender that requires 8" tall pitchers as accessories. You put a 7" pitcher into the blender mechanism and it doesn’t work. Would you demand that the blender company provide a “solution” for this problem? Would you say, “It’s not fair that I have to dig into my pitcher collection and fix it!” ? No, you would realize that you need to use the correct pitchers with the blender.
You need to use 64-bit, up-to-specification plugins with WaveLab. For any that fit that description and are still not working (like the Acustica plugin you mention), simply report it and if it’s WaveLab’s fault, PG will usually fix it quickly. It’s that simple.
Overall, there’s nothing to put into the user knowledge base. It’s common sense.
On the specific issue of 32-bit plugins, see this article here for a general idea of possible solutions. (Note that current versions of Cubase no longer have an internal 32-bit bridge and therefore cannot support 32-bit plugins natively):
This article describes the Cubase version 9 Plug-in Sentinel and how 32-bit plugins are automatically blacklisted.
For outdated plugins in general, it makes sense that technology and specifications move on. If you try to use plugins that no longer adhere to modern specifications, they won’t work well (or at all) in modern DAWs.
Why hasn’t tech support fired out this “common sense” to myself, and posted it elsewhere in this forum and the internet?
That would be proper guidance, and it seems to have been missing, until I just happened to encounter you here.
And NO, I do not expect WaveLab nor Cubase to utilize 32bit plugins. But I DO expect WaveLab and Cubase to scan and make available the bulk of 64bit plugins I install. Again… Cubase 9.5 is virtually a ‘librarian’ in that sense; WaveLab is an absent-minded professor (in comparison).
I will not deny that ultradust is patient and persistent and helpful.
I’m generally expressing some anger at Steinberg here, and it may seem that I’m directing it at this/that individual participating in the forum. I apologize for that ‘effect’.
IF Steinberg does not come up with ‘something’ official… then I’ll surely give the suggestions here a try.
Arjan P, thanks for clearing that up. Even so, you did help me shift my perspective as to how I’m communicating overall.
Yamaha/Steinberg are massive companies. Sometimes, I expect the same level of focus/attention I get from all the other software companies I deal with. And it is difficult to say ‘nicely’, that there are no 2-year-old anomalies with other pieces of software or gear I own. (Sigh.)
On the positive side of things… I have a request for Steinberg:
One feature I would like to see incorporated into WaveLab(and some other programs), is a way to manually select which plugins become active upon initializing the program for a session. That is, a way set up a custom-loading of plugins (per activation). More specifically, the ‘user’ (customer) decides exactly which plugins are scanned and made available. Personally, I wouldn’t care if that slows (somewhat) the startup of WaveLab… but would welcome such control immensely.
I’m pretty certain that I should run WaveLab on a PC separate from anything else. The “WaveLab Computer”. LOL!!
My layman’s wish (not being a software expert), is that WaveLab would do whatever Cubase is doing, to scan and implement plugins. Cubase sees and handles well virtually all of the ones I’ve installed on my workstation.
Thank you (and PG) for the patience and kindness that you showed a few weeks ago, as I was (anxiously) searching for answers to my plugin issues.
I know I was more ‘irate’ than I should have been; I let my frustrations skew my logic some during that time. So, I apologize for not being as diplomatic as I know I should have been.
The detailed procedure you provided is something I’ve decided to give a try, now that I have time. (I was/am impressed that you have nearly 1100 plugins working with WaveLab 9.5x!!)
And WaveLab is just too good/fast of a program to just give up on.
Anything else you might suggest to make this go more smoothly is absolutely welcome.
Other than that, I will tell you that about 4 weeks ago, I shared what you suggested with Steinberg Technical Support… and they said your procedure would likely help me to resolve my issues.
So, thanks again for the post… I have opportunity to search and organize things in my PC this weekend. I’m optimistic that your solution will take care of a lot of my problems with VST’s.
Thanks for your candor here and for taking a second look. I think all of us have experienced less-than-fun times dealing with issues like this. The key is digging in and taking the steps needed. Not the most exciting experience, but necessary.
Basically, if you go back and look at the folder locations I listed in a previous post, just ensure that you don’t have multiple versions of plugins hiding in those various locations. You want one and only one instance of any given plugin and type (for example, Klanghelm SDRR 64-bit VST2) on your system, and you want it in the correct location (on my machine, in a dedicated 64-bit VST2 folder). Then, you ensure that the plugin folder settings for your various DAWs point to the correct plugin folders for use in those DAWs.
For a quick example of how things can go wrong: Many newer 64-bit DAWs no longer support bridging (hosting using special translator technologies) of 32-bit plugins. So let’s say you’ve got a 64-bit version of a plugin, and you’ve also got the 32-bit version installed, and they’re both inside folders that a 64-bit DAW is scanning for plugins. If the DAW scans the 32-bit version first, it may blacklist that plugin; and then, when it scans the 64-bit version later, it might ignore that version. Thus overall, the DAW would be ignoring the plugin, even though you’ve got a 64-bit version installed - which could be confusing at first. Each DAW handles situations like this differently, and there are many different possible configurations and combinations of factors that could elicit unexpected results (such as “missing plugins”). So best thing to do is to carefully go through all the relevant folders and ensure that one (and only one) copy and bitness of a plugin exists in any given DAW’s plugin paths. This cleans things up so that each DAW doesn’t encounter possible confusion while scanning plugins. Make sense?
Here’s a quick distinction to help: Typically, you want only one bitness of a plugin in the DAW’s plugin paths. (For example, you only want a 64-bit Klanghelm SDRR plugin in a 64-bit DAW’s plugin path.) But most modern DAWs readily accept multiple types/formats of the same plugin (for example, having VST2, VST3 and AAX versions of a plugin in the DAW’s plugin paths). (You can even try to have these various plugin types installed side-by-side in the same folder. Personally, I don’t like taking that approach because it’s harder to maintain, and it also doesn’t follow recommended VST (and other) specifications - and some DAWs will ignore plugins placed in the wrong locations.) But it’s fine and industry-standard for a single DAW to scan both a VST2 and VST3 version of the same plugin. Just keep in mind that the developers themselves might code their plugins such that only one or the other type (VST2 or VST3) will actually appear as available in the DAW. This is up to the developer.
So preferably you want one and only one bitness of plugins scanned by each DAW, but you can use multiple types/formats with each DAW (as long as the DAW supports those types/formats).
My personal approach is to simplify things by:
having only one folder “32” for all 32-bit VST2 plugins (effects and instruments together);
having only one folder “64” for all 64-bit VST2 plugins (effects and instruments together);
putting all 32-bit VST3 plugins (effects and instruments) into the standard location C:\Program Files (x86)\Common Files\VST3 ;
putting all 64-bit VST3 plugins (effects and instruments) into the standard location C:\Program Files\Common Files\VST3 ;
putting all 32-bit only (no 64-bit versions available) plugins into a special folder “32-bridge” for bridging ;
putting all the resultant 32-bit-bridged-to-64-bit plugins into a special folder “64-bridge”.
Then:
I point any 32-bit DAW at “32”; “C:\Program Files (x86)\Common Files\VST3”; and “32-bridge” to use those plugins; and
I point any 64-bit DAW at “64”; “C:\Program Files\Common Files\VST3”; and “64-bridge” to use those plugins.
At first, this may seem a bit tedious, and you may ask yourself, “Why don’t they just make this easier?” That’s definitely a valid question, but - once you get used to this setup, you’ll like it because it keeps everything clean and most (if not all) of your missing-plugin issues will resolve.
No, I generally did not have issues with re-authorization. Typically (and speaking very generally here, since licensing methods and installation processes vary widely), once a plugin is installed and authorized, the core plugin installation is instantiated with a license. This is typically decoupled from the actual plugin VST .dll or VST3 files themselves. You can usually move those files around where you need without breaking a license.
In the event a particular plugin uses a more brittle licensing/authorization method, it’s usually not too much trouble to get it reactivated/re-licensed assuming that you’ve got a valid customer account and, in the event you need help from the publisher, the company/developer is still in business and supporting products.
And yes, getting the latest updates for all your plugins is highly recommended. This may help resolve most of the remaining legitimate issues you reported.
We’ll be interested to hear how things go. Keep us posted if, after a thorough cleaning, you still run into any issues. We’ll try to help!
I have read the discussion about missing plugins in Wavelab but without problems showing and functioning in Cubase. The version wich is spoken of is Wavelab 9.5. I just want to state that I have Wavelab 12 Pro and Cubase 13 Pro and experiencing the same issues. I have from Samplicity audio recently purchased the Berlin Studio and Gemini BM7 plugins. Working perfectly in Cubase but in Wavelab the already discussed problems. I have made a technical support request today hoping they will be able to help. I wrote this message to inform you that obviously the problem is still not adressed or solved!
