Steinberg Discontinuing VST2 Support in its products

Audio Plugin Hosts and other audio software applications discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

stargate wrote: Mon Jan 31, 2022 9:55 pm I wish the CLAP format all of the success in the world, but the odds are stacked against them. It's going to be almost impossible for them to get the critical mass of hosts and plugins required to succeed. Because VST(tm) is that name brand that consumers demand, with more inertia than a runaway train. Also, being "open source" only means that anybody can implement a CLAP host or plugin without unreasonable restrictions, the standard is still controlled by somebody who can completely screw it up (now or later), or hand control over to somebody else who will.

What they need is a broad coalition of major plugin and host vendors to come together and agree on a standard, governance, and most importantly, all agree to implement it. If Ableton, Bitwig, FL Studio, Xfer and some other plugin vendors not in bed with Steinberg joined forces to promote CLAP, then it will almost certainly become a thing.

The vast majority of users won't consider using something without VST support (please, ask me how I know that), and there is no clear path for CLAP to become so dominant that it replaces VST. Which leaves host developers with gambling on a huge burden of providing support for yet another plugin format, while still supporting VST in parallel for many years.
I would argue that although it would be nice, and helpful even, CLAP does not even need host support to succeed. All that is needed is a CLAP to VST3 wrapper. The developer can code with CLAP, wrap to VST3, and compile. CLAP would still be a success and make developers’ lives easier without the customer ever knowing the difference in their VST3 binaries.

Now truthfully, I fully believe that independent host developers will jump to make their DAWs natively CLAP compatible—there is no drawback other than a couple of days’ work, and there’s a lot to gain. But I don’t think even the lack of widespread native host adoption will slow CLAP down, as long as it makes development easier—even for VST3 apps.

As for a broad coalition? It was already tried and failed.

Also, another standard, LV2, failed to gain mass acceptance as well. It is a powerful and complete standard, but, like VST3, not easy.

This has a chance where others have failed, because it is not competing against VST3, but is complementary to it. Yet, it has the legs to stand alone as its own native format as well. This is why I think it has a good chance.
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.:mad:
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
:roll:

Post

Teksonik wrote: Mon Jan 31, 2022 10:05 pm
stargate wrote: Mon Jan 31, 2022 9:55 pm What they need is a broad coalition of major plugin and host vendors to come together and agree on a standard, governance, and most importantly, all agree to implement it.
The music production software world needs something like the MIDI Manufacturers Association:

"The MIDI Manufacturers Association was officially established as a nonprofit in 1985 with the goal to expand, promote, and protect MIDI technology for the benefit of artists and musicians around the world".

A similar organization would benefit both software developers and end users alike especially if there is going to be a new format.
This was done and failed.
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.:mad:
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
:roll:

Post

audiojunkie wrote: Tue Feb 01, 2022 2:36 am I would argue that although it would be nice, and helpful even, CLAP does not even need host support to succeed. All that is needed is a CLAP to VST3 wrapper.
We can, of course, agree to disagree on this point, but IMHO that's not nearly enough. How would that be compelling to plugin developers? If the only way to run CLAP plugins is to run them as a VST3 plugin using a wrapper, then why would a plugin developer waste their time on a CLAP port and a VST3 port instead of using VST3 exclusively? I really doubt anybody would choose to only write plugins that require a CLAP->VST3 wrapper to run, it's a needless abstraction layer at that point.

Steinberg, a single player in a large ecosystem, has been lording over the rest of the ecosystem for a long time using their SDKs and predatory licenses. The only way that changes is if the broader ecosystem decides to band together and share the responsibility of maintaining standards, instead of allowing a single company to control everything. But chances are Steinberg lawyers predicted this moment and added a "Thou shalt not conspire to overthrow Steinberg" clause to their agreements with the major players.

Post

Super Piano Hater 64 wrote: Mon Jan 31, 2022 10:33 pm
Yvan wrote:We will change the formulation in order to make it clearer.
This §9.7 does not apply to Host which already supports VST2, in this case your last signed VST2 license agreement is still valid.
For plugins developer we will add a transition period.
They did indeed "change the formulation" in a subsequent update to the license agreement. Specifically, they changed it by simply removing it. But look closely. They clearly intended to enforce this against plugin developers, and "a transition period" implies they fully expected to enforce it later.
That's kind of good news, at least they aren't planning on coercing other DAWs into dropping support for VST2. It's not optimal obviously, but it's better than nothing. Still, softsynth developers really need to figure out an alternative to the kind of dumpster fire VST3 is.
stargate wrote: Tue Feb 01, 2022 4:12 am We can, of course, agree to disagree on this point, but IMHO that's not nearly enough. How would that be compelling to plugin developers? If the only way to run CLAP plugins is to run them as a VST3 plugin using a wrapper, then why would a plugin developer waste their time on a CLAP port and a VST3 port instead of using VST3 exclusively? I really doubt anybody would choose to only write plugins that require a CLAP->VST3 wrapper to run, it's a needless abstraction layer at that point.
Because CLAP is simple and VST3 is far from being simple and user friendly. Because it's a nightmare to port stuff from VST2 to VST3 and one could argue that VST3 as a format is suboptimal for developing softsynths to begin with. There is a very good reason why so many plugin developers have shied away from VST3 for so long. It's a question of basic convenience.
Markus Krause wrote: Thu Dec 30, 2021 9:36 am I can confirm this, as I natively worked with VST2, VST3 and JUCE.

On the development of Warlock I wasted one year of development with trying to tame the VST3 SDK (v3.6 as well as v3.7). Warlock is one of the few native VST3 synthesizers that are around here. Warlock itself works, but has limitations and I had to do many tricky hacks to make even the most simple things work. Apart from this Steinberg's AU wrapper still fails compiling on all my machines. That's why there is still no AU version available.
As soon as you support more advanced VST3 features you'll notice that you quickly run into compatibility problems with various DAWS (patch management, hierarchical parameters, etc) or things quickly get extremely complicated (animated custom-displays, singlecomponent, GUI-only parameters). As a result you can only support a very basic set of VST3 features that is even less than what VST2 supports.

Porting VST2.4 SDK projects to the VST3 SDK is a complete nightmare. The SDKs are completely incompatible. There is no downward compatibility at all.

I wasted one year of work just to find out that the VST3 SDK simply doesn't work properly for complex plugins and then move to JUCE. The VST3 SDK is a loveless mess. It's over-engineered, partially broken, heavily obfuscated and fails compiling in many places. It partially works if you create simple effect plugins like 'AGain', but it doesn't work properly for synthesizers.
And FYI, a lot if not most of VST3 plugins already use VST2->VST3 wrappers, so it's just swapping one abstraction layer for another.
mystran wrote: Thu Jan 20, 2022 10:44 pm It's probably also worth emphasizing that in general plugin developers don't develope separate plugins for every API they support. Rather they develop their plugin against one API, whether that's some internal API, some toolkit (eg. Juce, iPlug) specific API, or some actual plugin API. Whatever other formats they support are then typically wrapped around that internal format. So if you're using some plugins that support multiple APIs, there's a very high chance that there's already some sort of wrappers involved.

When such wrappers are built into the plugin itself, it's essentially invisible to the users, but it can make quite a bit of difference to the developers and having a solid, open API can have quite a bit of value (to developers), even if no actual DAW ever supported it directly. If they do, then that's sort of a bonus.
I suggest that you check out the other CLAP threads in the DSP and Plug-in Development and u-he forums, I'm only reiterating what's already been said, you might as well read them for yourself.

Post

stargate wrote: Tue Feb 01, 2022 4:12 am
audiojunkie wrote: Tue Feb 01, 2022 2:36 am I would argue that although it would be nice, and helpful even, CLAP does not even need host support to succeed. All that is needed is a CLAP to VST3 wrapper.
We can, of course, agree to disagree on this point, but IMHO that's not nearly enough. How would that be compelling to plugin developers? If the only way to run CLAP plugins is to run them as a VST3 plugin using a wrapper, then why would a plugin developer waste their time on a CLAP port and a VST3 port instead of using VST3 exclusively? I really doubt anybody would choose to only write plugins that require a CLAP->VST3 wrapper to run, it's a needless abstraction layer at that point.

Steinberg, a single player in a large ecosystem, has been lording over the rest of the ecosystem for a long time using their SDKs and predatory licenses. The only way that changes is if the broader ecosystem decides to band together and share the responsibility of maintaining standards, instead of allowing a single company to control everything. But chances are Steinberg lawyers predicted this moment and added a "Thou shalt not conspire to overthrow Steinberg" clause to their agreements with the major players.
That depends on the goal of CLAP, from my small understanding it is not only a plugin format but also a way to design plug ins that doesn't require the VST SDK and its license, for developers it circumvents the need to code for VST3 strictly using Steinbergs SDK.

As for its success among hosts and the overall public, there is a single company that can make it successful: Ableton , they clearly didn't like VST3, they have the biggest market share.
dedication to flying

Post

Super Piano Hater 64 wrote: Mon Jan 31, 2022 10:33 pm The response from a Steinberg employee (one who, as you can see, is in contact with their lawyers) was as follows:
Yvan wrote:We will change the formulation in order to make it clearer.
This §9.7 does not apply to Host which already supports VST2, in this case your last signed VST2 license agreement is still valid.
For plugins developer we will add a transition period.
Here's the thing though. §9.7 in that formulation does apply to hosts as well. Either any lawyer (if involved) or the employee are simply wrong. It also fuels fire on the situation as plug-in manufacturers feel double crossed - why should they suffer while host developers get a free pass?

Apparently, by dropping §9.7 altogether instead of adding a "transitional period" into it - for now -, Steinberg has realised just how much backlash there would be, and how much trust from the industry they would lose.

Because: The concept indicated in this, no matter how long a transition period is given, has enormous gravity for many people in the industry. Every VST2 host or plug-in developer who signs this (or any future version of it) has to immediately (or within months) wipe any derivative of VST2 off their websites, distribution chain and download archives, including any mention of VST2 as a trademark. This means for many: Rework the code base big time, throw out any VST2, replace it with something else and possibly change the whole debugging and testing workflow from VST2 to something else. And also: Rerelease the entire portfolio, "cleaned". This is, for many, many developers, a bigger change than any recent move by Apple.

Dropping VST2 support now in their DAWs is the complete opposite of restoring that trust. As I wrote elsewhere, their best option to move forward IMHO would have been placing VST2 in the public domain. The other options are rather grim for the industry, no matter of what attempts are made to add a light at the end of the tunnel. Everyone tries their best though.

Post

Once I was a fan of Steinberg. That's the reasons why I am very disappointed by them as a developer:

- Forced obsolescence of VST2
- Legal threats against developers with sneaky clauses like §9.7 (like Urs pointed out above)
- The VST3 SDK is full of bugs, heavily obfuscated, bloated, partially broken and fails compiling in many places. It is not possible to develop complex synthesizers with an efficient workflow. You need to jump trough hoops to do the most simple things.
- As an Indy Developer you have to be frightened that you get sued by one of Steinberg's lawyers, because you missed something or made a mistake. This isn't fun, because a big corporate can completely ruin you on court - no matter if you are right or not

Meanwhile I wasted 18 months to port our stuff to VST3. Time that I don't get paid for and that could have been used to add new features or develop new products. Facts is that those 'new' VST3 versions of our products have no advantages compared to the VST2 versions at all. The opposite is even true. There are some features missing, because VST3 has many stupid limitations. That's why we recommend to use the VST2 version if the DAW supports both.
https://www.tone2.com
Our award-winning synthesizers offer true high-end sound quality.

Post

rod_zero wrote: Tue Feb 01, 2022 8:12 am As for its success among hosts and the overall public, there is a single company that can make it successful: Ableton , they clearly didn't like VST3, they have the biggest market share.
...and native instruments! if those two are on board, it's doomed to be successful. and why would they be not? it's in their own vital interest. i'm actually very optimistic about clap and expect a lot of good news in the next couple of months.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Music Engineer wrote: Tue Feb 01, 2022 10:09 am
rod_zero wrote: Tue Feb 01, 2022 8:12 am As for its success among hosts and the overall public, there is a single company that can make it successful: Ableton , they clearly didn't like VST3, they have the biggest market share.
...and native instruments! if those two are on board, it's doomed to be successful. and why would they be not? it's in their own vital interest. i'm actually very optimistic about clap and expect a lot of good news in the next couple of months.
I would argue, Native Instruments is the company with the biggest impact by far, since the whole NKS ecosystem is built on top of VST2. The deprecation of VST2 means that they now need to work with all their NKS partners to move all of NKS to another platform.

I am sure that this new platform will be VST3, but I am also sure that NI will rework NKS in a way that works with any format from now on.

Post

Might I add that it is not easy for a developer (specially a big name from a business perspective) to come out and say "I don't know how to do this?", Or "Why is this feature in VST3 not working". Because it can be seen as a weakness. As if the dev doesn't know how to do his job (which is not the case here ofcourse). So the fact that some devs are actually talking about this out loud is an indication of a great hidden suffering. And we're probably seeing only the tip of the ice berg. I think hundreds of developers out there are just silent to avoid giving a bad picture/reputation.

I frankly don't think Ableton's or NI's slow adoption of VST3 is intentional. I think it's technical. And if it is, they won't be telling you that, would they? for the same reason. I'm not sure ofcourse, this is just a guess.
www.solostuff.net
The 3rd law of thermo-dynamics states that: the 2nd law has two meanings, one of them is strictly wrong, the other is massively misunderstood.

Post

audiojunkie wrote: Tue Feb 01, 2022 2:38 am
Teksonik wrote: Mon Jan 31, 2022 10:05 pm
stargate wrote: Mon Jan 31, 2022 9:55 pm What they need is a broad coalition of major plugin and host vendors to come together and agree on a standard, governance, and most importantly, all agree to implement it.
The music production software world needs something like the MIDI Manufacturers Association:

"The MIDI Manufacturers Association was officially established as a nonprofit in 1985 with the goal to expand, promote, and protect MIDI technology for the benefit of artists and musicians around the world".

A similar organization would benefit both software developers and end users alike especially if there is going to be a new format.
This was done and failed.
Oh really? I don't remember such an association and I've been around the plugin world since day one. Perhaps you could refresh my memory with some facts about an organization of all the major music software developers coming together to develop standards for the benefit of artists and musicians around the world".
None are so hopelessly enslaved as those who falsely believe they are free. Johann Wolfgang von Goethe

Post

audiojunkie wrote: Tue Feb 01, 2022 2:36 am
I would argue that although it would be nice, and helpful even, CLAP does not even need host support to succeed. All that is needed is a CLAP to VST3 wrapper. The developer can code with CLAP, wrap to VST3, and compile. CLAP would still be a success and make developers’ lives easier without the customer ever knowing the difference in their VST3 binaries.
Except that wrappers normally come with some baggage whether it be decreased efficiency or adding another fail level.

The whole point of a new format is to rid developers of the dependence on Steinberg's proprietary format. Given that SB is going after people just because they have VST in the name of their website it's not a stretch to assume they will take issue with anyone creating such a wrapper in order to circumvent VST3 licensing requirements.
audiojunkie wrote: Tue Feb 01, 2022 2:36 am I fully believe that independent host developers will jump to make their DAWs natively CLAP compatible—there is no drawback other than a couple of days’ work
You know for sure that adding CLAP support will only require "a couple of day's work"?

You've spoken personally with every DAW developer to verify your assertion?

Spending man hours to add a new format only makes sense when that format gains a solid foothold on the market. If only a handful of plugins support the format then it might not be worth the effort.

We simply do not know at this point.
None are so hopelessly enslaved as those who falsely believe they are free. Johann Wolfgang von Goethe

Post

Teksonik wrote: Tue Feb 01, 2022 12:41 pm
audiojunkie wrote: Tue Feb 01, 2022 2:38 amThis was done and failed.
Oh really? I don't remember such an association and I've been around the plugin world since day one. Perhaps you could refresh my memory with some facts about an organization of all the major music software developers coming together to develop standards for the benefit of artists and musicians around the world".
https://en.wikipedia.org/wiki/Generaliz ... _Interface

It was big news in 2003, and kind of died in 2005.

Post

Teksonik wrote: Tue Feb 01, 2022 12:54 pmExcept that wrappers normally come with some baggage whether it be decreased efficiency or adding another fail level.
All plug-ins that support multiple formats are wrapped. Every single one. Either to some kind of internal format, or to one of the common ones. You can call it "abstraction" or you can call it "wrapping", depending on just how well the boundaries are defined. If latter is done properly, it should be no issue to separate the internal format from the wrapped one, which you could then call "adaptation".

Post

Teksonik wrote: Tue Feb 01, 2022 12:41 pm
audiojunkie wrote: Tue Feb 01, 2022 2:38 am
Teksonik wrote: Mon Jan 31, 2022 10:05 pm
stargate wrote: Mon Jan 31, 2022 9:55 pm What they need is a broad coalition of major plugin and host vendors to come together and agree on a standard, governance, and most importantly, all agree to implement it.
The music production software world needs something like the MIDI Manufacturers Association:

"The MIDI Manufacturers Association was officially established as a nonprofit in 1985 with the goal to expand, promote, and protect MIDI technology for the benefit of artists and musicians around the world".

A similar organization would benefit both software developers and end users alike especially if there is going to be a new format.
This was done and failed.
Oh really? I don't remember such an association and I've been around the plugin world since day one. Perhaps you could refresh my memory with some facts about an organization of all the major music software developers coming together to develop standards for the benefit of artists and musicians around the world".
I’m feeling lazy, so I’ll just let you research this:

https://en.m.wikipedia.org/wiki/General ... _Interface

search.php?keywords=Gmpi&terms=all&auth ... mit=Search
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.:mad:
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
:roll:

Post Reply

Return to “Hosts & Applications (Sequencers, DAWs, Audio Editors, etc.)”