Steinberg Discontinuing VST2 Support in its products

[Ah_Dziz]

I don't see the benefits of dropping vst2 support since it already works just fine in pretty much every host (on PC). I do like vst3 much better for my every day use. I use VEP and the multiple midi ports make things far easier to setup than they would be otherwise. I stayed with Cubase 8.5 for years and I'll just not update to any version that stops vst2 support in any major way.

[monomaker]

Steinberg are conspiring to make Cubase 13 the unlucky version!

[Trensharo]

I don't see the benefits of dropping vst2 support since it already works just fine in pretty much every host (on PC). I do like vst3 much better for my every day use. I use VEP and the multiple midi ports make things far easier to setup than they would be otherwise. I stayed with Cubase 8.5 for years and I'll just not update to any version that stops vst2 support in any major way.

Umm... I'm pretty sure Steinberg's own products like HALion 6 support multiple MIDI Ports in the VST3 version. This is hardly a reason to forego an upgrade. Secondly, it's up to developers to implement the features in the VST3 versions, not Steinberg.

VST3 has been on the market for a long time, now. VST2 has been out of development and deprecated for several years. How long do people expect developers to keep maintaining code using an out-of-development SDK in their products? Should they also keep ReWire support for another 12 years, even though it's out of development?

For developers complaining about VST3 being more complicated... well, welcome to the real world. Guess what, ASP was a lot more complicated than Plain HTML, and C++ is a lot more complicated than C, WPF is a lot more complicated than WinForms and XAML MVVM is a lot more complicated than ASP.NET WebForms. Those developers moved on and did what they had to do to create and deliver their products. Not sure why plug-in developers are trying to pull the "woe is me" card out, simply because they'd rather not do the work to move their product over, test and QA them, and deal with user bases who won't want to pay upgrade fees simply for a VST2 -> VST3 upgrade (this probably has a lot to do with it, from a business perspective).

Steinberg isn't mandating anyone upgrades, and I doubt they will be crying over a few hundred people not upgrading as the costs for supporting issues that may arise in those areas, and maintaining that old code, is likely more than the upgrade revenue they'd be generating from those users. Hell, even the Testing/QA probably overruns that on its own. People don't work for free.

Lots of people seem completely ignorant of how software development actually works. They think keeping this stuff in these DAWs is free - but, they [often] then ironically complain about software being "bloated." There are always costs to it. Development, Testing, QA, Tech Support, etc. You see things "working fine," but you ignore what has to be done to get things to that place, and what has to be done to rectify situations where things do not "work fine."

[Guenon]

For developers complaining about VST3 being more complicated... well, welcome to the real world. Guess what, ASP was a lot more complicated than Plain HTML, and C++ is a lot more complicated than C, WPF is a lot more complicated than WinForms and XAML MVVM is a lot more complicated than ASP.NET WebForms. Those developers moved on and did what they had to do to create and deliver their products.

These are quite different things, though. Plain HTML is still used where appropriate, C as well (a lot), and so on . It's not like all C developers "moved on" just because C++ came out; it hasn't been a case of being forced to drop one for the other, and instead a case by case choice of what is needed, suitable and sufficient.

[Super Piano Hater 64]

Not sure why plug-in developers are trying to pull the "woe is me" card out, simply because they'd rather not do the work to move their product over, test and QA them, and deal with user bases who won't want to pay upgrade fees simply for a VST2 -> VST3 upgrade (this probably has a lot to do with it, from a business perspective). (...) People don't work for free.

You almost had it.

Effort aside, VST3 causes problems by being subtly incompatible with other formats. For example, it supports powerful automation-driven control schemes, but other formats are designed around MIDI-driven control schemes that won't work in VST3. Developers of expressive sample libraries, among other things, end up stuck between a rock and a hard place. Should they have two control schemes for different formats? How do they support users who don't know what any of this means or why the two VST formats are different? And that's just the tip of the iceberg.

[Trensharo]

For developers complaining about VST3 being more complicated... well, welcome to the real world. Guess what, ASP was a lot more complicated than Plain HTML, and C++ is a lot more complicated than C, WPF is a lot more complicated than WinForms and XAML MVVM is a lot more complicated than ASP.NET WebForms. Those developers moved on and did what they had to do to create and deliver their products.

These are quite different things, though. Plain HTML is still used where appropriate, C as well (a lot), and so on . It's not like all C developers "moved on" just because C++ came out; it hasn't been a case of being forced to drop one for the other, and instead a case by case choice of what is needed, suitable and sufficient.

Look... That person who takes an example given to illustrate a point and nit picks it to death.

How are you?!

[Trensharo]

Not sure why plug-in developers are trying to pull the "woe is me" card out, simply because they'd rather not do the work to move their product over, test and QA them, and deal with user bases who won't want to pay upgrade fees simply for a VST2 -> VST3 upgrade (this probably has a lot to do with it, from a business perspective). (...) People don't work for free.

You almost had it.

Effort aside, VST3 causes problems by being subtly incompatible with other formats. For example, it supports powerful automation-driven control schemes, but other formats are designed around MIDI-driven control schemes that won't work in VST3. Developers of expressive sample libraries, among other things, end up stuck between a rock and a hard place. Should they have two control schemes for different formats? How do they support users who don't know what any of this means or why the two VST formats are different? And that's just the tip of the iceberg.

They've had a decade to figure this out.

I'm not shedding a tear for them.

You people are acting like they just got the rug pulled up from under them, when in reality they have had 5-10 years of notice that this was eventually going to happen.

This is like game developers complaining that Apple removed OpenGL, making it hard for them to develop a game in 2021, when it has literally been deprecated since 2013/14.

Everything you're citing is just an excuse, in reality. They have had a decade to solve these issues.

[Guenon]

Look... That person who takes an example given to illustrate a point and nit picks it to death.

No nitpicking at all, just mentioning that the examples didn't quite fit (and as the examples were used to then somehow chastise programmers, it seems relevant to mention) - instead, these are examples of different kind of technological development. There is an actual difference, and if comparing with the case of VST2 and VST3, and really wanting to discuss the technological advancement aspects of discontinuing the former, and adopting the latter, it does matter what sort of parallels one draws.

[jancivil]

Oddly, I instantiated Kontakt VST3 in Cubase to see if it didn't like MIDI for control after that account (MIDI vs Host Automation). It was bizarre, it did insane things that I had not given it data at all to do. One CC1 ramp straight up and it performed several key switches ex nihilo, about as far from a straight line if that's the confusion as it can get. This is a library I'm fairly familiar with, and no. I'd never used a VST3 actual instrument up to now. I like that VE Pro VST3 has the up to 48 MIDI ports, that's about all I've had any use for.

[jancivil]

Long story short, I don't instantiate instruments hardly at all in Cubase, but if I did I'd be real worried right about now.

[Super Piano Hater 64]

You people

Nah.

[Markus Krause]

This is like game developers complaining that Apple removed OpenGL, making it hard for them to develop a game in 2021, when it has literally been deprecated since 2013/14.
...

...which is also used by a massive amount of existing VST/AU plugins and is still used Steinberg's latest VST3 SDK. The next drama is incoming

[Ah_Dziz]

I don't see the benefits of dropping vst2 support since it already works just fine in pretty much every host (on PC). I do like vst3 much better for my every day use. I use VEP and the multiple midi ports make things far easier to setup than they would be otherwise. I stayed with Cubase 8.5 for years and I'll just not update to any version that stops vst2 support in any major way.

Umm... I'm pretty sure Steinberg's own products like HALion 6 support multiple MIDI Ports in the VST3 version. This is hardly a reason to forego an upgrade. Secondly, it's up to developers to implement the features in the VST3 versions, not Steinberg.

VST3 has been on the market for a long time, now. VST2 has been out of development and deprecated for several years. How long do people expect developers to keep maintaining code using an out-of-development SDK in their products? Should they also keep ReWire support for another 12 years, even though it's out of development?

For developers complaining about VST3 being more complicated... well, welcome to the real world. Guess what, ASP was a lot more complicated than Plain HTML, and C++ is a lot more complicated than C, WPF is a lot more complicated than WinForms and XAML MVVM is a lot more complicated than ASP.NET WebForms. Those developers moved on and did what they had to do to create and deliver their products. Not sure why plug-in developers are trying to pull the "woe is me" card out, simply because they'd rather not do the work to move their product over, test and QA them, and deal with user bases who won't want to pay upgrade fees simply for a VST2 -> VST3 upgrade (this probably has a lot to do with it, from a business perspective).

Steinberg isn't mandating anyone upgrades, and I doubt they will be crying over a few hundred people not upgrading as the costs for supporting issues that may arise in those areas, and maintaining that old code, is likely more than the upgrade revenue they'd be generating from those users. Hell, even the Testing/QA probably overruns that on its own. People don't work for free.

Lots of people seem completely ignorant of how software development actually works. They think keeping this stuff in these DAWs is free - but, they [often] then ironically complain about software being "bloated." There are always costs to it. Development, Testing, QA, Tech Support, etc. You see things "working fine," but you ignore what has to be done to get things to that place, and what has to be done to rectify situations where things do not "work fine."

Things "working fine" are why I use older versions of software while still paying to keep all my licenses up to date. There are many plugins I use routinely which will never ever ever have a vst3 version and I would like to keep using them. I just won't be using a version of a host with no vst2 support at any point in the near future. Steinberg still gets some upgrade money from me every couple years.

If someone could (and I have no idea what it would take) make a vst2 to vst3 wrapper that worked as well as jbridge then I'd feel fine about having a vst3 only host. I was just mentioning that vst2 works like a champ in pretty much every host (on PC) as of now so if it's a big deal to you, you can just continue to use an older version of your host.

I've never particularly been bothered by or had anything to say about "bloated software" buddy so I don't know where that came from.

[SparkySpark]

For developers complaining about VST3 being more complicated... well, welcome to the real world. Guess what, ASP was a lot more complicated than Plain HTML, and C++ is a lot more complicated than C, WPF is a lot more complicated than WinForms and XAML MVVM is a lot more complicated than ASP.NET WebForms. Those developers moved on and did what they had to do to create and deliver their products.

These are quite different things, though. Plain HTML is still used where appropriate, C as well (a lot), and so on . It's not like all C developers "moved on" just because C++ came out; it hasn't been a case of being forced to drop one for the other, and instead a case by case choice of what is needed, suitable and sufficient.

Actually, I think this is a valid example (and not nitpick by Guenon). MS is notoriously known for coming up with standards and languages, and then dropping them. Myself having been a Microsoft dev, I was pretty fed up with this. Also, several of these newer MS languages did nothing much of importance more than mess up existing structures for no apparent reason (i'd much prefer if they'd just fixed the shortcomings of old languages). I cannot tell if the same goes for VST 3, but I for one am not overly excited about it, and would have preferred devs of VSTis and DAWs to be able to focus on their relevant code rather than on updated APIs.

In any case, here, we have a very solid standard (VST2), which, for many VSTis/fx, has never been updated. I understand Steinberg doesn't want to support it forever, but I do think that even though it's been quite some time, pulling the plug is still too early.

Of course, there may be more to it than I know. Just a bit annoyed that I will now need a wrapper or abandon my VST2's, again, for no apparent benefit on my part.

[Super Piano Hater 64]

In any case, here, we have a very solid standard (VST2), which, for many VSTis/fx, has never been updated. I understand Steinberg doesn't want to support it forever, but I do think that even though it's been quite some time, pulling the plug is still too early.

I've said in previous posts that I'm fine with Cubase dropping VST2 support, and I even think they should have done it something like ten years ago. No idea why they waited so long. Maybe they were specifically waiting for Native Instruments, and they have some kind of leverage now that they didn't before, like an acquisition deal. Or blackmail.

My primary criticism of Steinberg is that they want to have it both ways. They want to change VST however they please and break backwards compatibility with no regard for its place as an industry standard. Simultaneously, they also want it to keep being an industry standard, presumably so they can exert power over the industry. Too bad for them. It doesn't work that way. They're heading for disaster and it's in everyone else's best interest to get as far away from them as possible.

I expect that VST2 is unfortunately a lost cause. Steinberg will continue pushing for total annihilation, and threaten third-party developers with the cancellation of their VST3 licenses if they don't follow its lead in dropping VST2 support. That will include both hosts and plugins, and of course VST2-to-VST3 wrappers. They have already begun making legal threats against open source projects compatible with VST2 (even if they don't use any of Steinberg's code) and they've successfully taken down a bunch of VST news and hosting websites. They have the resources and the legal authority to run very far with this scorched earth campaign. I think the next few years will be chaos.