Steinberg Discontinuing VST2 Support in its products

[whyterabbyt]

Well it was nonsense is what it was.

not as much nonsense as not knowing the difference between a hypothetical example and a belief.

[zvenx]

C'mon now, let's just be real here: it was very almost certainly a business decision not to expose sidechain inputs on VST2 plugins. Every other DAW implemented an easy to use solution so there's no technical reason Steinberg couldn't do the same. Implying such almost insults their developers who I'm sure would've been very capable of implementing that feature over the years.

Users requested it. Someone at Steinberg must have asked, "should we do this?" They certainly would've discussed internally and for whatever reason, made a business decision not to. Most of us, myself included, just assume it was to promote this feature in VST3, but whatever the reason, it was almost certainly a business decision not any kind of technical limitation. Every other major DAW that supports VST2 allows for this. Except King Cubase.

How would you know this with the certainty you seem to have? Because others did it? Afaik it was known as a limitation in vst2 and planned for vst3 long before vst3 was ever released.
Rsp

[Funkybot's Evil Twin]

How would you know this with the certainty you seem to have? Because others did it? Afaik it was known as a limitation in vst2 and planned for vst3 long before vst3 was ever released.
Rsp

Yes, because others did! So it's clearly not a limitation of VST2. Was it a bit of a workaround? Yes! Did every other DAW and every plugin developer basically land on a successful way of implementing it in VST2? Yes! Did that become an unofficial standard? Yep, everyone does it the same way, plugin makers and DAWs! Is Steinberg aware that other DAWs and plugin makers did that? They must be. Did Cubase users request this? Sure did! Myself included! Are people at Steinberg smart enough to have implemented the feature the same if they wanted to? Yes, of course! They're not stupid. It's not a technical limitation. So what does that mean? Steinberg must have chose not to do the same. That was a business decision.

I'm not sure anyone could come to any other conclusion.

[pdxindy]

Anyone can feel free to go to SB's developer forum to see their view point in the matter which they will say much better and much more technical accurate l than I ever could.

Steinberg has leveraged the VST format (2 and 3) to support their DAW and to function as something of an impediment to others.

The reasons they state (point of view) to justify their choices end up as kind of a smokescreen. No doubt the various employees are decent people and sincerely try to communicate the company "point of view".

If that "point of view" had actually served the broader community of developers and users, VST3 would not have been so poorly received and Steinberg would not be now trying to force the issue.

An industry wide standard should not be controlled by a single company. And in this case, Steinberg demonstrates a 'my way or the highway' attitude when they express their 'point of view'. Such a standard as VST should be open and developed by a coalition. There is no question that Steinberg has done a poor job as the steward of the VST format.

[zvenx]

An industry wide standard should not be controlled by a single company.

On this we are one.
Maybe CLAP will be that.
SB's Asio is also a standard for PC. Maybe a competitor for that not owned by one company needs to be developed.

rsp

[whyterabbyt]

How would you know this with the certainty you seem to have? Because others did it? Afaik it was known as a limitation in vst2 and planned for vst3 long before vst3 was ever released.
Rsp

Except it wasnt a limitation in VST2. Steinberg failed to state or apply a limitation to the number of usable input or output channels a plugin could support, or how channels 'should' be used. The way the VST2 API was written, the 'workaround' or 'hack' you alleged was quite literally to use the API exactly as documented.

Did the SDK call out against plugins being written to support multichannel inputs, be that sidechaining or whatever? Nope. Quite the contrary, it actually even made it explicit that processing could be being applied to to multi-channel input sources.

[simmo75]

Anyone can feel free to go to SB's developer forum to see their view point in the matter which they will say much better and much more technical accurate l than I ever could.

Steinberg has leveraged the VST format (2 and 3) to support their DAW and to function as something of an impediment to others.

The reasons they state (point of view) to justify their choices end up as kind of a smokescreen. No doubt the various employees are decent people and sincerely try to communicate the company "point of view".

If that "point of view" had actually served the broader community of developers and users, VST3 would not have been so poorly received and Steinberg would not be now trying to force the issue.

An industry wide standard should not be controlled by a single company. And in this case, Steinberg demonstrates a 'my way or the highway' attitude when they express their 'point of view'. Such a standard as VST should be open and developed by a coalition. There is no question that Steinberg has done a poor job as the steward of the VST format.

Totally agree with you, but they created the VST format, so they can do what they like with it.
VST3 is supposed to be an improved format, not just on their DAW but the competition too, and seems to be generally accepted as such.
Ableton Live seems to be an exception to this and it's VST3 performance is terrible.
Personally, given the choice, I use VST3.

[whyterabbyt]

How would you know this with the certainty you seem to have? Because others did it? Afaik it was known as a limitation in vst2 and planned for vst3 long before vst3 was ever released.
Rsp

Yes, because others did! So it's clearly not a limitation of VST2. Was it a bit of a workaround? Yes!

Its not even a workaround, it uses the API exactly as written and described. You declate that the plugin has more than two inputs, and/or more than two outputs, you pull in the buffers from as many input channels as there are, and then you process that and send it to the buffers for as many output channels as there are.

Basically, everyone on the planet grokked that that meant sidechaining came free, but when Steinberg thought up features for VST3, they had to pretend that they hadnt already built an API that could deliver those features. And some people seem to have swallowed that NewSpeak wholesale.

[pdxindy]

VST3 is supposed to be an improved format, not just on their DAW but the competition too, and seems to be generally accepted as such.

There are a variety of developers that have explained why they do not consider VST3 an improved format.

[simmo75]

VST3 is supposed to be an improved format, not just on their DAW but the competition too, and seems to be generally accepted as such.

There are a variety of developers that have explained why they do not consider VST3 an improved format.

No doubt, I’m sure there’s a lot of devs that see it is more work too.
It seems totally unnecessary to me but being a Nuendo user, VST3 is essential for me. So devs that don’t make VST3 versions will lose out on the Steinberg user sales.

[Dewdman42]

I wouldn't worry about that @simmo75. There will be vst3-wrapped plugins for everything you probably use. A great deal of VST3 plugins floating around right now are already just wrapped as it is. Its nothing new.

[Dewdman42]

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.

Not necessarily. First it should be pointed out that one of the development paths with CLAP is that devs can develop using the CLAP sdk...and by using wrappers they can distribute VST, VST3, AU and AAX plugins. It is yet to be seen if these wrappers can be done in in a binary runtime fashion such that licensing will not continue to be an issue. But a lot of developers already use their own internal plugin frameworks, or they use things like JUCE or iPlug, which essentially use wrappers to produce plugins of various formats in distribution..this is nothing new..

One of the main ideas about CLAP is simply to find a way around the licensing headaches caused by Steinberg.

But...as hosts do add native CLAP support, and that is the question...will they...then wrappers won't be needed. Why would they? Well CLAP is bringing a few new features which may be interesting to a lot of people, like much better multi-thread handling and a few other things. Its yet to be seen whether those features are compelling enough that neutral DAW developers such as Ableton, MOTU, PreSonus and others may simply add CLAP as an additional support format, and it may not be that difficult to do so. I suspect that Apple, Steinberg and Avid will wait until hell freezes over though.

[Teksonik]

If there are glaring omissions or faults in the VST3 format that other developers can spot then why Steinberg can not remains a mystery.

Of course Steinberg can... they make what suits their business. They have no reason to be helpful to other developers who are competitors of theirs.

But then you're saying Steinberg has no reason to be helpful to users of their proprietary format including their own paying customers.

If the evidence presented here is correct and VST3 is inferior to VST2 and other developers can spot that fact then Steinberg should be able to do so as well.

If SB drops VST2 support for their DAWs and other developers stop releasing VST3 plugins how many people will continue to buy SB DAWs if all they can use is the included content or they are left out of using a number great third party plugins?

How would that suit their business in any way?

It just seems like SB is saying "it's my ball and we'll play the game my way" which they have the right to do but then the result is other people working to create an open source alternative that may in time if executed properly render VST3 obsolete.

[Dewdman42]

How would that (CLAP) be compelling to plugin developers?

At least three reasons off the top of my head

1. Avoid signing a Steinberg license
2. Much easier SDK to develop to
3. A few new features such as better multi-threading, etc.

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.

what you may or may not realize is that many developers already use a different abstraction in order to build for VST, VST3, AU and AAX distributions. JUCE and iPlug are two examples, some developers develop their own in-house abstractions. CLAP is just the possibility to create something like that as an open sourced MIT License technology, which can also run natively if desired. And a lot of attention is being made in this effort to get us all out of the Steinberg-license-ditch while we're at it..possibly even including when wrappers are used for distributing VST, VST3, AU and AAX plugins..but we shall see how that goes.

CLAP is not intended to "take down" Steinberg. Though in the long run it may have the effect of humbling down Steinberg to adapt a bit more then they planned. But again, we shall see how that goes.

[Teksonik]

First it should be pointed out that one of the development paths with CLAP is that devs can develop using the CLAP sdk...and by using wrappers they can distribute VST, VST3.....One of the main ideas about CLAP is simply to find a way around the licensing headaches caused by Steinberg.

Given that SB went after someone just because they used "VST" in the name of their website do you not feel that they are going to have an issue with people circumventing their VST3 licensing ?

Speaking strictly as an end user I'm not likely to buy a CLAP plugin wrapped in a VST3 wrapper.

What's the benefit to the end user? Just another fail layer or more overhead?

Anyway it's far too early in the game to say what impact if any CLAP will have on the market.

I wish everyone involved good luck....let's see what the future holds.

JUCE and iPlug are two examples, some developers develop their own in-house abstractions

The difference being those are development tools not plugin formats. No matter how you create the plugin, as it stands right now you're limited to VST (and of course AAX Au LV2 etc but the subject here is VST2/3).