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?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.
Bye bye VST2
-
- KVRAF
- 2772 posts since 28 Mar, 2007
-
- KVRist
- 131 posts since 18 Sep, 2021
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.
- Beware the Quoth
- 35437 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
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."
"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."
-
- KVRAF
- 2772 posts since 28 Mar, 2007
Interesting. Thanks.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.
- KVRer
- 4 posts since 15 Sep, 2014
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.
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.
-
- KVRian
- 1119 posts since 4 Jan, 2007
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.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.
- KVRAF
- 2034 posts since 30 Mar, 2008 from MN, USA
No idea, and you are the only one who seems to care.jamcat wrote: Mon Mar 18, 2024 11:00 pmYou 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?
CLAP Software Database: https://clapdb.tech. KVR Discussion Topic.
-
- KVRAF
- 3401 posts since 6 Nov, 2006
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.mi-os wrote: Tue Mar 19, 2024 12:26 pmYeah, 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'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.
-
- KVRist
- 143 posts since 5 Oct, 2001
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?Urs wrote: Tue Mar 19, 2024 11:43 amA 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.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
- KVRAF
- 2627 posts since 16 May, 2004 from Soviet Union
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.
- u-he
- 30194 posts since 8 Aug, 2002 from Berlin
Well, if someone wanted to do that, sure.Cochrane wrote: Tue Mar 19, 2024 4:09 pmWhat 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?Urs wrote: Tue Mar 19, 2024 11:43 amA 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.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
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.
-
- KVRist
- 414 posts since 26 May, 2018
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.Urs wrote: Tue Mar 19, 2024 5:02 pmWell, if someone wanted to do that, sure.Cochrane wrote: Tue Mar 19, 2024 4:09 pmWhat 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?Urs wrote: Tue Mar 19, 2024 11:43 amA 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.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
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.
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?
-
- KVRist
- 248 posts since 13 Oct, 2018
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... ?!?
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... ?!?
-
- KVRist
- 439 posts since 4 Oct, 2002
For what purpose?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?
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.
