Steinberg Discontinuing VST2 Support in its products

[Markus Krause]

Isn’t adding a new format technically more work?

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.

I can confirm that porting VST2 plugins to VST3 is a nightmare. VST3 isn't downward compatible at all. It's a completely different plugin format with serious design-failures.

[vurt]

Isn’t adding a new format technically more work?

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.

I can confirm that porting VST2 plugins to VST3 is a nightmare. VST3 isn't downward compatible at all. It's a completely different plugin format with serious design-failures.

are you going to support clap? or is there another option?

[Compyfox]

Steinberg advertises that their VST3 format has 'many essential new features' and 'advantages' compared to competing plugin-formats.
In practise, we do not think that this is true for synthesizers, since VST3 does not offer proper MIDI support.

Oh, ain't the advertising great, no?

It will only get worse once everyone starts adapting MIDI 2.0.

I can confirm that porting VST2 plugins to VST3 is a nightmare. VST3 isn't downward compatible at all. It's a completely different plugin format with serious design-failures.

That's why we recommend to use the VST2 version if your DAW supports both formats.

The Steinberg Discourse Forum already hinted at "this might be be game over with Cubase 12.5"...

If Steinberg sticks to their known release cycles, however Cubase 12 got shifted (due to the Elicenser drama) -- then chances are 12.0 drops in a couple of weeks, and 12.5 probably already way too soon in November 2022 (probably paid again... a v.5 and free, like Nuendo? Or the competition with Studio One? Unheard of!)...

In June 2022 we'll know if Apple drops Rosetta 2 with MacOS 13, or if we're safe for another year. As this seems to be the main reason for the final drop (the valid backlash won't help this time, I'm afraid).

So the code phrase here is indeed "if your DAW supports both formats".

[Super Piano Hater 64]

In June 2022 we'll know if Apple drops Rosetta 2 with MacOS 13, or if we're safe for another year.

Not necessarily. Existing Mac OS update installers already include assets and code to display messages about this. They could spring it on us at any time. The phrasing of the messages implies that it may happen at different times in different countries. It's not clear what the licensing situation is with the third-party tech that Apple uses in Rosetta.

[pdxindy]

In June 2022 we'll know if Apple drops Rosetta 2 with MacOS 13, or if we're safe for another year. As this seems to be the main reason for the final drop (the valid backlash won't help this time, I'm afraid).

There is zero chance Apple will drop Rosetta that soon.

[Super Piano Hater 64]

I can confirm that porting VST2 plugins to VST3 is a nightmare. VST3 isn't downward compatible at all. It's a completely different plugin format with serious design-failures.

Would you mind sharing more details? I seem to recall you just recently added VST3 support. Some of the discussion we've linked to here is from fairly old posts (before Steinberg added some essential features to the SDK). Your experience with specific difficulties might be more relevant to the current state of the VST3 ecosystem.

[Freaqpeak]

Are there any plugins devs that still refuses to do VST3 even on new plugins?
One is Admiral Quality but they havent been active for several years. Are there anyone else?

Can any dev here make a list of things that is broken, missing or just bad by design in VST3? ("Objectively" within the dev community). Did you talk to Steinberg?
Is Steinberg acknowledging the issues?

Thing is, the chance/risk that more hosts will go down this road within two years, are pretty high I guess...

I hope CLAP will disrupt the dependancy of Steinberg.....

[Super Piano Hater 64]

Can any dev here make a list of things that is broken, missing or just bad by design in VST3? ("Objectively" within the dev community). Did you talk to Steinberg?
Is Steinberg acknowledging the issues?

I asked Markus (Tone2) for more details above. In the meantime, here's a list from a 2020 post by a different developer:

Just want to follow up for anyone in the future looking for this information. Have spent a lot of time the past few days on this. Here's my understanding of the current situation in 2020.

1. VST3 does not pass CC midi events into VST3 plugins, as midi events. DAW's are supposed to translate all midi messages into VST SDK objects which are provided to plugins, but not as a serial midi queue full of midi events, as has been the case with VST2.
2. CC events in particular show up to VST3 plugins as parameters in a queue. It is a separate queue from NoteOn/NoteOff, so serialized ordering of mixed type midi can not be garaunteed inside VST3 plugins other then through timestamp.
3. CC events previously could not be output from VST3 plugins, but last year Steinberg added a legacy function to do that. However many DAW's do not yet make use of this added VST3 feature, so trying to output CC midi messages from a VST3 plugin will be unreliable for the time being. Also it is not clear whether timing information is included in that legacy out function. And they are on a seperate queue from notes, as per the above, so synchronization between notes and CC's cannot be absolutely guaranteed at a fine level.
4. Steinberg says that articulation management and keyswitching should be handled via the VST3 NoteExpression paradigm. VST3 also includes support for exposing keyswitching information to the host. These API's should be used for managing key switches, not simple processing of midi events in serial order as has been possible with VST2
5. Most DAW's do not yet fully support VST3 SDK, including NoteExpressions, Keyswitching, legacyCC out, etc. Until they do, its not really feasible for a VST3 plugin developer to utilize the complete VST3 sdk without running into problems with many hosts. Paradoxically, using the actual VST3 sdk fully is the only way to ensure complete and accurate synchronization of mixed midi event types processed through a VST3 plugin.
6. Steinberg does not support using VST3 sdk for midi plugins, they say its an audio SDk that happens to have some midi capability that is being exploited by some developers. They take no responsibility for ensuring that VST3 can be used for midi plugins, as of 2020.
7. JUCE also does not fully support VST3 sdk, per some of the reasons mentioned above. They have some hack arounds to get midi in and out, but since not all DAW's are looking for the legacy CC out, VST3 plugins produced with JUCE will also not work with all daws, in terms of midi thru. JUCE currently also does not provide a way to have VST3 plugin with multiple event input buses.
8. VST2 still works, but with the license change, its not possible for everyone to develop with it. So until all DAW's and plugins conform more fully to VST3 approach, we will be stuck in the middle. New developers will have to live with limitations of VST3 broken midi.
9. Some DAW's such as StudioOne, for example, keep CC's separate from notes internally, making it basically impossible to use a VST2 plugin that generates CC's in any way and have it feed to a VST3 instrument plugin. StudioOne is more compliant with VST3, but breaks the use of mixing VST2 midi plugins with VST3 instruments.
10. Until further notice, the main thing I see is that VST3 cannot be trusted for outputting CC's and it cannot be trusted for ensuring serial ordering with mixed event types. So that means, don't develop midi-only plugins with it, and don't ever use CC's for articulation keyswitching.

If you follow the rest of that thread, you'll see posts by the lead VST3 SDK developer dismissing these complaints. Other recent posts suggest that he continues to maintain his anti-MIDI stance.

[pdxindy]

Thing is, the chance/risk that more hosts will go down this road within two years, are pretty high I guess...

Steinberg is going to force them to.

[Compyfox]

There is zero chance Apple will drop Rosetta that soon.

Yeah, the same was said with the switch from PPC-to-Intel, and 2 OS versions later (as in... .1 versions, these days .1, .2, .3 are patches with Apple), Rosetta was gone.

macOS 11 was "the hybrid", macOS 12 is "full M1", I fear for macOS13...

Though we might be save just a slight bit longer, as chip shortages are still a thing. And this also affects Apple. But a "goodbye!" can happen anytime, unannounced.

See Super Piano's post

Not necessarily. Existing Mac OS update installers already include assets and code to display messages about this. They could spring it on us at any time. The phrasing of the messages implies that it may happen at different times in different countries. It's not clear what the licensing situation is with the third-party tech that Apple uses in Rosetta.

Steinberg is playing a huge f'n gamble, at the behest of the Windows users.
And this is definitely not okay.

I asked Markus (Tone2) for more details above. In the meantime, here's a list from a 2020 post by a different developer:

Just want to follow up for anyone in the future looking for this information. Have spent a lot of time the past few days on this. Here's my understanding of the current situation in 2020.

• VST3 does not pass CC midi events into VST3 plugins, as midi events. DAW's are supposed to translate all midi messages into VST SDK objects which are provided to plugins, but not as a serial midi queue full of midi events, as has been the case with VST2.
• ...
• Steinberg does not support using VST3 sdk for midi plugins, they say its an audio SDk that happens to have some midi capability that is being exploited by some developers. They take no responsibility for ensuring that VST3 can be used for midi plugins, as of 2020.
• JUCE also does not fully support VST3 sdk, per some of the reasons mentioned above. They have some hack arounds to get midi in and out, but since not all DAW's are looking for the legacy CC out, VST3 plugins produced with JUCE will also not work with all daws, in terms of midi thru. JUCE currently also does not provide a way to have VST3 plugin with multiple event input buses.
• ...
• Some DAW's such as StudioOne, for example, keep CC's separate from notes internally, making it basically impossible to use a VST2 plugin that generates CC's in any way and have it feed to a VST3 instrument plugin. StudioOne is more compliant with VST3, but breaks the use of mixing VST2 midi plugins with VST3 instruments.
• ...

If you follow the rest of that thread, you'll see posts by the lead VST3 SDK developer dismissing these complaints. Other recent posts suggest that he continues to maintain his anti-MIDI stance.

Yup, and that is just the tip of the iceberg.

VST3 was supposed to be "a workaround", because of Steinberg not wanting to/or being able to fix their own spaghetti code (CubEndo never felt fully rewritten like Wavelab 7 was). Their stance was always "3rd Party devs need to adhere to the specs -- if it's not working, it's their fault, not ours", but as can be seen above, the specs are broken beyond belief.

Not only that, Presonus Studio One... was programmed by former Steinberg developers. They stuck to the SDK like a fly to... you get the analogy. And in my years of software testing, the cursing and swearing I heard about VST3 alone, or the bugs I ran into which were never showing in up VST2... sheesh.



As mentioned previously...

VST3 is also broken if we talk "Bypass" - I ran into plugins that completely nuked CubEndo (as in: soft-lock, no more editing possible, only "terminate task"), because the bypass function didn't properly work. Thankfully, the dev in question back then could fix this within a couple of days.

VST3 also needs special hacks if you want to use it in Wavelab because while rendering it loads another instance of the the used plugin, and tries to copy the preset. If it fails, you have two results: 1) no processing, 2) silence (this is a well known SDK UI recall bug). VST3 also can result in 1 additional s of silence while rendering. Something that does not happen for as often for VST2, if at all.




Now Steinberg wants to enforce VST3, and everyone must to adhere? A SDK that was never really made for "Instruments", but mainly audio processing plugins. In order for "instruments" to maybe-somewhat-properly work, the host needs to change, to work around the VST3 shortcomings.

Yeah... this will swing well with developers all around the globe.

[jamcat]

I take it then you don't currently own any u-he plugins or if you do, you intend to sell them.

Sure don’t. But that has nothing to do with any future clap format, should it ever go anywhere.

I never said anything about selling registered plugins I already own. That’s not something I have ever done and it’s not something I will likely ever do. It seems unethical to sell your problems to someone else.

And it is definitely unethical to sell an IP usage license granted exclusively to you by a third party to someone else.

[Markus Krause]

Isn’t adding a new format technically more work?

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.

I can confirm that porting VST2 plugins to VST3 is a nightmare. VST3 isn't downward compatible at all. It's a completely different plugin format with serious design-failures.

are you going to support clap? or is there another option?

- Support for 'clap' is planned for the future
- VST3 support on PC had been added recently (although VST3 offers no significant advantages for synths at all. The opposite is even true!)
- VST3 might not be supported on the Mac, since we already got AU
- VST2 will be supported also in the future - we recommend to use VST2 if your DAW supports it

[vurt]

Isn’t adding a new format technically more work?

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.

I can confirm that porting VST2 plugins to VST3 is a nightmare. VST3 isn't downward compatible at all. It's a completely different plugin format with serious design-failures.

are you going to support clap? or is there another option?

Support for 'clap' is planned for the future

the more of the "top name" devs that they can get onboard, the better it will be for all

[Markus Krause]

Thing is, the chance/risk that more hosts will go down this road within two years, are pretty high I guess...

Steinberg is going to force them to.

No they can't if the devs got a valid VST2 license

[Super Piano Hater 64]

Steinberg is going to force them to.

No they can't if the devs got a valid VST2 license

They can revoke the license as part of an updated VST3 agreement, and put all kinds of pressure on VST3 SDK users to agree to the new terms. They can force you to keep one and lose the other.

They already tried this once. Do you honestly trust them not to try it again?