VST2 support, "legacy versions" and plugin blocking

[NateKVR]

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

Well... CPU efficiency, multi output and surround support, per note events, sidechain support, parameter categorization... there are a couple of reasons at least to switch.

[hannesmenzel]

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 :-D

Well... CPU efficiency, multi output and surround support, per note events, sidechain support, parameter categorization... there are a couple of reasons at least to switch. :wink:

I would argue that the whole discussion about VST3-MIDI-support leading to the development of the CLAP format reveals some reasons to avoid VST3 in some cases. Same goes with re-reading my latest support tickets with Arturia.

Anyway, thanks for the good effort with this app, it's highly appreciated.

[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

Well... CPU efficiency, multi output and surround support, per note events, sidechain support, parameter categorization... there are a couple of reasons at least to switch.

I don't want go into an argument about how these are just Steinberg buzzwords and how almost all of this is already done & possible with VST2 and that only Steinberg users are forced to switch But I'd say that my situation is not uncommon and VST2 usage still is dominant. Until CLAP takes over of course.

[jamcat]

Security is literally non-existent for VST2 plugins.
VST2 plugins also don't contain parsable metadata like VST3 does, and they can be renamed simply by changing the filename. So correctly cataloging and version tracking them would be near impossible.

On Windows, VST2 plugins are .dll files, which are dynamically linked libraries, which are meant only to be internal program components. VST2 plugin loading presents a huge security hole that is susceptible to DLL hijacking. These are only a few of the many reasons Steinberg killed VST2 over a decade ago and are adamant about vendors dropping support.

I think KSM trying to support VST2 would open several large cans of worms, which is not worth it for a dead plugin format.

[MirkoVanHauten]

VST3 plugins are dll files with vst3 file extension. If there are security concerns, they apply to VST3 as well. Somehow no DAW or plugin developer is concerned supporting VST2 as the leading plugin format. With VST3 on the other hand... Anyways, I think I made my initial point.

[chk071]

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

Well... CPU efficiency, multi output and surround support, per note events, sidechain support, parameter categorization... there are a couple of reasons at least to switch.

I don't want go into an argument about how these are just Steinberg buzzwords and how almost all of this is already done & possible with VST2 and that only Steinberg users are forced to switch

Out of the box functionality vs. workarounds resourceful developers found.

But I'd say that my situation is not uncommon and VST2 usage still is dominant. Until CLAP takes over of course.

Yes, keep dreaming.

[BBFG#]

Are there some VST3 that are wrappers and therefore still require the VST2 to be there? And it's there a way for KSM to show when there is that dependence?

[jamcat]

VST3 plugins are dll files with vst3 file extension. If there are security concerns, they apply to VST3 as well. Somehow no DAW or plugin developer is concerned supporting VST2 as the leading plugin format. With VST3 on the other hand... Anyways, I think I made my initial point.

VST3 is much more locked down and picky about how plugins are allowed to interact with the host. That’s actually the primary complaint from the VST2-clingers, isn’t it? It’s also what makes VST3 more secure.

But let’s just focus on the basic obstacle to VST2 support: VST2 does not contain parsable metadata. A VST2 plugin is simply whatever the filename tells the host it is. The “vendor” is whatever you named the subfolder it’s in. It doesn’t transmit version data, or vendor/plugin information. How can you build a reliable cataloging and version-tracking system from that?

[MirkoVanHauten]

But let’s just focus on the basic obstacle to VST2 support: VST2 does not contain parsable metadata. A VST2 plugin is simply whatever the filename tells the host it is. The “vendor” is whatever you named the subfolder it’s in. It doesn’t transmit version data, or vendor/plugin information. How can you build a reliable cataloging and version-tracking system from that?

This is simply wrong. Took me 2 minutes googling to figure out, a VST2 plugin has "getProductString", "getVendorString", "getEffectName", "getPlugCategory" functions... And they are being read and parsed e.g. by FL Studio which then sorts these plugins into categories.

Our favorite DAW that now btw. supports CLAP. And I know forum members who will now be triggered by that