VST 2 Coming to an End


#1

Late 2013 we announced that the Software Development Kit (SDK) for VST 2 would no longer be maintained and would only be available as subset of the VST 3 SDK. Five years down the line and this transitional phase is now also coming to an end.

From October 2018 onward we are closing down the second version of VST for good. While the VST 2 SDK has been unavailable, and so have maintenance and technical support, the subset within the VST 3 SDK will also be omitted.

https://www.steinberg.net/en/newsandevents/news/newsdetail/article/vst-2-coming-to-an-end-4727.html

Lord help us.


#2

Well… so says Steinberg, but what does that mean in the real world??


#3

Well, it had to happen sooner or later. Such is the way of advancement in technology. I just hate when it bites me in the arse! But It should be OK for my C3 use for a long while as far as my stable plugs if the vst 2 support is still available in the Cantabile host going forward. That’s what Steinberg is doing with Cubase and Nuendo. Hopefully VST3 will become available for C3 at some point, it’s on the major features list on Trello.

Dave


#4

Not that all developers follow Steinberg’s lead, but many do, and the sheep will follow. It still amazes me how many current VSTs defaults loading into the Steinberg folder.


#5

May not be a big issue as software does not wear out, so existing VSTs will still work. Assume developers can still develop against a VST2 SDK they have downloaded and still works.

Unsupported does not mean it will stop working immediately. It means that there is a risk that as other software moves on, there may be a point in time when some change to an OS or driver (say ASIO) breaks the deprecated VST2 SDK.

Just to give an example. The Software Editor for my Nord G2 engine has not been updated for years, probably was updated last for Vista (spit), but still works well on Windows 10. So far I have not needed to set up a different partition with an older version of Windows on to run it.

Only failure I have has so far with legacy software is AN1xEdit failing to install on Windows 10, but it turns out that is an installer problem! Install on WIN7 and then manually copy the AN1xEdit program folder to Windows 10 and it runs just fine.


#6

I’ve the all the SDKs.
The real issue is when the plugin hosts say they are not supported.
It’s not so much the plugins being updated but the classics that will be gone forever.


#7

It means all them confederate dollars you got stashed are no good any more …
:slight_smile:


#8

Eventually…goodbye VB3 as it fades into the darkness of WIN 13.


#9

Surely there will be some kind of emulator or bridge to keep that stuff going. I’m not leaving VB3 behind.


#10

That is why I am clinging on to Win 7 as long as I can. C3 may actually become the ONLY future source to use VB3.

I found an old copy of Voyetra a few days ago. Made me realize I have a studio desktop with XP and E-MU 1616M PCIe gathering dust. So amazing for it’s time.


#11

There are already bridges and hosts that bring ‘alien’ formats into the host. Metaplugin, for one.
But VST2 will only stop working if the host app determines that it will stop working. VB3 will not stop working, even if you maintain a host that will run it via midi! :slight_smile:


#12

That’s what I’m thinking.


#13

I think that it would be really nice if, before they shut down VST2, that they FINISH VST3?
What I mean (and there could be more problems I’m not aware of) is that, VST3 plugins (at least the one I’m using, TH3) don’t respond to midi program change messages! Control Change yes, Program Change no!
I thought at first that it was simply a problem in TDFKAS, Sonar Tech Support (when they HAD Tech Support) told me that VST3 didn’t support Program Changes. I thought, at the time, that they were full of it, but same in Reaper too.

Now, I’m not really knowledgeable when it comes to the details of VSTs, so if I’m wrong, someone please tell me what I’m missing?


#14

I posted a question to the Steinberg VST developer forum to try and get some clarification on exactly what this means… but it seemed to only raise more questions.

https://sdk.steinberg.net/viewtopic.php?f=4&t=561


#15

It’s worth remembering that the VST2 or VST3 are simply definitions of APIs. The entire point of an interface based API was that you could guarantee the methods that are available. So while Steinberg may choose not to host the SDK any more for 2.4, so what? Enough copies are out there in the field. If there is sufficient groundswell support (and I cannot imagine it disappearing for a long time yet) then 2.4 will carry on and on, as some GitHub resource. “Not supported” (bySteinberg) does not mean “not implemented” or even “not implementable”. Avid pulled RTAS in favour of AAX - but Avid were actively involved in approving these products, so when they stopped, everyone stopped. That is NOT the case with VST2.4 at all. All the time JBridge bridges, these 2.4 plugs have a use.

I had a look at the VST3 SDK and can see why the controller and audio engines have been teased apart. Speaking as software engineer, it makes some kind of sense. If you imagine building an audio process, that relies on <5ms to run a strictly timed algorithm, you really don’t want to be mixing your UI calls and messages with that. You’d want them on separate threads.

The point made about VST3 not supporting “program changes” is quite true. But there is a reason. It is tempting to consider a plugin as a MIDI device, and hope therefore that the VST2/3 API is expressed in terms of MIDI, perhaps even being MIDI compliant. It is not! The boundary of “MIDI compliance” (if it was to be taken seriously by host authors) is actually the “host” itself, because it is the host which has responsibility for managing audio and MIDI device access, and controlling global settings. That is, if you compare a host to a multi-timbral synth, a plugin is more like a given “channel” with its own algorithm and patch/program/sound, and the host more like the overall “instrument”. Since MIDI is about comms between devices, MIDI stops at the host, and internal messaging can be expressed in other ways. MIDI is but one comms standard - you may get NoteOn from a network, from OSC, from a script, from a JoyPad. Provided the host can interpret these “input signals” and map them to the API, you will get a function call in the plugin called. But would it make sense to have “MIDINoteOn” “OscNoteOn” “NetworkNoteOn” “JoypadNoteOn” in the plugin API? No. You want one - “NoteOn”. It wants to be external comms agnostic, and only concern itself with the actual function being asked. So “MidiProgramChange” CAN be implemented - but by the host in VST3, and cause a “LoadProgram” function to be called, achieving the same thing.

Now while that all might sound like I am defending VST3, I am not - I am extremely critical of the abandonment of MIDI, consciously in the host/VST world, because MIDI is staple, established, extremely well thought out, functional, quick enough actually (most times!) and actually quite under used in terms of its potential. If a host cannot switch sessions using MIDI there is something missing - is that not what the “Song Select” message is for? If I cannot “BankM/BankL/ProgramChange” pretty much any plugin using a host, something is missing. If I alpha scroll a dial on an 88noter, and the volume/pan of the plugin shoots up to maximum (deafening crowd and destroyng amps) then the host is not reapplying controllers responsibly on patch change. And all these things are what keeps VST stuck in bedrooms and not on stage.

So for my money, please keep developing 2.4 and 3.0 VST. Or create a new API that works better for multi-core support - anyone check out Intel’s 28core 5GHz i9 chip? Why not talk to the folks developing ReactOS about booting into a live performance mode where NOTHING is loaded except Cantabile and your plugins, and your ASIO device? That has to better than Win10 updates.

Steinberg may have led the charge, but an intelligent, creative community now knows what it wants, and if they are pulling back for commercial reasons, then the field is open for the more technical among us to come up with something informed by VST but which is designed out the gate to do live sound better.

PS>
Just like to make clear that ASIO and VST are unrelated APIs. They are separate, with no overlap at all.


#16

Thanks David and Welcome!

This is some good reading for a curious old techie…

Dave


#17

Great overall post, but isn’t the existence of Cantabile, this forum, and the ever increasing number of exponents of live performance, on stages around the world, testament to the fact that VST is clearly out of the bedroom?