Bye bye VST2

VST, AU, AAX, CLAP, etc. Plugin Virtual Effects Discussion
Post Reply New Topic
RELATED
PRODUCTS
VST 3 Plug-in Development Host VST Audio Plug-ins SDK (C++)

Post

Urs wrote: Tue Mar 19, 2024 11:43 am
A VST2-as-CLAP wrapper can't be GPL'd because the VST2 license is incompatible with any version of GPL. Such a wrapper can only ever be closed source and needs to be published by someone who still has a valid VST2 license.
I realise I am citing Linux,and not OSX or Windows, but how is Yabridge able to wrap VST2 - VST3 - Clap under GPL without contravening the Steinberg licence?

Post

Yabridge uses the Vestige headers, a GPL licensed basic alternative to the official VST2 headers. The Vestige authors claim their implementation is a clean room reverse engineered effort, as do the other alternatives out there (FST, Xaymar, RST, probably more). But companies are not prepared to test the clean room claim in court.

Post

mi-os wrote: Tue Mar 19, 2024 12:26 pm It's lame for how long many plugin devs refused to jump at the command of Steinberg


ftfy.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."

Post

diroxe7660 wrote: Tue Mar 19, 2024 12:48 pm Yabridge uses the Vestige headers, a GPL licensed basic alternative to the official VST2 headers. The Vestige authors claim their implementation is a clean room reverse engineered effort, as do the other alternatives out there (FST, Xaymar, RST, probably more). But companies are not prepared to test the clean room claim in court.
Interesting. Thanks.

Post

As an end user:

Terrible! I have so many old tracks and sessions that I won't be able to open and play back any more if VST2 versions of the plugins (that I have VST3 versions of by now) got removed from my system or were not available for installation any more after the next system change! Especially given the lack of one standardised and working migration path.

Also I still sometimes have the experience that a certain VST3 plugin does not work, and when I instantiate its VST2 counterpart, it works flawlessly. Last time it happened to me it was the Sub 37 Editor plugin by m00g not too long ago, like 3 months or so.


As an audio engine / plugin developer:

They do it to not look as shortsighted any more. I mean the decision to discontinue VST2 support in their own hosts was not the smartest one especially since it was soo damn easy to make the 'old' standard work in hosts and plugins alike even when architectures change like with Apple's recent switch to ARM. Now they ended up in a situation where only the 'owner' of the most wide spread format stopped to support it. And all others do it just fine. And that makes them look not smart to say the least.

Why is it that everyone else keeps supporting it? I guess they underestimated the fact that no one really likes COM-like interfaces like in VST3. My hunch is that if a developer community hesitates to make the switch and discontinue the predecessor for over a decade, it might not be the exact solution to their problems...? Many devs still having problems to get their VST3 versions as stable and reliable as their VST2 counterparts also does not really speak for the VST3 interface. Be it the interface itself, its documentation the different interpretation in different hosts or a mixture of all of those ingredients.

Instead of bullying the partners (that made their standard a standard in the first place) out of their agreements that promised a lifetime license, they could as well be very proud of what they achieved with VST2 and out of that pride continue to support it as long as they possibly can. The comparison might be a bit dull but my wife works for the world market leader in waffle makers. When an old lady walks into their HQ with a 70 year old waffle maker, they will repair it - just out of pride that the device kept working for so long. And I totally understand that!

That being said, there might be good reasons for them to discontinue it but I would strongly tend to reconsider in their shoes. Especially the way they do it. They could simply allow everyone to keep their lifetime license, support it as long as they want but fade it out in their own product lines as they wish - everyone is happy.

Post

diroxe7660 wrote: Tue Mar 19, 2024 12:48 pm Yabridge uses the Vestige headers, a GPL licensed basic alternative to the official VST2 headers. The Vestige authors claim their implementation is a clean room reverse engineered effort, as do the other alternatives out there (FST, Xaymar, RST, probably more). But companies are not prepared to test the clean room claim in court.
They don't need to if they don't distribute the wrapper. Imagine an OSS utility that you point it to an installed VST2 (or many) and it spits a clap wrapper (or many). It doesn't need any DAW or Plugin vendor involvement.

Post

jamcat wrote: Mon Mar 18, 2024 11:00 pm
teilo wrote: Mon Mar 18, 2024 10:52 pm
jamcat wrote: Mon Mar 18, 2024 10:32 pm So how did you or anybody else get "Apple Silicon ⇒ No VST2" from that?
VST2 wasn't even mentioned.
Feel better?
You compiled the ASaudio.tech database, so you would have pretty good insight into this question:
How many native Apple Silcon plugins other than Airwindows don't support VST3?
No idea, and you are the only one who seems to care.

Post

mi-os wrote: Tue Mar 19, 2024 12:26 pm
dayjob wrote: Mon Mar 18, 2024 10:13 pm
mi-os wrote: Mon Mar 18, 2024 9:46 pm VirSyn was already coding VST3 plugins when many of you weren't even born yet. :o :clap:
And? But also, no.
Yeah, i know it's mostly old geezers. Inlcuding myself. So let's say 'some' not 'many'.

It's lame for how long many plugin devs refused switching to VST3. Also DAW devs for not supporting it. VirSyn showed it was usable many years ago. I'm pretty sure if adaption would have happened earlier Steinberg would have addressed concerns with some implementation details earlier as well.
i think that's speculation at best. no one knows what they would or wouldn't have done based on behavior of developers. they don't seem very supportive based on stories people share here. it's clear a lot of devs viewed vst3 as worse than vst2 in every way. also, steinberg themselves said that vst2 was 'abused' and they never intended for it to be used in the way it was.. for example.. all the work arounds devs found for making midi plug ins etc.. this was never supposed to happen according to steinberg. there's posts on the forum about this and copy pasted word for word posts from steinberg about it.

i'm sure devs reached out asking for changes to vst3 but i don't recall the nature of all that. it would require digging in to those threads in the developer sub forum to find the answers.

generally, the characterization of steinberg's attitude is not pleasant and not supportive. at least that's what i remember from reading all the stuff over the last couple years.

obviously, a handful of devs getting together to make a new open source format to move away from all the BS is evidence enough that steinberg wasn't holding up their end... but i'm just an end user so can't say for sure.. as said.. read all that long ago and it's been pushed out of my memory to make room for other things.

Post

Urs wrote: Tue Mar 19, 2024 11:43 am
Cochrane wrote: Tue Mar 19, 2024 10:50 am IMHO, a GPL'd VST2-to-CLAP/VST2-to-VST3 'invisible' (for reloading old projects) wrapper is the future! :)

Cheers,
Cochrane
A VST2-as-CLAP wrapper can't be GPL'd because the VST2 license is incompatible with any version of GPL. Such a wrapper can only ever be closed source and needs to be published by someone who still has a valid VST2 license.
What I was thinking of is: if you make a (GPL'd or even closed source) VST2 wrapper only using VST2 ABI (and not a single line of the VST2 SDK's API but only pointers to memory locations in the target dll), maybe even not citing VST2 in neither GUI nor documentation, is this a loophole in the whole licensing stuff? Is it viable?

Post

Folks sorry i did not get (did not read all thread), do i right understand that this prohibition (will) applies to using vst2 read ability in things like mini-hosts too, like Bidule\Bluecats ? And utilities like JBridge.

Post

Cochrane wrote: Tue Mar 19, 2024 4:09 pm
Urs wrote: Tue Mar 19, 2024 11:43 am
Cochrane wrote: Tue Mar 19, 2024 10:50 am IMHO, a GPL'd VST2-to-CLAP/VST2-to-VST3 'invisible' (for reloading old projects) wrapper is the future! :)

Cheers,
Cochrane
A VST2-as-CLAP wrapper can't be GPL'd because the VST2 license is incompatible with any version of GPL. Such a wrapper can only ever be closed source and needs to be published by someone who still has a valid VST2 license.
What I was thinking of is: if you make a (GPL'd or even closed source) VST2 wrapper only using VST2 ABI (and not a single line of the VST2 SDK's API but only pointers to memory locations in the target dll), maybe even not citing VST2 in neither GUI nor documentation, is this a loophole in the whole licensing stuff? Is it viable?
Well, if someone wanted to do that, sure.

Most of us host and plug-in devs are however "contaminated" as we have or have had the actual SDK and actual licenses. The professional advice I was given was to not even think about using anything that claims to be clean room reversed.

Post

Urs wrote: Tue Mar 19, 2024 5:02 pm
Cochrane wrote: Tue Mar 19, 2024 4:09 pm
Urs wrote: Tue Mar 19, 2024 11:43 am
Cochrane wrote: Tue Mar 19, 2024 10:50 am IMHO, a GPL'd VST2-to-CLAP/VST2-to-VST3 'invisible' (for reloading old projects) wrapper is the future! :)

Cheers,
Cochrane
A VST2-as-CLAP wrapper can't be GPL'd because the VST2 license is incompatible with any version of GPL. Such a wrapper can only ever be closed source and needs to be published by someone who still has a valid VST2 license.
What I was thinking of is: if you make a (GPL'd or even closed source) VST2 wrapper only using VST2 ABI (and not a single line of the VST2 SDK's API but only pointers to memory locations in the target dll), maybe even not citing VST2 in neither GUI nor documentation, is this a loophole in the whole licensing stuff? Is it viable?
Well, if someone wanted to do that, sure.

Most of us host and plug-in devs are however "contaminated" as we have or have had the actual SDK and actual licenses. The professional advice I was given was to not even think about using anything that claims to be clean room reversed.
From a legal point of view, it is not easy to prove that something was *not* clean room reversed. You would need actual proof. That said, I realise that a company can't just take chances.

But!

All this situation really would call for a concerted effort on the part of the whole audio industry against Steinberg, since they haven't been playing fairly much (I mean, with this last development). What's stopping you from chipping in into a shared fund and kicking their arses in court?

Post

Just an almost off-topic question : it's been said a lot, in this conversation, that Ableton Live has a bad vst3 implementation.
What are the issues exactly ?
I was using vst2 almost exclusively until some months ago. Now that I switched to vst3, I don't find a lot of differences in real use (and I'm pretty demanding, because I use Live on stage and I need stability and reliability).
I prefer the fact that automation with vst3 shows the "true parameters", but that's it with vst3 advantages.
I have some issues with vst3 I don't have with vst2, but only with 2 or 3 plugins.
What I want to say is : I don't see exactly where are the issues with vst3 in Ableton Live... ?!?

Post

ampetrosillo wrote: Tue Mar 19, 2024 6:21 pm What's stopping you from chipping in into a shared fund and kicking their arses in court?
For what purpose?

Best possible (although not likely, some stars have to align) outcome of all of this is 3 walled gardens with their proprietary non-permissive formats and CLAP as a industry standard for everybody else.

Post

Yamaha has around $3 billion USD in revenues per year. That can pay for a lot of lawyering.
THIS MUSIC HAS BEEN MIXED TO BE PLAYED LOUD SO TURN IT UP

Post Reply

Return to “Effects”