Waves Audio Plugins

[Tez]

My scan option is set to Automatic Background Scan, and typically on a CbB startup when there’s no new plugins the scan popup will show either searching for plugins and/or the Scan Complete no new plugins found list and no plugin scan notice, but since adding a Waves Audio plugin this shows up as being scanned, albeit very swiftly, prior to no new plugins found list each time on a CbB startup. The WA plugin is an indirect Shell to the actual plugin, is this why the scan occurs or, in general, a quirk of Waves Audio, or something else?

[scook]

Plug-ins that load from a shell must be scanned every time.

I believe those using these types of plug-ins run scans manually as needed.

[Tez]

2 hours ago, scook said:

Plug-ins that load from a shell must be scanned every time.

I think basically you're right which is good to know & now to be expected thank you very much. This plugin loads in 3 flavors and on an initial 1st time scan I'm sure I saw multiple scans resulting in 3 new plugins per vst2/3, but on subsequent  startups it's seems only the shell for each vst gets a token scan which is really fast and not significantly adding to the startup time, if at all.  So, right now an auto scan is just fine.

[Starship Krupa]

20 hours ago, Tez said:

This plugin loads in 3 flavors

As an experiment I tried deleting the VST2, AAX, and all 32-bit versions of the WavesHell dll and it had no ill effect. Now CbB and others scan only the 64-bit VST3 versions. If you have different versions of Waves plug-ins, you do need to keep the multiple VST3's, but otherwise thinning them out worked fine on my system.

[Tez]

2 hours ago, Starship Krupa said:

thinning

Yes, it's a matter of choice keeping both vst2 & vst3 versions of a plugin,  a vst3 may not be suitable for all cases depending on the plugin and it's intended use. In  this case the shell loads all 3 plugin flavors so only the shell needs to be on the CbB's vst path, and it seems that the plugs the shell loads get scanned once on the first time loaded, but the shell gets scanned each CbB startup, this behavior, albeit  normal for a shell, was something new too me hence the OP.  Regardless the shell scan is lightning fast. The plug-in manager lists all plugins loaded by the shell with unique VST IDs, but all have the same filename which is the shell's and there are no individual .dlls or .vst3s  for these VSTs which I think are embedded in a lib .dll file ?...

Edited June 6, 2021 by Tez

[Starship Krupa]

Yes, there are some VST's where I keep the VST2 version around because one of my hosts crashes with the VST3. VST3 is the New Coke of audio plug-in technology. Nobody asked for it, everyone except the company who made it prefers the earlier version.

However, if you're getting three scans, that's one too many. I bet one of them is for a 32-bit version. Not hurting anything, just unnecessary.

Not everyone (I'd say few people) are as fussy about this as I am. I sent a letter to A|A|S asking them to stop spamming my C: drive with copies of their plug-ins. Their installer used to put in multiple copies of the 64 bit VST2, the 32 bit VST2, the 32 and 64 bit VST3's, 64 and 32 bit AAX, and even the RTAS version. Just in case I had a 20-year-old Pro Tools system I guess. At its worst I counted over 12 different install locations where I would delete the extra plug-ins.

I had a folder called "A|A|S Wipe" that had shortcuts to every location on my drive where they put their plug-in, and I'd go in there after every A|A|S install and weed them out. Now they've stopped with the redundancy, and no longer even supply 32-bit versions. All the weeding I do is for the VST2 and AAX versions, which is much more manageable.

[Craig Anderton]

Also FWIW, if you use amp sims, a lot of the VST2 ones respond to program change messages, but not the VST3 versions.

[Tez]

2 hours ago, Starship Krupa said:

three scans, that's one too many

I think you misunderstand, no offense, the shell loads 3 distinct 64 bit plugins which only get scanned once when the "shell plugin" was first installed and the vsts are registered, after that it's just the shell that gets scanned each time CbB starts up, the shell is just the front end for each plugin which  the shell extracts,  in my case, from a "WavesLib1.14_12.7_Win64.dll" file,  there is no individual vst plugin dlls or vst3 files except the shell which for the vst3 is "WaveShell1-VST3 12.7_x64.vst3". Now I'm assuming that the shell maybe generic, capable of loading vsts from other libs if and when a new lib is installed and then the vsts that get loaded would be scanned when first registered. Again, no 32 bit plugins are involved and plugins loaded by the shell are scanned when first registered, and appear in the plug-in manager.  It's possible the shell gets scanned every time to see if a new lib was installed, that's my conjecture. As for AAS the old installers splattered vsts all over the place, I know all the locations, but the only ones I'd delete were in the Cakewalk\VstPlugins folder the only location on my CbB's and Splat's  vst path I didn't specify. The new installer is cleaned up putting the 3s in the default location and the 2s where you tell it, yahoo!

 

1 hour ago, Craig Anderton said:

program change messages

I believe I saw this in one of your prior posts,  that was what I implied by "a vst3 may not be suitable for all cases" and FWIW I also seem to remember that some vst2s were needed to take advantage of NKS support despite an available vst3.

Edited June 7, 2021 by Tez