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.
