Steinberg Discontinuing VST2 Support in its products

[whyterabbyt]

The solution, which works elsewhere, is genuinely open protocols. Most of those protocols do originate from a single company, but they share, properly. For example, in the 3D software industry, Alembic, USD and, most recently, MaterialX...

Isn't that what CLAP is supposed to be? It's backed by U-He, Bitwig etc., but it's open source.

Yup, exactly.

[S0lo]

....
Very far from the "sign in" and "hold you by the neck" license from Steinberg: https://developer.steinberg.help/pages/ ... eement.pdf

....

I have seen people 'hint' that there is a cost involved for licensing use of vst3.

It is, as I understood it from before:

§ 4 FEES AND ROYALTIES
This license is non-royalty bearing and the Licensee shall not obligate to pay to Steinberg any fees or
royalties with respect to the VST 3 Plug-In Interface technology or use of the trademarks as set out in §3

Definitely no cost. Sure wasn't implying that.

I also am curious to those developers who find the Licensing Agreement with Steinberg onerous, if they would be willing to use a similar EULA like the MIT one for the plugins they sell to us users.

MIT is not viral (unlike GPL). Meaning that developers don't have to release their code as open source under the MIT license, even if they use MIT licensed code. What they have to do is just include the MIT license with the product and indicate that it refers to the original code they used. Thats as far as I know. I'm not a lawyer obviously.

[pdxindy]

So those doing VST2 and VST3 and then adopting CLAP, will they be releasing just VST3 and CLAP or just CLAP ?

I would assume CLAP and VST3...

[zvenx]

....
Very far from the "sign in" and "hold you by the neck" license from Steinberg: https://developer.steinberg.help/pages/ ... eement.pdf

....

I have seen people 'hint' that there is a cost involved for licensing use of vst3.

It is, as I understood it from before:

§ 4 FEES AND ROYALTIES
This license is non-royalty bearing and the Licensee shall not obligate to pay to Steinberg any fees or
royalties with respect to the VST 3 Plug-In Interface technology or use of the trademarks as set out in §3

Definitely no cost. Sure wasn't implying that.

I also am curious to those developers who find the Licensing Agreement with Steinberg onerous, if they would be willing to use a similar EULA like the MIT one for the plugins they sell to us users.

MIT is not viral (unlike GPL). Meaning that developers don't have to release their code as open source under the MIT license, even if they use MIT licensed code. What they have to do is just include the MIT license with the product and indicate that it refers to the original code they used. Thats as far as I know. I'm not a lawyer obviously.

Oh I wasn't at all implying you hinted that there was a cost, but I have seen others do so over the last few months here.


What I meant re:licensing.. is when you buy a plugin and use it you are subject to the developers EULA's.... which indeed are not as simple and innocuous as the MIT one paragraph one. My point is I am curious to know how many of those developers whilst on one hand object to the implications of the licensing agreement with vst3 vs a simpler one the MIT one, whilst on the other hand give us, the end users, EULAs much more complicated EULA's than the MIT one.


That is they are ok with more complicated Licensing Agreements when it suits them, when they aren't the ones binded by them.

rsp

[AsPeeXXXVIII]

Can't say I'm surprised.

Don't exactly agree with the decision, though.

[S0lo]

That is they are ok with more complicated Licensing Agreements when it suits them, when they aren't the ones binded by them.

Fair point.

Edit: Though I have to say that I have never seen a case in any other industry where hundreds of developers are required to literally "Sign" an agreement to use a format, API or SDK.

[zvenx]

Can't say I'm surprised.

Don't exactly agree with the decision, though.

This is my position more or less.
I knew it was coming, surprised it came this soon, but definitely don't agree with the position.
rsp

[Super Piano Hater 64]

Depends on the format. If you modify a VST2 plugin to support CLAP, you can get it working in a day or two. If you instead want to modify it to support VST3, it could take you over a year.

Based on?

The experiences of developers who already adopted VST3.

For example, I’ll link the same old u-he thread someone else did:

viewtopic.php?p=5584975

You can see from the dates of the posts that they introduced VST3 support in (roughly) early 2013, partially withdrew support for it about a year later, and spent almost two years rewriting and fixing things before they were comfortable bringing it back. I’ve seen other developers mention having similar amounts of trouble.

EDIT: To clarify, you might write the code in much less time, but programming is not just about writing code. It’s about making it work correctly, without crashing, and fast enough for the user’s needs. Debugging VST3 support is clearly a nightmare.

[zvenx]

Yes and there are many who have had little or no difficulty with vst3 development. I know because I beta test for some of them and I can see how long it takes for an update to be up, and conversations with them.

I think that the main issue is there are some developers who have set up frameworks that are deeply set up and tied in with the vst2 protocols, and vst3 requires lots of changes to their framework which they are reluctant to do for one reason or other. So some just patch their framework to include vst3 and end up with difficulties as opposed to redoing their framework to vst3 protocols.... well this is my theory anyway, which is why some have little or no difficulties and some have lots.


u-he for instance still has issues with their vst3 framework..
for instance:
"* VST3 host bypass button non-functional in some hosts"
from viewtopic.php?p=8295706#p8295706 where as they are lots of developers who do not have these issues..

Why?

rsp

[zvenx]

....Debugging VST3 support is clearly a nightmare.

For some, but not all.

I have given this example twice now on kvr.

A developer I test for needed to get Audio in to his vst3 instrument for use in Cubendo. I alerted him that since I think Cubase 8, sidechaining in the vst3 spec on instruments works great on Cubase..
He returned two days later.. yes you read right, two days later with it fully implemented and working without issues.. two days later, he is a one man shop developer.

Why?
rsp

[Compyfox]

Ow wow... thank you Steinberg for continuing to mess up VST3, then forcing users on to it "within the next 24 months" (make that 6-9 months in reality).

I really hope somebody will create a VST2-to-VST3 wrapper, and soon (or I really hope Urs' "CLAP" concept will work out - but I don't think Steinberg will adhere). There are so many tools that never never went to VST3. Wrappers are getting rare as well. Now pushing this off on the "Apple M1 and Rosetta 2" commentary is just utterly ridiculous IMHO.


Wasn't VST3 supposed to be backwards compatible? Doesn't the SDK render the same code in both versions? I mean, you can change the filename from .vst3 to .dll and the other way around in places, and it just works.


What was VST3 really of an improvement - like, honestly?

Multi-Channel and Surround setups was/is possible with VST2, only Steinberg refused to make it possible in their hosts and rather "moved on" and stated "only VST3 can do that". Side-Chaining? Possible but not in Steinberg DAWs, again with the comment "only VST3 can do that" (because their routing matrix was always bad!). VST3 really only brings two major things IMHO: micro-tuning (MPE) and "stop processing if not audio is present". You can't even put these plugins in custom folders on installation (if it's not within Common Files, you're out of luck).



Cubase 12 is on front doors, will this be the first to fully drop VST2? I hope not (according to the official statement, "within the next 24 months", but this means nothing as Steinberg is known to just "drop things" overnight). I ain't taking my chances here.

Great announcement, absolute slow clap there, Steinberg.

True, the paintings have been on the wall for years at this point (IIRC, it was already planned for Cubase 8, then moved to Cubase 10). However, in the last 10 years since the constant back and forth on VST3 and people still sticking their guns to VST2, because reasons, they did not manage to reach out to devs properly, or fixed proposed things and finally said "okay, let's go VST4, with your input". I mean... we're on VST3.7... and developers still release VST2 versions. Ever thought about that?!

In all these years of being forced to use VST3 - App hangs, strange longer loading times, keyboard stealing, random crashes, UI problems, VST3 bypass not working (see mentions above), Wavelab's infamous "copy instance and settings 1:1 then render" bug. Heck, no Steinberg host interprets VST plugins 1:1... each DAW needs their own hacks and workarounds -- which adds unnecessary extra development time. And they're the damn creators of this SDK! "If it's not working, it's the third party's developer fault" - the times I've heard/read this sentence.


So many outstanding tools will be lost forever in this forced purge. Project Recall will be a fun (not!).
And not every developer can, not to mention will catch up within weeks.


What a frigging mess, in the middle of the "we drop the Elicenser" (after the activation servers have been overloaded/nuked several times) and Dorico 4 installation mess. Sure, let's add another well received announcement.

Time to grab some popcorn, and keep an eye on what both Markus Krause (Tone2) and Urs Heckmann (U-HE) will do from this point forward. Not to mention Bitwig GmbH, iZotope and Native Instruments. Maybe the VST Technology will finally change... for the better. And I really hope the just mentioned companies are on the front lines.



What a start into 2022...

[zvenx]

Cubendo 12 on Intel and other non Apple Silicon Native platforms has vst2 that works fine.

Woudln't be the same to have an SB thread without you coming to complain.
rsp

[Super Piano Hater 64]

....Debugging VST3 support is clearly a nightmare.

For some, but not all.

Why?
rsp

It’s easier (not trivial) if you use some kind of compatibility layer where a lot of the debugging has been done already. Loads of plugins rely on JUCE for this.

Furthermore, it has gotten somewhat easier to keep track of the differences in VST3 spec behavior across different hosts, just by virtue of the fact that they added support years ago and there are fewer surprises these days.

[MirkoVanHauten]

What was VST3 really of an improvement - like, honestly?

Agree, there is lots of in it that's already possible or not even supported by Steinberg hosts itself. The one actual feature I remember is that parameters are identified by ID and not by index (I think something like that) which makes adding or removing parameters without messing up automation possible.

[zvenx]

.............
It’s easier (not trivial) if you use some kind of compatibility layer where a lot of the debugging has been done already. Loads of plugins rely on JUCE for this.

Furthermore, it has gotten somewhat easier to keep track of the differences in VST3 spec behavior across different hosts, just by virtue of the fact that they added support years ago and there are fewer surprises these days.

So how does say Waves and Steinberg not have issues developing for vst3? I think they both use their own framework.

rsp