Not quite literally. But close; according to rekkerd.org they've announced that they are 'planning to make the SDK for VST 2 unavailable by the end of this year'

This isn't them just dropping support for it, or stopping working on it. After that point in time no one who doesn't already have the VST2.x SDK will be able to legitimately obtain it, and thus create VST2 plugins.

whyterabbyt wrote:After that point in time no one who doesn't already have the VST2.x SDK will be unable to legitimately obtain it, and thus create VST2 plugins.

Won't new devs simply use the VST3 SDK to create VST2 plugins, and the world will carry on spinning as normal? I think most devs have got to some multiplatform compile setup and have solved these sorts of issues a long time ago :

The VST 3 development kit not only generates VST 3 plug-ins, but also is capable of rendering to VST 2 and AU formats, making it the ideal choice for outputting three formats.

Saying this is like a pita, as i own a big bunch of old vst2 plugs, but it's more than time. vst2, vst3, 32 bit & 64 bit for windows, 32 & 64 bit for mac os 10.5, 10.6, etc... What a headache. Letting go vst2 (and certainly soon 32 bit) means more time for bug fix and developpment.
Avid did the same with rtas/aax and logic just stopped 32 bit developpment and support.

whyterabbyt wrote:After that point in time no one who doesn't already have the VST2.x SDK will be unable to legitimately obtain it, and thus create VST2 plugins.

Won't new devs simply use the VST3 SDK to create VST2 plugins, and the world will carry on spinning as normal? I think most devs have got to some multiplatform compile setup and have solved these sorts of issues a long time ago :

The VST 3 development kit not only generates VST 3 plug-ins, but also is capable of rendering to VST 2 and AU formats, making it the ideal choice for outputting three formats.

There are a lot of smaller VST companies not producing VST3 plugins, so I'd suggest that they're not using the VST3 SDK. Im sure they have reasons for that. I'd say its not an uncommon perspective that the VST3 standard is utterly redundant goalposts-moving for the sake of it.

Also, Ive seen issues of thie following nature listed more than a few times.

the chief reason to use the VST3 SDK was the essentially free AU and VST2.4 builds. However, we ran in to so many problems along the way (this plug-in, while having a simpler purview, is way more complex internally than Filterstation, our first build with this toolchain) that our next product is absolutely going to be VST2.4/Symbiosis. Something that should have taken 3 weeks on the outside is running the clock out on 5 months now, with no end in sight.

Plugin standards changes don't particularly help third party developers, they're just an expense, and I'm get the impression that rewriting a plugin with the VST3 SDK and wrapping that to VST2 is not 'simple use', let alone that it should be forced on developers. Having set a precedent with the VST2 SDK, who says that Steinberg wont deprecate support for VST2 in the VST3 SDK?

edit for typo

Last edited by whyterabbyt on Tue Sep 03, 2013 2:15 am, edited 1 time in total.

"While VST 3 was introduced in 2008, Steinberg's technical support and development of the VST 2 SDK is now at a closing point. The VST 3 development kit not only generates VST 3 plug-ins, but also is capable of rendering to VST 2 and AU formats, making it the ideal choice for outputting three formats."

mabian wrote:"While VST 3 was introduced in 2008, Steinberg's technical support and development of the VST 2 SDK is now at a closing point. The VST 3 development kit not only generates VST 3 plug-ins, but also is capable of rendering to VST 2 and AU formats, making it the ideal choice for outputting three formats."

- Mario

And here was me thinking I'd replied to that 5 minutes before you posted.

Im curious though. Given all the stuff that people were already able to do (multiple inputs, resizeable windows, audio inputs on instruments etc) with the VST2 SDK, before Steinberg introduced them as 'new' features of VST3, it kind of implies that Steinberg dont think that VST2 plugins do any of this stuff. So does their 'render' to VST2 allow these things we already have (that they imply we dont have), or not?

mabian wrote:"While VST 3 was introduced in 2008, Steinberg's technical support and development of the VST 2 SDK is now at a closing point. The VST 3 development kit not only generates VST 3 plug-ins, but also is capable of rendering to VST 2 and AU formats, making it the ideal choice for outputting three formats."

- Mario

And here was me thinking I'd replied to that 5 minutes before you posted.

I took a fragment of the official Steinberg announcement, you didn't... I thought it was a more complete and "authoritative" answer

EDIT: just noticed now Krzysztof Oktalski took a piece of the announcement too, sorry.

Im kind of seeing this as an admission of failure of VST3 to be honest; There are only 3 host companies supporting VST3 plugins, AFAIK (Steinberg, IL and Presonus), and only the larger plugin developers are getting there, and incredibly slowly at that.
It would appear to me that the only way Steinberg have to get VST3 embedded in the wider market is to pull direct support for VST2, so that people are essentially given the choice of 'build for VST3 to get your VST2 version, or not at all'. If the VST3 carrot was as compelling to developers as they imply it should be, they shouldnt need this kind of stick.
Deprecating the VST2 SDK is fair enough. Removing it completely is an attempt to force VST3 on develoeprs whether they want it or not.

In theory, it should. (multi-channel for VST2)
In practical terms, the hosts need to actually understand that.

Apparently, Steinberg is not capable of using VST2 plugins with Sidechains, here you need to use the sidechain trick. But load the very same VST2 plugin into a modular subhost, and suddenly you can access the channels.

Another prime example would be old dlM's "Truc2 Mini". This one has 1 stereo in and 4 stereo outs and is a VST2 plugin. Cubase in itself can only use the first stereo in/out, even with a QUAD channel (since it can't create 8 channel subbusses). Use a modular subhost, works.

The thing with the SDK, and that is my understanding, is that they want to press forward and actually focus on maintaining one SDK rather than two. As stated several times, VST2 rendering is possible with the SDK, and Cubendo/Wavelab will still support it.

So... developers and host providers that still use VST2 now have some time to think about actually "upping to VST3" (which will happen eventually - see AVID with AAX, though here the period was shorter). Though VST2 will still be possible to render (IIRC, it'll drop VST2.4 compatibility).

That the SDK in itself has issues (like the infamous "audio forward bug" while rendering in Wavelab with VST3 plugins, which still doesn't seem to be documented/fixed according to the companies I betatest for), lies on a whole different ballpark.

So...
I don't see a problem with dropping the VST2.4 SDK, if it's really built into VST3.5 (current status!). I'd see a problem if Steinberg would announce VST4 (which will happen eventually) and drop VST2 in the process.

Last edited by Compyfox on Tue Sep 03, 2013 3:11 am, edited 1 time in total.

This thread should be in the DSP forum. Now you'll get common folk guessing about things they don't understand.

whyterabbyt wrote:So does their 'render' to VST2 allow these things we already have (that they imply we dont have), or not?

VST SDK 3.x comes with wrappers to VST 2.x and AU formats, has done for years already. They probably aren't perfect, but then VST SDK 3 alone is so much better as standard as either of those two. You can almost think of it as coding safety feature having to first implement your plugin as VST SDK 3 architecture. It forces a developer to implement independent DSP process and parameter handling.

This has been a source of endless confusion of VST 2.x when the two were interleaved, especially from host developer point of view.

mabian wrote:EDIT: just noticed now Krzysztof Oktalski took a piece of the announcement too, sorry.

and macmurphy. that's why I thought it was funny. honestly, I knew that bit. Looking back I should have said "no one who doesn't already have the VST2.x SDK will be unable to legitimately obtain it, and thus create VST2 plugins directly", so admittedly poor choice of words on my part.

whyterabbyt:
I still think it's down to the host providers how "well" the VST2 SDK is actually implemented. Or whether or not they will up to VST3.

Steinberg seem to ignore their own standards, while other developers seem to loosen them to actually fully support what's possible with VST2. And I also see more and more smaller developers going for VST3 versions.

I think, in the end it will be a host war again, the host that has the best support ultimately wins. Unless Steinberg says "we drop VST2 completely" with the VST4 SDK (which is only a matter of time, considering we're on 3.5 already).

Apparently, Steinberg is not capable of using VST2 plugins with Sidechains, here you need to use the sidechain trick. But load the very same VST2 plugin into a modular subhost, and suddenly you can access the channels.

Another prime example would be old dlM's "Truc2 Mini". This one has 1 stereo in and 4 stereo outs and is a VST2 plugin. Cubase in itself can only use the first stereo in/out, even with a QUAD channel (since it can't create 8 channel subbusses). Use a modular subhost, works.

well, although Ive been using a subhost of one type for complex routing myself (for about a decade), these kinds of thing do work in various other hosts without needing a subhost.

The thing with the SDK, and that is my understanding, is that they want to press forward and actually focus on maintaining one SDK rather than two. As stated several times, VST2 rendering is possible with the SDK, and Cubendo/Wavelab will still support it.

So... developers and host providers that still use VST2 now have some time to think about actually "upping to VST3" (which will happen eventually - see AVID with AAX, though here the period was shorter). Though VST2 will still be possible to render (IIRC, it'll drop VST2.4 compatibility).

As I say, I dont think that that many developers, particularly small developers, want VST3. If they did, there'd a lot more VST3 plugins. I dont think this is a technical decision, its a 'political' one. The code isn't being maintained, AFAIK, so removing the old SDK doesnt change anything they actually do.