Bye bye VST2

[Music Engineer]

Arturia brings in over $2 million per month, perhaps $4 million. IK Multimedia brings in $1.5 million per month. And you can be sure neither of them are hacking VST2 plugins into a VST3 wrapper.

If a plugin manufacturer wants to target more than one plugin format, they will have use some sort of abstraction layer anyway because writing separate code for each supported plugin format would be a maintenance nightmare. Maybe some companies do that, but I doubt it. This abstraction may either be a self-made in-house thing or something like JUCE (class AudioProcessor, to be specific) or they may decide to elect one of the existing plugin formats to serve a similar purpose and then use a wrapper. Apparently, the latter is what many companies did so far with VST2. It may look like a "quick-and-dirty" solution but technically, if you use a compile-time wrapper, there isn't really much of a difference to an actual abstraction layer. So, I'd say, it's a viable option and not necessarily a dirty hack. If it works - who cares? A wrapper (or abstraction layer) is certainly easier to maintain and debug than half a dozen of different plugin implementations (of dozens or hundreds of plugins) each of which is written directly against the given plugin API. Arturia seems to use JUCE, by the way - they are listed here: https://juce.com/ (scroll down a bit to the "Companies Using JUCE" section)

[jamcat]

It's my understanding that Steinberg views MIDI-FX in VST2 as an unauthorized hack, and shut it down in VST3. My theory on this is that Steinberg views their MIDI features as defining selling points, and sees the ability to add MIDI processing features in other DAWs via plugins as a threat to their DAW itself. This is probably why there hasn't been a universal MIDI-FX standard.

ok...

While I have tried to point out that the obstacle to CLAP adoption is that there is no incentive for plugin developers to adopt a redundant plugin format like CLAP that doesn't give them access to any additional DAWs that they can't get with VST3...

ok...

someone should create some really kick-ass free MIDI-FX for CLAP, which is something that cannot be done with VST3. Perhaps that someone could even be you.

oh wait, there is an incentive* to get around Steinberg's anti-competitive actions. I'm not sure why it has to be free, but whatever.

* I got the feeling there are more, but if you want to stick with this one, ok.

It's not an incentive if no one is doing it. And so far, no one is doing it. They're all just focusing on using CLAP as a redundant audio plugin format to release stuff that's already available as VST3.

[gaggle of hermits]

It's been my experience that after writing automation with the VST2 versions, it doesn't sound quite the same on playback. But I haven't experienced that with the VST3 versions.

what do you mean "doesn't sound the same"? what, each time? depending on the automation mode?

and are we talking host automation or midi here? most of the time, I'm using midi cc to control pretty much all the important real-time manipulations. I'd only use host automation for things like positioning and playback parameters like body resonance etc. I've yet to come across a situation where I'd need to make micro edits in host automation channels.

[jamcat]

Arturia seems to use JUCE, by the way - they are listed here: https://juce.com/

But only for their GUI implementation. The rest is self-made in-house.

[gaggle of hermits]

It's not an incentive if no one is doing it. And so far, no one is doing it. They're all just focusing on using CLAP as a redundant audio plugin format to release stuff that's already available as VST3.

I'm not sure you understand what an incentive is.

[gaggle of hermits]

I didn't say Urs or u-he are hacks. I respect what Urs has built with u-he, actually. I just don't believe that the major audio firms that bring in $1 million+ a month are wrapping VST2 plugins in VST3 clothing. But maybe a bunch of smaller indie guys are, and maybe those are the peers that Urs surveyed?

you probably want to lay off syllogism. it's not really your field by the looks of it.

a sizeable org that has built up a large chunk of technical debt is *more* likely to do a full rewrite on its entire code base? sounds legit.

This sounds more like an argument against adding support for a new plugin format like CLAP.

from what I've seen, CLAP doesn't require a complete rewrite of a code base to use it.

you may think it's smart to keeping moving the goalposts around but you're just wrapping yourself into a pretzel.

[ampetrosillo]

But by the way, jamcat's argument is: VST2 has been dead for fifteen years, you should have expected this. NO. I can't remember an instance when a company not only deprecated a previous version of its own software, but it also actively went after users of past versions. I'm not going to say that this is unprecedented, because I suspect that this has happened before, sadly, but it is certainly far from the norm.

Besides, there are some other examples of new versions never truly catching on. There are some other libraries whose new versions were controversial (to say the least) and that still haven't really caught on 100% even years after their introduction (eg. GTK3).

[Music Engineer]

Arturia seems to use JUCE, by the way - they are listed here: https://juce.com/

But only for their GUI implementation. The rest is self-made in-house.

Maybe. Are you sure about this? But anyway - this doesn't really matter because my point is: whether they use their own in-house plugin-format abstraction-layer or juce::AudioProcessor or a (compile-time) wrapper around one of the other formats (i.e. VST2) - in any of these cases, there will be some function-call delegation and perhaps data conversion be going on under the hood. So, from a performance point of view, it's not so clear if a wrapper would be inferior to an actual abstraction layer. And from a maintenance/debugging point of view, there isn't really much difference either. And from a feature-set point of view - well - OK - in this case, a wrapper around, say, VST2, would imply a limitation to the feature set of the wrapped format - actually a limitation to the intersection set of the features of the wrapped and target format. A true abstraction layer could provide the set union of the feature-sets of the abstracted formats and enable or disable features for the different formats. So, in this sense, a true abstraction layer can be better than a wrapper - but only if you really need the features that would otherwise be unavailable. If you don't need them anyway, a wrapper should be fine as well. Performance-wise, the ideal situation would be to use neither a wrapper nor an abstraction and instead code directly against the plugin-API(s) - but as said - that's not really a viable path if you want to target multiple plugin formats.

[Funkybot's Evil Twin]

KVR: where wildly successful plugin developers can come to waste time bickering with end-users who think they know more about plugin development!

Jamcat, you're not the expert here. The actual developers from U-he, Bluecat, Audiority are. Your posts are about your beliefs, assumptions, things you may have surmised on your own, or came about secondhand. The people who do this for a living and running successful companies have actual insight to share. I'm sure they frequently engage with other developers outside of their own companies and this isn't just Urs and a few other dummies running their successful plugin development businesses wrong. It's a bit outrageous to think otherwise to think you'd know more, but hey, that's the [bad part of the] internet for you! Your posts read more like religous beliefs than anything rational. It's like a cult of personality around a plugin format. You don't know which big developers, if any, are wrapping VST2 plugins. You just want to believe they don't because it supports whatever argument you were spouting off on at that particular moment. You don't know what IK, or Arturia, or Waves, or Plugin Alliance think about this because you don't represent them and they're not here. Maybe they're just as p*ssed off and impacted by this as indie developers, if not even more so due to their giant catalogs! But you're making assumptions about what they must be doing and using them to support this tirade of yours.

Anyway, Reaper has a nice feature that lets your prioritize what format appears in the browser when you have multiple versions of the same plugin. It's easy enough for me to put CLAP first.

[seafire]

Argumentum ad verecundiam isn't evidence.

I would like to see the data from this survey. That would be evidence.

So I guess I should have taken notes then?

Always. He will want to see your accounts too after you threw in the 100k plus figure

Why wouldn't I believe that? It's not really impressive. At ~20 employees, that's only 5k each per month. Arturia brings in over $2 million per month, perhaps $4 million. IK Multimedia brings in $1.5 million per month. And you can be sure neither of them are hacking VST2 plugins into a VST3 wrapper.

I can't be sure of anything in that paragraph. I haven't looked at their accounts or their code.

If you have, maybe you can provide the evidence.

[kinkajou]

Anyway, Reaper has a nice feature that lets your prioritize what format appears in the browser when you have multiple versions of the same plugin. It's easy enough for me to put CLAP first.

This also applies to Bitwig...

[FrettedSynth]

Steinberg 15 years, That's way more time than Microsoft gives you. It's really no more complicated than that.

I can't believe there were three more pages with Jamcat after that statement. Microsoft has been one of the best for backwards compatibility. Applications that I ran on win98 still run fine on win10, most likely win11, I wouldn't know gave up on Windows. What you have been spouting is a joke right.

Hell my old Maudio 1010 still ran on Win10. All are still usable on Linux.

[fuseaudiolabs]

Hi,

I genuinely wonder why they should still include the VST2 wrapper files in the latest VST SDK (v3.7.10) if they really intended to finally drop VST2 for good and changed the accompanying license agreement in a way that it would now prohibit the development and distribution of VST2 plugins or VST2 capable hosts.

As far as I know this only affects new developers who have signed the agreement after 2018. Here's what the VST3 SDK Licensing FAQ has to say:

Q: I am a developer/company and I want to develop and distribute a VST 2 plug-in and/or host in binary form.

• If you have signed the VST 2 license agreement (before October 2018), you can.

• If not, you are not allowed to distribute it!

• See here!

I have brought this up on the Steinberg VST SDK forum. Let's see how they respond.

Best,
Ray

[mi-os]

Is there a discussion on Steinberg forum about this? All these things are better discussed with them participating. The discussion here is rather one-sided.

I think SB should release a statement explaining their position/direction. Maybe rethink some aspects beforehand. But most importantly talk with devs/users about surrounding issues.

From what i read MIDI (controller?) handling and VST2s that will never make it to VST3 (legacy project compatibility) are the main issue for me personally.

ps
Just for fun someone should add up every VST plugins ever sold. What kind of number are we talking about? How many people are making a living from it for years? It's probably not all negative.

[zvenx]

Ray, as he mentioned above, asked in SB's developer forum..
We shall see.
rsp