Steinberg: No more VST2 Development

[Aleksey Vaneev]

VST2 ids can still be registered here: http://service.steinberg.de/databases/plugin.nsf/plugIn

VST3 is generally a nightmare, but I've found a "cheap" way to adopt it - by deriving "public SingleComponentEffect, public IUnitInfo". Effectively shitting on Steinberg's "UI vs AudioProcessor" decoupling.

But I still had to create derived "parameter" and "stream" classes. I also had to rewrite their DEF_CLASS2 macro and GetPluginFactory () function to be able to provide plug-in info from my own XML, not hardcoded into the CPP file: it's a huge miss of the VST3 API.

Then window resizing is host-driven in VST3, which is a bit wrong I think.

Then factory presets are not universally supported - e.g. some hosts do not see "factory presets" while Steinberg hosts do.

Everything is quite messy in VST3 in comparison to VST2.

[AdmiralQuality]

VST2 ids can still be registered here: http://service.steinberg.de/databases/plugin.nsf/plugIn

VST3 is generally a nightmare, but I've found a "cheap" way to adopt it - by deriving "public SingleComponentEffect, public IUnitInfo".

But I still had to create derived "parameter" and "stream" classes. I also had to rewrite their DEF_CLASS2 macro and GetPluginFactory () function to be able to provide plug-in info from my own XML, not hardcoded into the CPP file: it's a huge miss of the VST3 API.

Then window resizing is host-driven in VST3, which is a bit wrong I think.

Then factory presets are not universally supported - e.g. some hosts do not see "factory presets" while Steinberg hosts do.

Everything is quite messy in VST3 in comparison to VST2.

Right, so without your massive amount of changes, hacks and fixes, it doesn't work as it comes "out of the box". Right?

And of course, none of your changes have been incorporated into a VST3 update.

And you can't legally distribute a fixed version of the VST3 SDK yourself.

[Urs]

So even now, 5 or 6 years after its release, it's still, from what I'm hearing, an unstable mess with far more problems than it's worth.

Well, the main issues are some conceptual "oddities". Some examples:

Parameter changes come in in the realtime thread. Good luck using malloc or anything on a parameter change.

The process information is kept in the Controller component, but the DSP-component has no way to query the Controller directly*, while the Controller may exist without a DSP component attached. Thus, if you have your DSP code laid out in nice C++ objects that each have a list of parameters, Getters, Setters and a tick/process function, then using that with VST3 is rather counter intuitive. Our framework implements a lot of patterns for reflection so that any information about the plugin is available at runtime, not at compile time. This is problematic in VST3, it's okay-ish in VST2, whereas it's a bliss in AU and AAX.

VST3 doesn't seem to have a preset name concept. We have no chance to find out what a user called a preset when he saved it with the host interface.

Other than that it also has its good sides, e.g. Cocoa interface in both 32 and 64 bit, multi-plug-in containers and so on.

- Urs


*the communication is asynchronous - if you need information from your DSp component e.g. in the constructor of some object in teh Controller, you can't just ask for it - you have to request the information and then it may come back within a few milliseconds. Or later. Thus we need to instanciate a dummy DSP object that we query instead of the actual DSP object we use.

[Urs]

Aleksey beat me to it

[Aleksey Vaneev]

VST3 is hard to streamline for professional plug-in production. It's simply not designed for us professional plug-in developers, and Steinberg never asked for 3rd party approval of their approaches. They designed a thing which works for them, their simple plug-ins, not for plug-in developers.

[AdmiralQuality]

So even now, 5 or 6 years after its release, it's still, from what I'm hearing, an unstable mess with far more problems than it's worth.

Well, the main issues are some conceptual "oddities". Some examples:

Parameter changes come in in the realtime thread. Good luck using malloc or anything on a parameter change.

The process information is kept in the Controller component, but the DSP-component has no way to query the Controller directly*, while the Controller may exist without a DSP component attached. Thus, if you have your DSP code laid out in nice C++ objects that each have a list of parameters, Getters, Setters and a tick/process function, then using that with VST3 is rather counter intuitive. Our framework implements a lot of patterns for reflection so that any information about the plugin is available at runtime, not at compile time. This is problematic in VST3, it's okay-ish in VST2, whereas it's a bliss in AU and AAX.

VST3 doesn't seem to have a preset name concept. We have no chance to find out what a user called a preset when he saved it with the host interface.

Other than that it also has its good sides, e.g. Cocoa interface in both 32 and 64 bit, multi-plug-in containers and so on.

- Urs


*the communication is asynchronous - if you need information from your DSp component e.g. in the constructor of some object in teh Controller, you can't just ask for it - you have to request the information and then it may come back within a few milliseconds. Or later. Thus we need to instanciate a dummy DSP object that we query instead of the actual DSP object we use.

Sigh...

All this to replace the 2.4 spec which was finally working perfectly. The second they got their bugs fixed, they tossed it out in favor of THIS insanity.

I hope they abandon VST 2.4 support in their hosts sooner rather than later. That will be the final nail in the coffin they've been so proudly building themselves.

But you didn't answer my question. Are you successfully making stable VST 2.4 plug-ins with the VST 3.x SDK? (If not I've got an "I told you so" from a few years ago to officially register. )

[Delfinoverde]

Yes, the only real issue is that there won't be any strictly legal way for newcomers to get a copy of the VST 2.4 SDK after year end. Leave it to Steinberg to try to force people into adoption of their stillborn abortion, VST 3.x by removing "support" for a single file download. Disgusting!

If they want to not be assholes, they should release it into the public domain. (I wouldn't hold my breath waiting on THAT one! They are doing this with the specific intention of strong-arming people into using VST 3. Arne admitted as much on the VST email list.)

Exactly!
It's like AVID (ProTools) with their AAX-format. Some companies adopt aggressive, intrusive and totalitarian systems to get the power of control over cash-flows, hence to maximize profits!

[Aleksey Vaneev]

AAX is also a nightmare, designed for outdated DSP processing. Who needs DSP chips when Apple comes with 12-core MacPro? It's plain stupid...

[AdmiralQuality]

Exactly!
It's like AVID (ProTools) with their AAX-format. Some companies adopt aggressive, intrusive and totalitarian systems to get the power of control over cash-flows, hence to maximize profits!

Yep. And it makes me sick.

[Aleksey Vaneev]

I would add, who needs DSP chips when "double" processing is FASTER than "float" processing on modern Intel CPUs?

[Urs]

Hehehe, I really like AAX. Don't care much about the DSP stuff, but the SDK is simple, well strcutured and the object communication is great. It fulfills the promise that AU made, without the bloat.

If there was ever gping to be another discussion about a general plug-in standard, I think tehy should take a close look at AAX.

(without the PACE signing stunt, goes without saying)

[AdmiralQuality]

...still avoiding my question, Urs...

[Urs]

...still avoiding my question, Urs...

Because we don't do VST2 that way - we use the original VST2.4 SDK... I have no idea if and how VST3 can compile to VST2, hence I can't answer your question...

[AdmiralQuality]

...still avoiding my question, Urs...

Because we don't do VST2 that way - we use the original VST2.4 SDK... I have no idea if and how VST3 can compile to VST2, hence I can't answer your question...

So you maintain two separate code bases? Awesome.

(Just teasing you Urs, because you were such a booster for this crap a few years ago. I guess those beers Steinberg bought for all you local developers have worn off? )

[Urs]

...still avoiding my question, Urs...

Because we don't do VST2 that way - we use the original VST2.4 SDK... I have no idea if and how VST3 can compile to VST2, hence I can't answer your question...

So you maintain two separate code bases? Awesome.

(Just teasing you Urs, because you were such a booster for this crap a few years ago. I guess those beers Steinberg bought for all you local developers have worn off? )

Let's put it that way: I still prefer the basic idea of VST3 over VST2, but I agree that the pitfalls were quite huge. So yeah, I changed my mind to a certain degree and I'm happy to admit that you were righter than I'd usually like to admit.

And of course, the reasoning behind us doing VST3 was a problem with VST2 and Cocoa namespaces - which we solved by a crude hack.