Steinberg: No more VST2 Development

[arakula]

No, it won't, I'm a sociopath, it's impossible to bait me, I roam at will.
VST3 FTW, keep on whining, I've seen some happy "sandwiched" ones already, money talks-people listen, so as far as vst3 goes, money talks louder there, so soon you'll all be "vst3whiched" lol and goodbye.

[bjporter]

I'm about ready to ditch Steinberg. They have failed me. Also their control of VST is very unfortunate.

[Angus_FX]

Sample accurate automation, CPU "savings", no hassle side-chaining makes it greater than by now archaic Vst2

All of which are noble, desirable features, but they don't make up for bad engineering, or worse, the wrong underlying design philosophy. (And all of which, incidentally, could easily have been built in to "VST 2.5"). There was a carefully thought out decision NOT to do that. Ask yourself why.

It's an interesting parallel really to what's going on in with AU sandboxing, or AAX signatures. Offer users the carrot of convenience & shiny new features, and while nobody's looking execute a power-grab to force third party developers to adopt your particular world-view.

[mkdr]

Sample accurate automation, CPU "savings", no hassle side-chaining makes it greater than by now archaic Vst2

All of which are noble, desirable features, but they don't make up for bad engineering, or worse, the wrong underlying design philosophy. (And all of which, incidentally, could easily have been built in to "VST 2.5"). There was a carefully thought out decision NOT to do that. Ask yourself why.

It's an interesting parallel really to what's going on in with AU sandboxing, or AAX signatures. Offer users the carrot of convenience & shiny new features, and while nobody's looking execute a power-grab to force third party developers to adopt your particular world-view.

Just went through the VST3 sdk a bit. At first look the demos seem a bit more messier than 2.4. But the fact that you can still use VST2.4 and even recompile VST3 plugins to 2.4 means it's not even close to what Apple is doing.

[arakula]

Oh yeah? Try to compile a VST2 plugin with VST3 that supports plain old getChunk() / setChunk() methods to handle a complete bank instead of just the current preset - have fun...

vst2wrapper.cpp: nearly 3000 lines just to mediate between VST2 hosts and internal VST3 layout. And still far from complete.

BTW, just because I came across that recently: Steinberg's own PresetFile implementation can't even deal with the VST3 SDK's possibilities. While the SDK allows multiple "units" and/or "program lists" (and hey, it's absolutely great that it supports two conflicting implementations - makes hosting it extremely funny), the .vstpreset file can only contain up to one unit's / program list's data. Talk about engineering excellence.

[Angus_FX]

Yes, VST3 is kind-of-sort-of-backwards-compatible-ish to VST2.

But it's not forwards-compatible. Making a big & complex VST2 plug-in fully VST3 compatible, without resorting to hacks which go against the spirit of VST3, is a major undertaking.

The most important aspect, which I appreciate is not very visible to end-users, is that instead of just specifying the interconnect between host and plug-in, VST3 takes a much more active & intrusive role in specifying the internal architecture of the plug-in. If my plug-in provides the correct i/o, it's none of the host vendor's goddamn business whether it's an MVC architecture.

Whether the architectural blueprint is good or bad is almost irrelevant. (and I don't for a minute claim that it's all bad).. the point is that, using a hardware analogy, if vendor A and B both provide 1/4in jacks with within-spec voltages and impedances, they can interconnect well without either party having any knowledge of, or say in, how the other builds their gear. MIDI is similar.. it doesn't really dictate the internal voicing architecture of synths or specify complex ways of handling articulations, it just tells them what note numbers to play & lets get on with it. What's nice about this kind of design is that it allows people to build gadgets compatible with the standard which the original designers never remotely envisaged.

I don't claim that VST2 is perfect in that respect, there's no such thing as a perfect standard, but if you judge it on the basis of what hosts/plug-ins have evolved since it was first released, and how much broader they are than what the spec was originally built to do, it's a pretty big accomplishment. VST3 throws all that away in favour of a different path, more tightly fitted to the needs and ambitions of a particular DAW vendor.

[duncanparsons]

where's the 'like' button for Angus and Hermann's posts..?

[arakula]

Here

[mkdr]

Yeah well i understand your points about porting a VST2 plug. But the happy situation is that you don't have to port your plug unless you desperately need the new features (note expression mostly? side-chain? what else is there?). But it should be great for starting new products. Gonna test porting my own old vst2 plugs to vst3 soon. Shouldn't be too difficult as they are rather simple plugs in the first place.

I rather like the "black box" approach to plugins too. But maybe there are some things that Steiny felt needed improvement to keep the ball rolling?

As a plugin user i have to praise Steinberg for bringing us Asio Guard, sidechaining, vst3presets, note expression, better automation and better remote controller use.

Maybe the ability to compile VST2, VST3 and AU for Win and OSX from one codebase will help plugin developers too in the long run.. if it works?

[EvilDragon]

Except it doesn't QUITE work...

[mkdr]

Except it doesn't QUITE work...

Ah, shame. The SDK seems to include some nifty features I'm very pleased to use. For example showing host context menu on right click for setting parameter automation. Or the wysiwyg Inline UI Editing. It took a bit of juggling to get it set up, but it seems rather cool now

[duncanparsons]

Here

oh, very good!

[Breeze]

I'm really not in the position of being able to comment on the intricacies of the VST3 API, but I had this thought with reference to Angus's arguments: is it at all possible that VST3's invasiveness and breaking of the true black-box plugin model is an attempt at improving stability within the VST environment?

I've often faulted Steinberg for allowing third-party plugin problems to take down a DAW mid-session. Most of us have experienced the frustration of losing hours of work at some point or another and Steinberg usually gets the flak for it. But more often than not, in my experience a plugin was responsible.

[Aleksey Vaneev]

Breeze, no, stability may only worsen with such heavy architecture as VST3 has.

Stability may only be increased by running plug-in in a separate process.

Stability of code interoperation is generally a x86 platform design problem. With its "linear process address space" simplicity comes the chance to ruin the flow of code of one party by the flawed code of another party.

[Urs]

is it at all possible that VST3's invasiveness and breaking of the true black-box plugin model is an attempt at improving stability within the VST environment?

This is true in case their plan was to alienate bad programmers.

I've thought about this a lot. The whole issue about separating UI and DSP came about when CPUs were still slow and host developers came up with concepts to fork out DSP power across multiple machines. Apple did that with Logic Nodes, and it kind of worked. However, nowadays the overhead of distributing plugins onto other machines is nuts in respect of the power we have on a current i7 CPU. In review of recent developments I think I go with Angus.

For us the main bummer about VST3 is the asynchronous message system, which is a direct result of the separation of UI and DSP part. This alone makes development so complicated and overly prone to buggy behaviour that talking about "more stability" sounds like straight from Tepco. Pretty much all of our VST3 bugs are a result of this.