So, since we’ve passed the storm, Waves on Linux status update from anyone?
Waves plugins work with Ardour on OSX and Windows. Waves does not provide Linux versions.
As for Waves VST on Windows. The waves-shell (which includes all plugins) can take a long time to scan and on some system times out. Press the “Stop Timeout” button in Ardour’s scan dialog or increase the default timeout in Preferences >Plugins > VST. (clear the blacklist and re-scan in Preferences >Plugins)
Back after some time with an update for the original question of this post:
Using the latest version of wine staging and linVST, the entire waves bundle is fully functional. You will want to ensure that all of the applicable redist packages and libraries are installed in your wine prefix, like msvcredXX.dll vcrunXX.dll etc. In order to run the legitimate licensing programs to properly license your software, you will almost certainly need wininet and webio installed in your prefix. Unlike previous times, the licensing software should work ok now. (that ones for all those in the previous debate, lol.) You will also still need to unpack the waveshells using shell2vst etc. I have managed to get every one of them working, though some seem to spike the CPU usage more than what I would think is normal. That said, Steinberg just released the VST3 SDK for linux, so strap in folks, we are gonna have a lot of plugin support soon!
Cheers!
recommended dll overrides: d2d1.dll wininet.dll, nsi.dll, iertutil.dll : native only
recommended installed libraries:
vcrun 2005 through 2015 should all be installed.
registered fonts
gdiplus
dx3d11
for 32bit versions: sudo apt-get install gcc-multilib g+±multilib
for plugins that require internet access for registration etc, its a good idea to install these libraries in linux:
sudo apt-get install winbind sudo apt-get install gnutls-bin sudo apt-get install libntlm0
Be careful about overcomplicating the registry in your prefix. thorough practice is to keep a separate prefix for different versions of plugins. For updates, best practice is to clean install in a fresh prefix.
For ease of maintaining prefixes, make a prefix with all of the most commonly needed libraries and components installed and keep a backup copy of it. Instead of creating prefixes from scratch each time, copy the backup to your wineprefix directory under the desired name and tweak it accordingly.
I do hope this helps save someone the headache I went through to figure out this info.
If VST3 support also finds its way into ardour - though other linux host applications do support it.
I do hope this helps save someone the headache I went through to figure out this info.
Why not just keep the Windows install that most likely came with the PC and run your Windows plug-ins on Windows rather than creating an add-hoc - and likely fragile - Windows emulation (in all but name) to run on top of Linux? Having already had to purchase commercial Windows plug-ins, it seems like the worst of all worlds.
the VST3 SDK has more lines of code in it than Ardour! It barely fixes the worst parts of VST. In the last month, despite Steinberg’s efforts to stop this, I’ve noticed at least 3 new plugins released in VST2 format, and I don’t even follow plugin announcements.
I wouldn’t rule out future VST3 support, but we’re not falling over ourselves to implement it.
Developers can still release VST2 as long as they have the SDK and a license agreement with Steinberg (I believe there was a cut-off for approving new agreements after October (2018) ) and I guess will continue to do so as long as hosts support it. The ‘problem’ with VST2 is that it’s actually quite good (considering its age) - its relatively easy for (new) developers to understand, its flexible enough that you can do just about all you would need for most plug-ins (as proved by the sheer number of them) and - it is extensible. You can add custom extensions if required (though not many do). VST3 adds some complexity - and improvements - its relatively easy to compile for Linux (I’ve ported a few plug-ins to VST3 on Linux, but there is little point in releasing them yet - as not all hosts support VST3 reliably and those that do also support VST2… which I guess proves my previous point)*
the VST3 SDK has more lines of code in it than Ardour
Some of my plug-ins (including the graphics toolkit / framework etc) have more lines of code in than Ardour… 
*Developers - especially commercial - generally hate new plug-in formats - it means no-one will buy your existing range because - futureproofing, unless you support the new format (which you will be expected to provide for free). Often this means significant work to port to a format which by definition there will be no immediate support / market for. All of which time could have been spent developing new products.
I don’t have an issue with a plugin that has a lot of code. I am sure that in particular things like Kontakt are enormous. But a plugin SDK? That doesn’t actually do much of anything? Oh, except for a GUI library that uses a very poor choice of underlying technology on Linux. No thanks.
I’m not even sure that VST3 fixes the single biggest problem in the VST API, which is the use of pointers in the API, making the 32/64 bit distinction problematic. I know this is fixed for VST4, at least.
I don’t have an issue with a plugin that has a lot of code…
I guess what I was saying - light-heartedly - about the amount of code, was that perhaps to a lot of people a plug-in appears as if its just some little ‘add in’ to a much larger application… whereas in many cases it has as much support infrastructure contained in it as a standalone application - it just happens to get hosted in / by another application.
(I’m probably unusual, in
a) spending so much of my time actually doing this… (I must be out of my mind…) and
b) having developed all the DSP, graphics toolkit etc, across all the supported platforms and OS - and even associated documentation, manuals etc - for the plug-ins I… attempt… to sell)
It is unusual that the SDK should be so large but as you mention VST3 has some GUI code in there too - though my preference (along with many other developers I expect) is to rely on my own GUI framework (others may use JUCE for example, or something similar, but they normally hook into the SDK at the same level)
I’m not even sure that VST3 fixes the single biggest problem in the VST API, which is the use of pointers in the API
This is a strange issue to highlight - in most cases, while there are some bits that are not ideal (I’m guessing you’re referring more to the dreaded use of something like VstInt32 to contain a pointer in some of the APIs), this is fixed up for 64Bit, and you can only run e.g. 32Bit plug-ins in 32Bit hosts or 64Bit in 64Bit etc, so this has never - to my knowledge - been a practical issue.