Don't know if anyone noticed... VST3

[Aleksey Vaneev]

Really? So is VST3 all hype then?

I bet. It does have a couple of things like parameter hierarchy and control surface interaction, but they could be added on top of VST2.4, via a couple of function calls. VST3 is just a new cumbersome framework.

Improved Performance. Instead of always processing input signals, VST3 plug-ins can apply their processing economically and only when it is needed. This is a shit many users will dislike since they won't be able to predict when they run out of CPU resources.

Multiple Dynamic I/Os This was available after introduction of speaker arrangements.

Activating/Deactivating Busses "Bus" is a new terminology in VST, and I can hardly understand its need. It's an overcomplication.

Resizable Edit Windows This was available in previous VST versions.

Sample-accurate automation This COULD be implemented via MIDI events. Beside that automation ramping is a HELL to implement in any average plug-in.

Logical Parameter Organization This is a new element which could be implemented in VST2.4.

Optional VST3 / SKI combination This is an opportunity to create your own host from scratch. Do you really need that? It's easier to switch to Sonar or something else then, than to buy a plug-in that optimizes a couple of things you do not like about Cubase/Nuendo.

VSTXML for Remote Controllers This is a new element which could be implemented in VST2.4.

UTF16 for localized parameter naming This is a wrong approach. English naming is usually mentioned in the User's manual. I can hardly see a need for localized parameter names consisting of 7 letters each.

No MIDI restriction for parameter value transfers This is an overcomplication it seems. Original VST2.4 already offers VstEvents structure that may carry more than just 3 MIDI bytes per event.

Audio Inputs for VST Instruments This could be and is probably already supported in VST2.4.

Multiple MIDI inputs/outputs This theoretically could be implemented via VstEvents structure.

64 Bit processing Already supported in VST2.4.

[aMUSEd]

Of course you do realise that despite your reservations and concerns some dev (maybe with less back catalogue to update) is going to adopt it at some point and when they do that will put the cat amongst the pigeons as they will no doubt use it to leverage a position in the marketplace. How could they not succumb to that little temptation?

[R2Project]

[quote="DaveSonalksis]

Unless someone develops an open source plugin standard - wouldn't that be interesting?

It's looking more and more like a necessity.
[/quote]

We nearly did, but it was killed:

http://en.wikipedia.org/wiki/GMPI

Andy

[aMUSEd]

Improved Performance. Instead of always processing input signals, VST3 plug-ins can apply their processing economically and only when it is needed. This is a shit many users will dislike since they won't be able to predict when they run out of CPU resources.

I don't know. That's something that was always a strong point in Logic.

[DrGonzo]

I am no programming overlord as you guys, but after looking at the spec, I though vst3 sounded like a Quite Good Thing. What's wrong with it?

Other than its implicit requirement that I restructure the code for a long list of shipping plugins, and distribute a whole new set of binaries alongside my current ones, and maintain two sets of sourcecode forever?

Hey, I respect you as a developer and have your code in my music. But is this really an urgent problem?

ATM - C4/N4 are the only hosts that support vst3. There are obviously not a huge point to do any kinds of coding unless at least two or three of the major hosts are using it. Vst3 _is_ backwards compatible with vst2.4 isn't it?

Managing two vst formats side by side is of course a waste of time, but don't you think a better route would be that newer plugs can be developed with vst3? When that time is here that is - and that time is probably far far away...

[arne]

As plug-in developers you may don't see the big picture here. The technical interesting part of VST3 is the controller-processor separation. VST2 is dead end in a future where you have n-core processor systems. Operating systems must change to handle the amount of processors and so will host applications. This will all happen in the next 2 to 5 years, so you all have enough time to plan migrating to VST3. Also another plus of the new SDK is that hosting is simpler. There are not that much things that can be interpreted differently.

arne

[Aleksey Vaneev]

http://en.wikipedia.org/wiki/GMPI

I guess it was just a 'wishlist'. We need an API.

[DaveSonalksis]

Enhanced CPU efficiency: unique silence detection feature automatically switches off the plug-in if no audio signal is being received

This looks like a good feature - presumably only for FX with audio inputs. Ideally the same thing could be applied to instruments. You can actually do this yourself in any case.

Really no.
There's a lot of plugins that can't be "switched off", such as:
1) anything with a free running LFO
2) anything that uses an IIR filter (eqs, reverbs, filters)
3) anything with a delay-line or buffer
4) anything that implements its own internal automation

... I'm sure that leaves something though.

Sample-accurate automation: Parameter changes can now be automated with extreme precision, including supported for 'ramped' data

This is one of the major shortcomings of the current SDK.

Sure, but a good host implementation can handle that.
And you can implement your own interpolation to improve matters in any case.

Resizable editing windows: The new SDK allows dynamic resizing of windows, allowing improved flexibility in the use of valuable screen space

I thought it did this already (kind of). I suppose they mean you can resize the container and have the VST inside it resize itself (if it supports this)

It does.
It's rarely a good thing though - if the container resizes, your UI layout will get broken.... unless you just zoom everything.

New Developer Tools: Designed to enhance the process of engineering VST3 products, VST3 offers a clearly structured, object-oriented C++ interface, an automated testing environment, an advanced preset system, a model test host application, sample source code and much more.

This sounds like a good idea - if these tools are any good that is.

Erm

I haven't looked at the new SDK itself but if they've put some complex "object model" around it then I will be pig sick.

They have. Very seriously and non-negotiably. It means a complete redesign.
Shall I pass the sickbag?

Dave.

[Aleksey Vaneev]

Aleksey - laws are different where you live, aren't they? Is there some way you could develop an open-source plugin standard which happened to be identical to VST2.4?

It can't be a copy&paste version of API. But nobody can stop you creating a 'similar' API in any country.

[Angus_FX]

Arne - I'll rise to the bait:-

What does controller / processor separation at API/ABI level have to do with multiple core CPUs?

[Angus_FX]

First rough analysis...

Total departure from VST2:-

- Based on a COM derivative

- C++ ABI, not C anymore (which is going to make it 'interesting' any time GCC tweaks their C++ ABI, and possibly 'interesting' to get Delphi compatibility working). C++ ABI compatibility is not guaranteed between compilers or even between different versions of the same compiler.

- Heavy on macros. If we're going to have to use C++ for the ABI, and have a design that requires a bunch of metaprogramming, why not use templates?

- It's a BIG interface. Hopefully that won't mean a big breeding ground for bugs , but it will require a lot of attention from the maintainers to prevent that. AU is a big API and suffered hugely from bugs in the first 2-3 years (still does to some extent), and that despite very active management from Apple's devs on the CoreAudio list. Steinberg have not historically put as much resources in to managing their list, hopefully they will budget for enough time for their engineers to do a proper job.

- Model-view-controller architecture implied at API level. Academics love this because it has a certain amount of, shall we say, intellectual elegance; people that have to build non-trivial plug-ins in the real world (and hence see plug-in APIs as a communication pipe between plug and host, not an architecture you want to build your entire code framework around) see it as unwanted interference. It's good for conceptually simple plug-ins like compressors, bad for conceptually complex things.

- Entire API based around virtual inheritance, which means if they want to add any functionality to an interface later, it will need to get reversioned and have a new GUID. What happens to hosts that only know about the old GUID, when they get a plug that's built with an updated SDK? 'C' enumerated dispatchers might be old and unfashionable, but if a host gets a plug with newer functionality, it simply ignores the new features in a safe way.

- Like AU and DXi before it, they've conflated physical port I/O with higher-level 'bus' and 'channel format' semantics. I'm not entirely convinced that's the right way to go - the physical port I/O should be kept simple (as it needs to be efficient and not go wrong!), bus/channel connection semantics are inevitably complicated if you want to support them ("if you connect a 5.1 input on my first input bus, I'm going to allow you to connect these types of thing on a sidechain and those on the output bus") and should be kept well clear of the physical I/O.

- Virtual function call for accessing each event in the event list. Not the end of the world, but hardly the most efficient. Hosts have to provide their own implementation of the IEventList interface.

- Inconsistent use of classes vs structs.. why are events (which obviously stand to benefit from polymorphism) a plain old struct, when I thought everything had gone C++?

- No mention of lockfree containers or other such things that help devs not make mistakes regarding threading.

- Sample accurate automation events... but on a SEPARATE event pipe to the other events. Why oh why?

- Currently supported event types are Note On, Note Off, and SysEx. It's unclear to me from the current SDK how MIDI control messages are sent. There is an enumeration of MIDI controllers, but I cannot currently see how that hooks up to the rest of the SDK. Is this thing even finished for instruments?

[DaveSonalksis]

I am no programming overlord as you guys, but after looking at the spec, I though vst3 sounded like a Quite Good Thing. What's wrong with it?

Other than its implicit requirement that I restructure the code for a long list of shipping plugins, and distribute a whole new set of binaries alongside my current ones, and maintain two sets of sourcecode forever?

Hey, I respect you as a developer and have your code in my music. But is this really an urgent problem?

ATM - C4/N4 are the only hosts that support vst3. There are obviously not a huge point to do any kinds of coding unless at least two or three of the major hosts are using it. Vst3 _is_ backwards compatible with vst2.4 isn't it?

No, it's COMPLETELY incompatible.
VST2.4 and VST3 are from different parts of the universe.

Managing two vst formats side by side is of course a waste of time, but don't you think a better route would be that newer plugs can be developed with vst3? When that time is here that is - and that time is probably far far away...

No, because it stops me selling to users who use a non-VST3 host.

[Aleksey Vaneev]

Vst3 _is_ backwards compatible with vst2.4 isn't it?

It's not. VST3-only host can't easily handle VST2.4 plug-ins.

[duncanparsons]

Dave - I've been reading Spolsky's columns for more years than I care to remember, I'm glad I'm not the only one here who does!

I'm not sure why Steinberg needs to know my DoB and 'phone. Thankfully having a phone number of 000 is acceptable

The communication with host (create tracks, etc) I would actually find quite useful in a project I'm working on right now, as it is I'm going to have to use OS drag and drop (which isn't a problem).

I'm up for an open standard being created. I know it gets bandied about quite often, but it's looking like it is highly desirable. If it could be mapped out to work with VST, then that would be very handy, but than matching opcodes would attract legal problems



I'm in no hurry to use this currnt offering.

DSP

[asseca]

I just had a 10 minute look at VST3.

conclusion:

• This is a complete new plugin standard, which does not even remotely look like the VST2.x standard.
• There is no backward compatibility at all.
• I am NOT looking for a new standard, so I shall avoid this new standard like the plague ...
• Personally I feel Steinberg has left the small developers out in the cold ...