VST2 support, "legacy versions" and plugin blocking

[hannesmenzel]

First I'd like to say that this app is very welcomed, so thanks for the developement effort. I do have some questions:

• Do you plan VST2 support or is this impossible because of the Steinberg VST2-licence issue? I think there would be some use for this feature.

• There are some users who might not be one the most current versions of some plugins. Let's say you're stuck with a former version of Arturia V-Collection, Kontakt or some iZotope stuff, it would be great to have a category for that. There might be the workaround to just exclude them from syncing, but i assume it wouldn't be in the list then, right?

• For the first time I had the issue that a plugin installation while having the KVRSM running was not possible (read/write access denied) . I think I did not have that issue while having a daw-host running. Is there a workaround?

[jamcat]

My guess is that VST2 support (on Windows) would be difficult because there is no fixed VST2 plugins folder. The app would have to scan your entire hard drive and compare every .dll it finds to a master list of plugins on the server. That's not realistic and it wouldn't be welcome by anyone.

Besides, VST2 is a dead format. I doubt DX plugins are ever going to be supported either.

[NateKVR]

• Do you plan VST2 support or is this impossible because of the Steinberg VST2-licence issue? I think there would be some use for this feature.

We'd like to add this yes, but it's not a priority right now since, as you mentioned it's essentially a dead format, and most legacy VST2 plugins that would remain in that format only are very unlikely to be updated. Would be nice to still have it as an option but it adds complications and I think we'd rather get the database up to speed with VST3 and AU first. We looked at .aax as well... also a little complicated as Avid won't allow .aax plugins to be instantiated outside of Pro Tools.

• There are some users who might not be one the most current versions of some plugins. Let's say you're stuck with a former version of Arturia V-Collection, Kontakt or some iZotope stuff, it would be great to have a category for that. There might be the workaround to just exclude them from syncing, but i assume it wouldn't be in the list then, right?

We already do this, right click a plugin in the list and choose 'exclude from sync'. It will remain in the list but just won't connect to our server to check for updates. You can also hide plugins from the list entirely (They'll be available again in the hidden tab).

• For the first time I had the issue that a plugin installation while having the KVRSM running was not possible (read/write access denied) . I think I did not have that issue while having a daw-host running. Is there a workaround?

Was it by any chance Arturia plugins you were updating? I've found the Arturia Software Centre is extremely sensitive to any app that might be looking at the plugin folder. I've had this come up with some brands, both with KSM and in a DAW... most should be fine though in my experience.

[hannesmenzel]

I think VST2 is not dead until CLAP is fully adapted by plugin developers because VST3 have some serious MIDI issues, including Arturia and IK Multimedia. I tend to install VST2 only for specific virtual instruments.

Concerning the blocking issue: No, it was Surge XT which claimed the CLAP plugin beeing blocked during installation.

[jamcat]

We looked at .aax as well... also a little complicated as Avid won't allow .aax plugins to be instantiated outside of Pro Tools.

So KVR Studio Manager doesn’t merely do a file search of the plugins, it actually acts as a dummy host and scans/loads them?

[underscoreraven]

We looked at .aax as well... also a little complicated as Avid won't allow .aax plugins to be instantiated outside of Pro Tools.

So KVR Studio Manager doesn’t merely search for the plugin files, it actually acts as a dummy host and scans/loads them?

Pretty sure that's standard and necessary to extract the metadata needed.

For comparison, in FL studio you got a fast and full scan, fast just lists the files with no info but only with a full scan, that opens the plugins like KVR, do you get info like whether it's an Instrument or Effect, Developer & Name. I'm guessing here it's used for features like showing the current version & through that whether there are updates available

[Ben [KVR]]

We scan the default directories for VST3, CLAP and AU to get the file list but you can add additional VST3 paths from the Options menu.

VST3 and CLAP use the JUCE scanner which, I believe, instantiate the plugins to get the additional info required. The AU scanner is a custom one that looks in the plugin's plist to extract the data, so the AU scanner is much faster and doesn't trigger pop-up iLok activation windows, etc.

As far as we can tell, AAX would require instantiation of some sort, which is not possible if you aren't Avid.

[D-Fusion]

-----

[DaveL60]

We scan the default directories for VST3, CLAP and AU to get the file list but you can add additional VST3 paths from the Options menu.

As someone who recently transitioned to a new PC and am already feeling a bit like plug-ins are getting scattered about, I'm interested in what you consider "the default directories". Please to enlighten?

[seafire]

The ones that the installers point to.

[neverbeeninariot]

We scan the default directories for VST3, CLAP and AU to get the file list but you can add additional VST3 paths from the Options menu.

As someone who recently transitioned to a new PC and am already feeling a bit like plug-ins are getting scattered about, I'm interested in what you consider "the default directories". Please to enlighten?

On Windows, the default directories for 64 bit are:

c:\program files\common files\clap
c:\program files\common files\vst3

... plus the equivalent Program Files (x86) folders for 32 bit.

Some vendors may use sub-directories for their brand at those locations.

Anywhere else is non-standard. VST2 could be installed anywhere (no defined standard)

[hannesmenzel]

Anywhere else is non-standard. VST2 could be installed anywhere (no defined standard)

There might be no standard, but C:\Program Files\VstPlugins and C:\Program Files\Steinberg\VstPlugins is used by most installers and hosts as default I guess.

[sjm]

For VST2 on Windows, there's a registery entry that you can use to define the path (which can be anywhere you want). Unfortunately, a fair few devs forgot to RTFM and ignore this on installation, which can contribute to a sprawling mess.

The VST3 folder is defined in the spec.

https://helpcenter.steinberg.de/hc/en-u ... on-Windows

[MirkoVanHauten]

Just saying, I have 95% VST2 plugins installed and there's no need to switch to VST3 at all. Adding VST2 search paths to KSM shouldn't be an issue. All other plugin managers have done that too

[neverbeeninariot]

For VST2 on Windows, there's a registery entry that you can use to define the path (which can be anywhere you want). Unfortunately, a fair few devs forgot to RTFM and ignore this on installation, which can contribute to a sprawling mess.

Well remembered! I vaguely recall setting these some time ago to try and keep everything together.

FWIW (given that many devs ignore it), the keys (and my paths) are :

[HKEY_LOCAL_MACHINE\SOFTWARE\VST]
"VSTPluginsPath"="C:\\Program Files\\Common Files\\VST2"

and

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VST]
"VSTPluginsPath"="C:\\Program Files\\Common Files\\VST2"