Nope. They work on the platform and environment they were written for. And if the rest of the world moves on, you either move with it or you stay behind. No one is forcing you to upgrade your system (not to mention this is still 2 years down the line)… With this attitude, should I be screaming at Apple because they killed the Apple IIe and I can no longer play the boxes of Ultima and King’s Quest games I have on a shelf? I dont see anything in any EULA that says this software is guaranteed to run for my entire existence.
essentially I agree - although the analogy isn’t quite the same. We are not talking about plugins or software from the 90s - we are talking about current plugins that you can buy today.
And of course nobody is forcing me to upgrade anything - Steinberg can do what they want, Apple certainly do !
BUT - that doesn’t mean it’s right or a sensible thing to do ? And for some of us it’s going to be particularly annoying. New users probably won’t care but some of us have a massive financial and workflow investment in VST2 plugins…and I feel there should be a very good reason for doing this.
but as you say - it’s up to them
1 Like
Yeap, you should.
The point I was making is that there is no wear and tear. It’s just programming.
The “we all move along with the times” thing is fabricated.
This train of thought is in place to get more money out people, buying (or RE-buyng) things that should not become obsolete…just because (insert excuse).
I use the Unify VST3 plugin sometimes - that can host VST2 plugins even in Logic. I’m assuming it won’t work if you try to host VST2 instruments in Unify under Apple Silicon, but I would hope that it would continue to host VST2 plugins on Windows or under Rosetta 2 on Mac.
Obviously this would not give backwards compatibility, but it would allow old projects to be converted into a form that works, and existing automation can be applied to the hosted plugins using copy and paste. But that would need to be done while a Cubase version that supports VST2 can still be run. New projects would not be a problem.
It’s still a pain - I have many completed projects most of which use VST2. Most of them will never need to be changed, it’s true, but once the last Cubase version that supports VST2 can no longer run on MacOS, it looks like it will be impossible to convert them without a separate computer running the old OS.
I do export audio mixdowns of every channel in each project for archiving purposes, so that will be some help, I guess.
If the rest of the world moves on and takes my briefs with them, I am forced to move with it so that I can cover my ass. But if they leave my briefs with me, I have the option to stay behind. 
It’s a false dichotomy in my opinion, and a needless dilemma. Why should I choose between complementary tools? I need my plug-ins for the sounds, I need the DAW as the workbench upon which the sounds will be worked on.
I get it that an updated standard brings benefits, and it’s good to update stuff, keep them alive, work on them. But to “dethrone” the old standard, the new one must have many benefits and very few drawbacks. I don’t see why we’re not discussing how XLR connections are outdated, for example. They do their job. They’re standard. We love them. In the same way, I don’t see why VST standards must go forward destructively, by completely excluding and discommunicating older versions of the specification. Unsupported? YES! Use at own risk? Of course, thank you very much, you won’t hear from me. Not able to use at all? No, you break my heart.
I just hope bridges will work reliably and it won’t be a big problem in the end. Throwing away perfectly fine tools just because they’re not current… I wonder what someone owning a Stradivari violin have to say about that. 
5 Likes
that’s a function of the Unify plugin so yes it should continue to support VST2 within the plugin itself.
Better protect that dongle at all cost. If it breaks…
1 Like
As a former software engineer, I know that software maintenance does not come for free.
Almost all non-trivial software has external dependencies. This is certainly the case for anything running on a third-party operating system. Most software uses external libraries such as Qt (used for the user interface of Dorico, for example) and JUCE (the middleware used for many audio plug-ins). Whilst operating system and library authors try to hold APIs and especially ABIs constant for as long as possible, eventually change proves necessary, requiring existing software to be updated.
Sometimes more disruptive change is needed in order to overcome architectural deficiencies. This was the case in the VST2 to VST3 transition, which has been underway for many years. There is no denying that it has taken a lot of effort for many teams to produce stable VST3 versions of their products and some important products that are actively maintained are still not there. There comes a point where Steinberg has to say “enough is enough” in what has been a long transition away from VST2. Leaving legacy support in place is not free of charge - you have to maintain that code. The more complex the code is, the harder it is to achieve reliability and assure performance, also the greater possibility there is of latent security issues being discovered. In addition, newer hardware can cause breakage, sometimes by invalidating assumptions about existing architectures, sometimes be being a complete change of architecture (as in Apple’s transitions from Power PC to x64 to ARM).
Microsoft had a policy of not deprecating legacy features and APIs for a long time if ever. It took a long time for 16-bit app support to disappear from Windows, and Internet Explorer was retained for much longer than was ideal because of all the legacy systems that relied on its non-standard behaviour. The same was true in the browser world - Flash wasn’t deprecated until Adobe finally decided to code a drop-dead date into the plugin, whilst Mozilla eventually had to go for disruptive change in dropping older plug-in technologies in order to move to a modern more performant architecture. Both companies eventually realised that a more aggressive deprecation strategy was necessary to eliminate “technical debt”.
You can’t expect to buy a plug-in and use it forever on the latest hardware, host applications and operating systems. It is best practice to render stems in completed projects, in case you cannot run the plug-in(s) in the future.
There is no denying that the upcoming discontinuance of VST2 will be disruptive. I am fortunate - the only VST2 plugins I have are those I acquired for free or at a low cost. It will not be painful for me to lose this minimal investment. Most of my plug-in spending has been on Steinberg and iZotope products, which are all VST3. Others are far from this fortunate, especially as some major players have been slow to adopt VST3.
I expect that Cubase 12 and Nuendo 12 will retain VST2 support - they are too late in the development cycle to be affected by the dropping of VST2 support. If I am correct, this means there will be a Steinberg Licensing version of Cubase and Nuendo that supports VST2 on all current platforms (though you’ll have to use Rosetta on Apple Silicon). Dorico 4 has VST2 support. There may well be a Steinberg Licensing version of WaveLab with VST2 support - either by the relatively recently released WaveLab 11 transitioning to Steinberg Licensing on a future minor release or by WaveLab 12 being released with VST2 support. However, this is as much as I think we can hope for. Steinberg has decided that this is finally the time for VST2 support to go away.
If you need ongoing VST2 support, one option is to keep a VST2 compatible version of the host application on your system, using virtualisation if necessary as operating systems and hardware move on. The other option is to use a VST3 to VST2 bridge.
7 Likes
Wow, all those older projects, gone, i mean it was bad enough with 32bit compatibility but Vst 2, man a crazy move on steinberg account, wouldn’t it make sense to have a super compatible and stable DAW that was rock solid, that could also still load up Older projects, Can they not just keep VST 2 compatibility also and work on ways to improve Cubase , i love Cubase it rocks but what do you tell the clients when you are going to do a remix or something( Sorry i can’t recall your file because it uses VST 2 plugins and instruments ) Come on Steinberg, if you want the real gig then be the company that makes the superior software, instead of ditching support just embrace, enhance and make your product compatible with as much as possible.
3 Likes
^^^^ a good post (IMO) - although I don’t agree with it completely
certainly C12/N12 will have vst2 support and possibly C12.5/N12.5 if they do .5 releases.
Of course we don’t really know about the mid-term plans for the range of SB products and maybe they are doing an amazing major rewrite from the ground up…but I think this is unlikely.
That being the case I suspect the amount of maintenance required to keep VST2 support is fairly minimal - why not leave it in as a ‘best efforts / unsupported’ feature. As has already been mentioned in this thread I suspect they are embarrassed by the saga of getting HiDPI working properly across the product range and VST2 is one of the barriers…hence it has to go.
Maintaining or improving Cubase/Nuendo is all about balancing the various requirements and resources. In this case I believe they have made the wrong decision.
2 Likes
I can certainly imagine that after they see Steinberg doing it, other DAW developers might do the same. It would as beneficial for them as it is for Steinberg to only deal with one version of the VST standard.
Or, it will be seen as a feature that you can utilise VST2 in other DAW’s. No other DAW has an interest in selling VST3 to plugin developers, SB has.
The only DAW able to move a market in the way SB want would be Ableton, and they’ve only just switched on to VST3 - so doubt they’ll be switching off VST2, would cause mass hysteria lol.
Reason more developers moved to VST3 in the past year was because Ableton finally supported it.
SB have a very big problem with legacy features in Cubendo, how much that stifles development I haven’t a clue. But you’d have to think that with new MIDI remote elements coming to C12 and their ageing MIDI (CC) Insert system they want to be building control with MIDI 2.0 in mind, and VST3 as the base requirement.
Other DAW’s are already very much stronger in regards to MIDI control and modulation of plugin parameters. Cubendo is stuck in MIDI CC land still, if they’re to improve this move is probably quite integral to future developments like that.
No, but any DAW has an interest to support as little plugin formats as possible (an so making their life and maintenance easier).
or maybe other manufactures look at what their users want and make decisions accordingly ?
remember all of those polls on new features…we didn’t see much from them either 
1 Like
I appreciate your detailed answer,
I had to fork out a lot of money on hardware and software over the years.
I had to trash audio cards, computers and software for a total of thousands of pounds because and I quote “things have to move forward”…
With all due absolute respect,
I don’t care if it is expensive to create software and update it. All I care about is that every time there is a major update people with older software/hardware are thrown into the wolves mouth so-to-speak.
There is an industry method to render things obsolete so people will have to part with their cash, again, and again, and again.
Sorry, I know that this sounds cynical, but I believe this to be true.
The future will tell, but I don’t look forward in a couple of years when one will have to make a decision weather or not to upgrade Cubase, ever again…
2 Likes
Somehow Focusrite Liquid Mix still runs even with some tricks for windows 7-10. It’s discontinued since 2011 and is VST 2. It’s even 32 bits and needs jBridge. But it still runs. It has great compressor emulations. I can’t imagine to do anything without it.
My first thoughts:
- No more cubase updates
- Get another DAW that won’t dump VST 2 so soon
- Find an adapter like jBridge.
- Try to contact jBridge developer
- Develop an own solution (will likely be problematic license wise)
- Use an old Cubase version for the old plugins and then bounce the results (bad workflow)
- UAD 1176 might replace Liquid Mix emulation, but LA 2A, distressor, …. I’ll miss the somewhat gritty subtone.
- Multitrack some of my older projects where I missed that
3 Likes
My sense is that the limited Midi CC support in VST3 is one of the major reasons why many developers hold onto their VST2 licenses. It’s especially limiting for non-instruments, i.e. for fx/inserts.
ADDED: But I know that Steinberg has held firm on the VST3 implementation (limitations) for midi for years.
I’m a Voice Actor, so I don’t use too many plugins beyond iZotope’s RX stuff
That said, Cubase 10.5 LE is working just fine for me. I have no current plans or need to upgrade.
1 Like
In some respects that’s like saying no one should still play a Stradivarius, and by all means ditch that 1954 Stratacaster!
These are musical instruments. People spend a lot of time mastering them and learning their strengths and weaknesses through and through. It often becomes part of the ‘character’ of a production.
True, we can always roll-back. Get the old hardware out of the basement and just refrain from upgrading it. Branch off to a new build to play with the modern stuff, and jack it in when needed.
Still…
If they’re going to strip native VST2 support out of the main app, they should at least offer a nice bridge on the side (even if it costs a little extra). Eventually 3rd parties will offer such bridges, and if Steinberg wants to rely on 3rd parties for this that’s fine too, but it needs to be on the market and ready to go before or on the same day as the big roll out of the first DAW that ‘no longer supports VST2’. It should be a ‘modestly priced’ bridge, or even ‘free or donation-ware’ for a basic functioning model.
For what it’s worth, there are a lot of nice bread and butter libraries out there that will NEVER make use of the VST3 feature set. VST2 is PLENTY. I.E. Garritan libraries. While it’s rather old tech, they do offer about the ONLY wind and concert band library on the market (and most certainly the only one that doesn’t cost a king’s ransom)…to get something anywhere close a user would have to spend 6 to 10 times the price trying to ‘peace libraries together’ to get that combination of instruments (and you’ll still need the Garritan ones to boot, because there just aren’t many libraries out there with stuff like 10 susaphones tutti, and 6 mellophones tutti, alto horns, funky marchign percussion, drum-lines, etc.).
Hopefully Garritan and Plogue will work up a complete VST3 plugin with multiple outputs and all, but really, it’ll just be compatibility kludges. There is not ONE THING the VST3 protocol offers over VST2 that those libraries will use. Yet, they are still viable and useful libraries with a very fair price tag for what they are.
1 Like
Unfortunately, developers do care about the costs of writing and maintaining software. There is a finite limit to return on investment, whilst all non-trivial software and hardware engineering demands a compromise between progress and legacy support.
Every product has a support life beyond which there is no budget for ongoing maintenance. Whenever you buy a software or hardware product, you buy it ‘as is’; there is no guarantee of any future support beyond that folded into the contract for purchase (though that future support relies on the developer staying in business). Once the developer reaches their support lifetime limit, users must accept that some features or even the entire product will stop working with the latest hardware and software even if your example of the hardware supplied as part of the product continues to operate properly.
Some vendors build substantial post-shipping software maintenance periods into the upfront cost of their products - RME audio interfaces are one example. At the other end of the scale, consumer-grade printers get essentially no software maintenance; the drivers shipped with the printer plus perhaps a few early hotfixes are all that is ever released. Indeed, consumer-grade printers are typically disposable hardware once the warranty has expired. The cost of a new printer is so low that repairs are rarely worthwhile, even in the unlikely event that you can purchase parts at a reasonable cost and carry out the repair yourself.
Obsolescence is inevitable as standards move on. Any Firewire audio hardware is unusable with modern systems because there is no official Firewire support in Windows 10 x64 (and certainly not in Windows 11), whilst Apple dropped Firewire from the Mac lineup and OS X many years ago. USB 3 and Thunderbolt made the rationale for Firewire in new products disappear. The ongoing need for Firewire ports reduced as digital video transitioned away from tape, so there was no longer a need for digital video over Firewire for video editing purposes.
The limits of older hardware plus the declining use of the remaining installed base over time can make it hard to justify the development of updated drivers even if ongoing support is theoretically possible. With software, indefinite support for existing standards is at least theoretically possible. However, the march of technology means that support for obsolescent standards will disappear over time. You cannot run ancient 16 bit Windows applications on Windows 10 x64 (or, indeed, any x64 version of Windows) as Microsoft felt it did not make sense to stack two compatibility technologies on top of each other: NTVDM under WoW64. Compatibility for 16-bit applications existed up to Windows 10 x86, the last 32-bit version of Windows. Anyone who still needs to run 16-bit applications will need to run them on a 32-bit Windows machine or a Windows x86 virtual machine.
In an ideal world of unlimited resources and no necessity for technical compromise, support would remain for all legacy features whilst users still show any interest. In the real world, it can make sense for software developers to sweep away the technical debt of legacy features. Keeping support for all legacy features when replacing code to add new features ties up development and testing resources whilst risking performance and stability. It can also make sense to drop legacy features when refactoring existing code to improve performance or take advantage of features found on newer hardware.
VST2 is an old standard, first emerging in 1999. There have been no updates to the VST2 standard since VST 2.4 in 2006 - around the time of the first Intel Core 2 Duo and AMD Athlon 64 processors. Windows Vista had not yet been released, so there was no mainstream 64-bit version of Windows (Windows XP x64 was released late during the XP lifecycle and is perhaps best thought of as a client version of Windows Server 2003). Tiger (10.4) was the latest version of Mac OS.
VST3 first emerged in 2008. Maintenance of the VST2 SDK ended in 2013, and VST2 licensing ended in 2018. Steinberg’s announcement amounts to “we are setting a sunset date for VST2 of 10-11 years after the underlying technology went out of maintenance”.
Of course, there are many reasons why it has taken so long for many plug-in vendors to embrace VST3. Some of the perceived deficiencies of the VST3 standard have been mentioned earlier in this thread. However, two years should be long enough for the remaining vendors to migrate their current product lines to VST3 whenever this migration is technically possible.
I do not doubt there is considerable pain to come. Native Instruments has been slow to embrace VST3 and I am not sure what the current situation is with VST3 support in Komplete Kontrol or Maschine as I don’t use any NI products. I don’t recall Universal Audio revealing any plans to support VST3; UA’s lack of VST3 support will be a major issue for some. Those vendors that do support VST3 may well not produce VST3 versions of older or discontinued products. Obtaining a VST3 version of the plug-in might require a paid version update. Some developers have dropped all their audio plug-ins or have gone out of business.
I believe cessation of VST2 support is the audio software industry’s equivalent of the sunset of Flash: despite the flaws of VST2 and the deprecation of the VST2 standard, many find no reason to move on and still regard VST2 support as a core feature of a DAW. The only way to remove VST2 support is to give a deadline for the removal of support.
It is time for users to start planning for the end of VST2 support. If possible, avoid the use of VST2 plug-ins in new projects. If you are not yet ready to go VST2-free in new projects, start to investigate bridging options. Consider voting with your wallet; I considered buying a Universal Audio interface at one point, but their lack of VST3 support meant I decided not to purchase. For legacy projects, keep a legacy version of the host application with VST2 support available, using virtualisation if necessary. The upcoming deprecation of eLicenser should not be a problem from a host application perspective, as there should be at least one Steinberg Licensing version of each host application with VST2 support.
As @skijumptoes notes, there is a lot of legacy code left at the heart of Cubase/Nuendo. Cubase/Nuendo 12 should see the release of the new remote control code that was pulled late in the version 11 development cycle. At the same time, this will almost certainly see the final removal of support for the long-discontinued Steinberg Houston controller. Houston support was added back to version 11 in a maintenance release following user requests, as this was merely re-enabling the existing driver. However, there is no chance of a Houston driver being written for the new remote control code; Houston has officially been unsupported for nearly fifteen years.
Steinberg felt able to continue to ship Houston support in Cubase and Nuendo on an ‘untested and no guarantees’ basis - if the existing driver worked for your usage case, great, otherwise bad luck but you still have your other controllers even if that is only a keyboard and pointing device. Continuing to ship VST2 support on an ‘untested and no guarantees’ basis seems unlikely to work; if VST2 support is present, people will continue to rely on it in their projects and will expect it to be fully working with all their VST2 plug-ins.
I want to see Steinberg move forwards in future versions, such as MIDI 2.0 support, optimisation for big.little processors and switching to the new Windows MIDI API (so that Bluetooth MIDI and multi-client MIDI are supported on Windows). This is going to involve reworking or, more likely, replacing legacy code. As code is rewritten, it is likely that legacy features in that legacy code will be dropped.
6 Likes