Bye bye VST2

[zvenx]

As always BaconPaul... well said.
rsp

[wikter]

I wonder in the long term when Ableton adopts clap and then eventually Steinberg makes something stupid and DAW developers drop VST support, what will happen to VST if it is only confined to Cubase/Nuendo, would be enough for developers to justify keeping ports for it?

The same file used for CLAP can be used for VST3. Just change extensión and if things are done on the right way, It will do the job.

[jamcat]

I wonder in the long term when Ableton adopts clap and then eventually Steinberg makes something stupid and DAW developers drop VST support, what will happen to VST if it is only confined to Cubase/Nuendo, would be enough for developers to justify keeping ports for it?

One of the things CLAP is needed for is to prevent the owners of legacy platforms from making policy changes that support CLAP. Without CLAP they can do whatever they want, the have all the leverage. With CLAP, that leverage is lessened because a drastic change would push developers towards CLAP.

yeah this thread is odd and some of the users here seem way more opinionated than i would think a non-developer would be about an api, but Urs let me reinforce this.

CLAP, as a programming model, is way easier than VST3, AUv2, AUv3, AAX etc... - the code is clean simple and well laid out. And that's not enough to get devs excited.

The thing which really matters about clap is

1. It is liberally licensed and there is no controlling party who can restrict you from using it
2. So you can use it for the base of your development unencumbered

Since *every* plugin you run which supports > 1 format is, in a technical sense, wrapped (I mean come on, do you think there's two copies of every bit of code for the VST3 and the AUv2?), all plugin authors end up with some form of unifying abstraction. For juce this is `juce::AudioProcessor`, and there's an equivalent in iPlug, distrho etc.... For plugins which roll their own API handlers they all have some internal abstraction so things like 'plugin gets midi message' can route to 'my code which does the midi stuff'

The nice thing about CLAP is it is a format which is reasonable as the basis for that abstraction. It's simple, robust, clear, easy to code, etc... and most importantly, IP unencumbered.

Imagine if you were a company who had, for that abstraction, used VST2 and then all of a sudden the license change happens. Your entire product line is at risk. You should not re-tool based on another toolkit with that exposure.

So the benefit of CLAP to a developer is you can use a shared abstraction which presents no IP overhang risk to your business. We have proof that CLAP can be invisibly projected into AUv2, VST3, Standalone, and (not yet in our mainline) AAX.

The fact that also, by doing so, you can run *directly* in a swath of popular DAWs (bitwig, FL, S1, Reaper, MTS, a collection of open source daws, a collection of re-hosters) with just that code is a boon, as is the fact that those DAWs can use extended features.

But for a commercial developer, segregating their exposure to the license oddities of the various other toolkits is a real benefit.

This has come up several times in previous conversations, and it makes sense. At some point I think a standard dev process that uses CLAP as the base will become established. I think this will depend heavily on CLAP integration into JUCE. It seems like it might require a pretty heavy rewrite to replace VST2's role within JUCE with CLAP.

My main focus though, is on existing plugins. Perhaps a lot of people engaging in this discussion don't actually own that many, but I do, and I have paid real money for them. One thing I know about programmers from experience is they take the path of least resistance, and do not like to do more than necessary. That's not to say they're lazy, but it's easy to break code and difficult to fix it. It's a can of worms no one is eager to open if they don't absolutely have to, and there is currently nothing incentivizing developers to put the work into adding CLAP support to the plugins they've already created, and no easy path right now to do it, either. So while CLAP as a basis going forward will likely become common in the future, particularly where it becomes a replacement for VST2 in that role, the path for moving the thousands of existing plugins over to CLAP does not seem so clear, and the outlook does not look so rosy. I've tried to impress upon people why that is the case.

[EvilDragon]

I think this will depend heavily on CLAP integration into JUCE. It seems like it might require a pretty heavy rewrite to replace VST2's role within JUCE with CLAP.

Yes, and this is already planned for JUCE 9. This will also make JUCE AudioProcessor support sample-accurate automation (currently plugin formats which support sample-accurate automation produced by JUCE don't implement that functionality at all).

[baconpaul]

I think this will depend heavily on CLAP integration into JUCE. It seems like it might require a pretty heavy rewrite to replace VST2's role within JUCE with CLAP.

Yes, and this is already planned for JUCE 9. This will also make JUCE AudioProcessor support sample-accurate automation (currently plugin formats which support sample-accurate automation produced by JUCE don't implement that functionality at all).

Yeah. As to difficulty, well jamcat has one opinion (which seems to think that vst2 is central to juce, perhaps confusing the vst2-like nature of their shared class with vst2 itself) , and I wrote the clap juce integration which many clap plugins use today. So .

Making juce eject a clap plugin with an extension to juce was tricky but it was weeks tricky. I’m excited for the juce 9 improvements also!

[MrJubbly]

I think this will depend heavily on CLAP integration into JUCE. It seems like it might require a pretty heavy rewrite to replace VST2's role within JUCE with CLAP.

Yes, and this is already planned for JUCE 9. This will also make JUCE AudioProcessor support sample-accurate automation (currently plugin formats which support sample-accurate automation produced by JUCE don't implement that functionality at all).

Yeah. As to difficulty, well jamcat has one opinion (which seems to think that vst2 is central to juce, perhaps confusing the vst2-like nature of their shared class with vst2 itself) , and I wrote the clap juce integration which many clap plugins use today. So .

Making juce eject a clap plugin with an extension to juce was tricky but it was weeks tricky. I’m excited for the juce 9 improvements also!

Any rough estimates on when that JUCE 9 with CLAP support (and other features) might start to be rolled out / made available to the audio plugin developers themselves?

Is it roughly a year away, 2 years, 3 years, etc?

I own a lot of plugins from many different developers and want to request CLAP support from them. But I am also aware that many use JUCE and so are likely waiting for the native support to be added.

I would like to time my CLAP support request emails to them in the run up to JUCE 9's release. As they may have more traction with those devs.

[baconpaul]

As much as it surprises me to agree with jamcat, I agree that the thousands of plugins which are no longer substantially updated will continue to not be substantially updated. Things like os or architecture changes and so on will eventually make them harder to run and leave us with a legacy of non updated plugins, some of which you paid for

I don’t think any of us in clap land thought that port to clap as an activity in its own right just to have another DLL was that exciting. And (functionally) abandoned software won’t do it of course.

But loads of devs are active today. Some juce devs shipped clap using the extension we have. Some iplug devs added it in an update. Some custom framework devs added it too. So I would say among plugins with active indie devs the take up has been pretty good. And getting into juce mainline so it is just a switch will help immensely

In the audio space we’ve had two new broadly applicable plugin things in the last 4 years which require plugin updates - clap and Mts-esp (ara2 is a bit older and bit more specific). Both have, I think, really good uptick. Of my new plugins lots of one and some have both. The fact that some have neither is also ok. But understanding the benefit and propagation of these two items may help you get a better idea about cadence and development processes in the audio plugin space, which if I charitably squint, your questions seem aimed at.

But if your point about clap is “software which isn’t changing doesn’t change”, I whole heartedly agree!

[baconpaul]

Any rough estimates on when that JUCE 9 with CLAP support (and other features) might start to be rolled out / made available to the audio plugin developers themselves?

I'm not on the JUCE team, although I've been talking to them about this topic obvious since JUCE users ejecting clap today use code that I wrote with jatin. As such I can't answer this question. Their roadmap is here https://juce.com/blog/juce-roadmap-update-q3-2024/

I own a lot of plugins from many different developers and want to request CLAP support from them. But I am also aware that many use JUCE and so are likely waiting for the native support to be added.

I would like to time my CLAP support request emails to them in the run up to JUCE 9's release. As they may have more traction with those devs.

Yeah i think this is smart. Once JUCE 9 ships asking those authors if they could consider turning on CLAP in their pipeline when they update JUCE is friendly; asking before that is likely going to fall on deaf ears. Devs who wanted to ship with the unofficial juce clap extensions already have, and I think its reasonable for other devs to wait for it to mainline.

[wikter]

I don't see Arturia updating their VCollection to clap soon, Native also seems to be away from updating their Komplete package, but hey, in more than 10 years as a user of their plugins I never needed VST3 and VST2 is still supported and working fine.
My next planned acquisitions took a direct part in Clap format development (U-he, TAL) and now that I'm switching from Studio One to Bitwig and Shortcircuit is close to a release... I can finally see VST3 headaches fading while all those OLD & (thanks to Steinberg) OBSOLETE VST2 32 & 64 bit keep doing a good job.
In the end, I also own hardware that rely on old standards like MIDI & analog audio, or even older acoustic sound transducers whose builders already left this world.
That's what VST3 is against and all the Virtual plug-in user community must support. Why did Steinberg decide VST2 must be eroded & erased?? Anyone not understanding that this is about the size of MIDI association releasing a MIDI V2 spec forcing incompatibility with & forbiding MIDI V1 products. A real shot at their feet.

[Andreya_Autumn]

...Midi 2 is very much backwards compatible? That was an essential part of the design vision.

EDIT: Oh I see what you're saying. "This is about as bad as if MMA did... etc". My misunderstanding sorry.

[baconpaul]

Shortcircuit is close to a release...

As long as this thread doesn’t suck up all my time that is

[wikter]

...Midi 2 is very much backwards compatible? That was an essential part of the design vision.

EDIT: Oh I see what you're saying. "This is about as bad as if MMA did... etc". My misunderstanding sorry.

Yep, sometimes my spanish complex grammar skills take control over english. English IS not that flexible...

[wikter]

repeated.

[seafire]

...Midi 2 is very much backwards compatible? That was an essential part of the design vision.

EDIT: Oh I see what you're saying. "This is about as bad as if MMA did... etc". My misunderstanding sorry.

Yep, sometimes my spanish complex grammar skills take control over english. English IS not that flexible...

English is not that flexible

[EvilDragon]

English is so flexible that even the most broken form of it can still retain the intended meaning, actually!