Steinberg SDK comparison: VST 3 vs. VST 2.4

[MRULTRA]

I'm very new at VST development (literally, this is day two of my adventure!) and curious if anyone is using the new VST 3 SDK.

It's not so new now anymore, yet I don't see much reference to it online (in developer areas such as this) nor are any of my recently downloaded/purchased VSTs indicating they are v.3 VSTs (Ableton Live kindly displays the VST version next to each).

Given the outline of VST v.3 on Steinberg's web site, the quoted "improved performance" (wonder how much?), ability to resize windows, and support for 64-bit (presumably impossible with prior versions?) seem to be the stand outs, at least for me.

Oddly, though, I've been having a very hard time compiling a VST successfully with the VST3 SDK. I've had no problems whipping out (albeit very simplistic) VSTS with VST2.4 SDK. For the record, I'm using VC++ 2010 Express.

Perhaps this is an issue encountered as well by other more advanced programmers? Is VST3 a little more finicky?

I think I'm going to stick with VST2.4 for now... I don't think most DAWs will be removing support for it anytime soon?

[arakula]

Given the outline of VST v.3 on Steinberg's web site, the quoted "improved performance" (wonder how much?),

IMO not much, if any.

ability to resize windows,

VST2 can do that, too.

and support for 64-bit (presumably impossible with prior versions?)

VST2 can do that, too.

The only improvement IMO is sample-accurate parameter automation without the need to slice the audio buffers - and VST2 could have implemented that easily, too.

[Aleksey Vaneev]

This is all wrong. VST3 has NO real advantages beside additional buses for side-chaining (but this feature could have been implemented in VST2.4).

VST2.4 can be used to create 64-bit plug-ins. VST2.4 can be used to resize windows (we have this working), and VST2.4 is already VERY efficient - the process call is a direct function call which is then redirected to a class method (this isn't expensive).

In my opinion, VST3 is simply an expression of ambition of some of Steinberg's developers. It's a complete failure from the marketing point of view, because they can't sell it to me, and they can't convince my customers since VST2.4 plug-ins work just fine (except for side-chaining which is an utterly minor feature if we talk about its market share).

[aciddose]

actually vst2 does implement it, it was just never used for some reason. perhaps if other hosts started to actually use parameter change events it might force steinberg to implement it.

the reality of it though is that you actually don't really need sample-accurate parameter changes in most cases. this is even stronger an arguement if you consider how small audio blocks are these days in combination with the majority of instruments and effects doing block-processing anyway.

regarding vst3 - don't do it

the main problems with vst2 are that the implementation jumps all over the place.. in some cases it works one way, and suddenly in the next function in a completely different way. there are layers of backward compatibility and tons of redundancy. the dispatcher is combined with string based canDo messages and with direct function pointers. on top of that hosts still expect to find a specific implementation of a wrapper class (audioeffectx) in the obj pointer and access it directly. (most have fallbacks, but making the assumption in the first place doesn't make any sense)

ideally vst3 would have been a stripped down and incompatible version of vst2 with all the interfaces using the same method. (ideally, case-insensitive strings, typecasting of struct pointers, event buffers)

in reality, it isn't.

instead it's a completely weird implementation of the same stuff in another format with no advantages which nobody would ever want to use and is even worse than the already bad implementations in vst2.

[Aleksey Vaneev]

Indeed, sample-accurate automation is a nonsense not only because in any realistic scenario a small audiocard block size will be used, parameter changes usually require low-pass smoothing anyway - host can't do it for a plug-in anyway. For bouncing at large block sizes sample-accurate automation may be useful, but that's it.

[Aleksey Vaneev]

aciddose, over time I have refined my VST2 implementation for a lot of audio hosts - and it isn't really quirky after all. It could have been all initially described in the SDK, though.

[Resplendence]

There are a lot of problems and shortcomings with current standards and VST3 according to me has not addressed any of these.

What is blatantly missing:

-Contracts, standards and guidelines for even the most simple features
-Decent documentation
-A contract for multithreading and the utilization of CPUs for both the host and the plugin
-Plugin isolation for stability (currently any plugin can crash the host)
-Distinction between live and studio technology
-Guidelines for exception handling
-An interface and tools for plugin verification and qualification
-An interface and tools for measuring execution times and latencies

just to name a few.


Some bright people of the audio developer community should sit around a table with some of the big companies in the industry and discuss first the requirements of a new audio plugin standard followed by some serious architectural thought. That is probaly just wishful thinking but in the meantime I hope VST3 will be thoroughly ignored by the industry and community so there is no need to waste energy on it.

//Daniel

[LOSER]

Some bright people of the audio developer community should sit around a table with some of the big companies in the industry and discuss first the requirements of a new audio plugin standard followed by some serious architectural thought.

You mean like: http://retropaganda.info/archives/gmpi/ ... draft.html ? Alas that stalled for some reason, even though so much thought: http://www.freelists.org/archive/gmpi has been put into it.

[Aleksey Vaneev]

There was a "new plug-in API" initiative started by Angus Hewlett back in early 2008. We have collected quite a big pool of interested plug-in developers at that time. But it seems that this initiative was forgotten since then. Probably due to VST3 release. But I guess Angus wasn't totally right thinking VST3 will solve most of our problems. VST3 worsened plug-in developer problems considerably.

[Resplendence]

I can easily imagine how such undertakings could fail. Lack of consensus, too much bureaucracy, overengineering, lack of funds, conflicting commercial interests (not to say that any of these actually happened).

Then plugins suffer from the problem that there will be no hosts until there are enough plugins available, similar to gas stations and hydrogen cars.

So if some commercial party such as Steinberg steps forward and says: "here it is", that is not at all so bad only if it would address nowadays technological challenges, improve quality standards and would address the issues where it was mostly lacking. In that light VST3 was very disappointing, it looks like more of the same with only interface changes.

//Daniel

[Aleksey Vaneev]

Yes, interface changes - moreover, WRONG interface changes. Who needs splitted user interface/audio code messaging system now when we have 6 and 12 core CPUs coming quickly? FX-Teleport-like solutions are not required anymore - that's sad for its developer, but it's a reality. Logic Node has a similar fate. It's a lot of engineering effort and induced design limitations that will just end up being obsolete quite soon.

[Aleksey Vaneev]

BTW, the "plugin isolation for stability" is indeed a very required feature, but it is not possible to implement it in an efficient manner on the existing Intel x86 platform. It's possible via inter-process communication, but this has quite a lot of overhead, and is not perfect latency-wise: may easily fail at 32 sample audiocard block size.

In a "dream world" each exported DLL function call could produce an execution context switch that almost completely decouples address spaces of the caller and callee.

[Aleksey Vaneev]

At that time I thought that Angus is the right person for a new publicly-discussed API. Of course, he would be the captain since his company has the capability to produce adapter plug-ins that convert this new API to both AU and RTAS, and VST. It could be a market for Angus. There would be some critique towards Angus, no doubt, but let's be real - things should give profit to evolve in the right direction. Beside that, the API should be quite good for plug-in developers to jump the wagon. It's a win-win situation, really.

[duncanparsons]

There was a "new plug-in API" initiative started by Angus Hewlett back in early 2008. We have collected quite a big pool of interested plug-in developers at that time. But it seems that this initiative was forgotten since then. Probably due to VST3 release. But I guess Angus wasn't totally right thinking VST3 will solve most of our problems. VST3 worsened plug-in developer problems considerably.

I seemed to recall that Angus and others started the initiative because of VST3, and when the spec was published he was very sceptical, rather than thinking it would solve the problems.

The thing is getting the take up from host companies - Steinberg, Digi and Apple/Emagic legacy, etc. wouldn't touch it, and they represent a large slice of the market. It would have to be supported by a few bigger 'indy' hosts (Ableton, FL, Presonus, Cockos), and have a couple of 'to die for' plugs only released in that format..

I'd still like to see it happen

[MRULTRA]

I appreciate the comments and subsequent discussion that my naive question spurred on. Some of it is admittedly over my head at this point, but I feel much more confident sticking with VST 2.4. In fact, I just deleted all traces of the VST 3 SDK from my hard disk.