Steinberg: No more VST2 Development

[mahaya]

In VST3 you're forced to use a certain threading model. You now have no guarantee of when data will be passed between GUI and processor. This kind of thing causes people real problems.

You're not forced to use the separate processor/controller model. If you inherit from SingleComponentEffect it is similar to the model used in vst2, au and so on.

Cockos has some vst extentions for better parameter visualisation (parameter values between 0 and 1 is another flaw in vst2 that no other format has) but afaik no host other than Reaper has adopted it. I'm not even sure how many plugins make use of it.

And imho that's the main problem with vst2 extensions or a new format. Devs will still need to develop vst2/vst3/au/rtas/aax so there's no need for a host to support a new format.

[aciddose]

Under windows you can remove au/rtas/aax right away. It isn't even possible to make these work under windows, assuming you had access to the components required to create a working host in the first place.

It then becomes VST2 vs. OVST with extensions and VST2 compatibility vs. VST3. Most people will immediately see very clear advantages to OVST, if such a thing were possible.

To avoid that, in my opinion they'll need to make VST3 fully VST2 compatible. The problem however is they're now stuck between VST2 compatibility and VST3 compatibility.

What we really needed was a VST2.5++. 2.5 which is half-way between 2 and 3 in terms of features and ++ with regard to everything both 2 and 3 are still horrible at.

It may yet turn out like winamp3 - maybe they'll jump right ahead to VST5.

[matt42]

I didn't get the impression from either post that anyone was vouching for VST3.

You're probably right. I tried to clarify that I may have misinterpreted things, but didn't mention you directly. I guess I jumped on Jeff's comment as it seemed awfully close to the kind of arguments some proponents of VST3 have come up with. For example it has been variously said that devs who prefer VST2 over 3 are either lazy, ignorant or lack experience. Jeff didn't directly say this which was why I made my clarification.

You're not forced to use the separate processor/controller model. If you inherit from SingleComponentEffect it is similar to the model used in vst2, au and so on.

This is true. I have in fact done this myself. Though I consider it a hack rather than a feature of VST3. So you are right that my argument is not a 100% accurate. I would stand by the assertion that the threading model while often touted as a feature of VST3's superiority can actually turn out to be an annoyance to be worked around.

[arakula]

Winamp will be dead after Dec 20th, BTW.

[whyterabbyt]

Under windows you can remove au/rtas/aax right away. It isn't even possible to make these work under windows

Thats very strange. How come all my RTAS and AAX plugins do work in Windows, then?

[aciddose]

I knew I should have added that to my post. I made an attempt to allude to it.

"If you aren't avid or apple."

Other hosts can't be written supporting the formats. On OSX you can use AUs as a component of the OS via the OS SDKs, but you can't go from there to windows and have it all work seamlessly.

For avid's SDKs, you can't even get access to these without signing a non-disclosure agreement. The RTAS SDK is the most horrible set of useless c++ classes in a highly interdependent hierarchy I've ever thought possible for a SDK. Think VST3 if it were written during Oktoberfest in between passing out. In fact it appears as if VST3 takes inspiration from RTAS and my theory is that they wanted to be able to gain the same legal protection RTAS takes advantage of.

[ponce]

Reading all of this about plugins formats I'm tempted to sing a tale about how it happens with formats in the video codec world (my current employer make codecs).

Codec specifications target decades of lifetime. A video bitstream is the standard being defined, with a reference encoder/decoder. Problems are worked out way before the standard is declared done, and by several standards bodies.

The result is so good that the Googles, Microsofts and Apples of the world don't really get a chance to force their formats on the industry excepts niches. The benefits of having one, single format that also happen to be good can't be overstated, since it allows developers to focus on their core competency instead of building abstractions over similar copy-pasta formats.

Maybe in the audio world, building exclusively VST 2.4 would force host vendors to propose extensions to fix the real problems, or at least work together on a suitable replacement. Cockos has been doing the right thing imho.

[sonigen]

And imho that's the main problem with vst2 extensions or a new format. Devs will still need to develop vst2/vst3/au/rtas/aax so there's no need for a host to support a new format.

Absolutely, almost all developers are going to look at a new plugin format and say "Whats in it for me? How does it make my life easier?"

A clean API, great docs, open source. None of that will be enough because at the end of the day it's still more work to implement, and no-one else is using it any
way.

IMO the only way a new format would get off the ground without a major host vendor backing it would be if it comes with wrappers for all existing formats, for hosting and for plugins. So a plugin developer can build against one API and get all the other formats for free. And a host developer can do the same.

If fact it could just start life as a plugin wrapper SDK, once it's up and running, stable, and has all the wrappers, then you can add the new plugin format. By then you'd have a good idea of everything that would be needed to keep the new plugin format able to easily wrap existing formats.

[mystran]

If fact it could just start life as a plugin wrapper SDK, once it's up and running, stable, and has all the wrappers, then you can add the new plugin format. By then you'd have a good idea of everything that would be needed to keep the new plugin format able to easily wrap existing formats.

Well, you could put the plugin and the wrapper in the same DLL (or .so or whatever you have on other platforms). Doesn't even matter which direction you're wrapping (or you could wrap both to an internal API) if the host is looking for the VST entry point, it'll find that and if it instead knows to look for the new API entry point, it'll get that instead. If you specify that hosts that support both APIs are required to understand this and pick their preference, then as long as you don't call your entry point "main" it should work perfectly fine.

Really, it's not like there are any real technical reasons that you couldn't start publishing those today. Just draft and API and go ahead.

[Caco]

And imho that's the main problem with vst2 extensions or a new format. Devs will still need to develop vst2/vst3/au/rtas/aax so there's no need for a host to support a new format.

Absolutely, almost all developers are going to look at a new plugin format and say "Whats in it for me? How does it make my life easier?"

A clean API, great docs, open source. None of that will be enough because at the end of the day it's still more work to implement, and no-one else is using it any
way.

IMO the only way a new format would get off the ground without a major host vendor backing it would be if it comes with wrappers for all existing formats, for hosting and for plugins. So a plugin developer can build against one API and get all the other formats for free. And a host developer can do the same.

If fact it could just start life as a plugin wrapper SDK, once it's up and running, stable, and has all the wrappers, then you can add the new plugin format. By then you'd have a good idea of everything that would be needed to keep the new plugin format able to easily wrap existing formats.

+1 this is the most pragmatic way forward for people unhappy with the current situation.

There is also enough people around experienced with the different plugin formats that it should be a feasible approach to get up and running if people actually want change to happen.

[Kingston]

It's a bit bothersome to traverse back 15 pages of discussion and maybe it was mentioned before but Juce pretty much does all that already and it has high quality standards. It's reasonably modern when it comes to interfaces and conforms to very decent C++ form. Surely its license will hamper down developers, but then again a framework like this is a lot of work to implement, test and maintain. I don't see it happening free as in free beer.

[duncanparsons]

The RTAS SDK is the most horrible set of useless c++ classes in a highly interdependent hierarchy I've ever thought possible for a SDK. Think VST3 if it were written during Oktoberfest in between passing out.

Sums it up perfectly.

[DaveHoskins]

The RTAS SDK is the most horrible set of useless c++ classes in a highly interdependent hierarchy I've ever thought possible for a SDK. Think VST3 if it were written during Oktoberfest in between passing out.

Sums it up perfectly.

They should be sacked. Fecking jobsworths and office politics. Over engineering and keeping their bloat to keep things 'worthy' or in other words, keeping their job without any thought for the future.
Look:
http://en.wikipedia.org/wiki/Jobsworth
And:
http://en.wikipedia.org/wiki/Software_bloat

And all we wanted was a simple buffer to fill and the means to attach to a host.
Pathetic.

[HrastProgrammer]

And all we wanted was a simple buffer to fill and means for attaching to a host.

Exactly.

+ I want a full MIDI support (yes, call me conservative/old-fashioned) and that's it.

Don't really understand all that bloatware and overbloated frameworks ...

That's the reason why I recently started to work on my own 32/64-bit VST host: just a window with plugin editor/interface, simple ASIO input/output support, full MIDI input, eventually 4-way insert rack for additional FX processing and nothing else - this will cover everything I need when doing some music.

[duncanparsons]

And all we wanted was a simple buffer to fill and the means to attach to a host.
Pathetic.

Indeed. I know Urs likes it, but AAX is just looking like more work for no visible benefit.. I've spent most of the last 18months figuring out APIs, OS changes (note - /not/ 'upgrades'), and config files rather than actual programming.

Hey ho.