Don't know if anyone noticed... VST3

[DaveSonalksis]

If we were to draft an alternative specification, I'd like to suggest that it works in such a way that the resulting plugin can easily be wrapped to VST2.4/AU/RTAS (all of which work in roughly the same way). VST3 is such a remarkable bastion of weirdness that I don't know what to think just yet.
What I do know is that in 2.4 you can code a gain plugin in about 2 pages of code.
The current sample is 62k of source. For a gain plugin. Nuts.

[For your reference, the TOTAL code for FreeG (which is heavily graphical, and has a few tweaks) is 64k, including blitter graphics libraries, etc...]

Sadly, the largest difficulty with getting any acceptance for a plugin standard is host support. So, instead, lets look for the back-route - open sourced wrappers which drop into a plugin, and turn something into the appropriate format. In the end, that leaves a reasonable chance that a host might want to incorporate support, but the safe-route that the plugins will work great with hosts that dont. With that setup, you just wait for a few killer plugs to come along which offer features only in the new spec, and then eventually the hosts will be obligated to follow.

Meh.

[DaveSonalksis]

GMPI just needed a better acronym. GMPI sounds a bit silly. VST and AU roll off the tongue so well. Vs, Us and Xs are always good. I propose the new UVX plugin standard.
Doesn't stand for anything, but we all know what it means, and it sounds good

[Aleksey Vaneev]

Personally I feel Steinberg has left the small developers out in the cold ...

It's probably too strong to say that - just scratch your head for a day and you are done. What is wrong about this SDK is that it is TOTALLY new, and is based on COM which is a NO-NO for a good multi-platform API.

[Angus_FX]

I suppose a better question would be - where would you (as devs) like to see the plugin standard going? I can't believe you would want things to just stand still forever?

That's actually a very important point.

Firstly, a plug-in API standard needs to be open. That means dropping the business dogma that is locking the GPL guys out - even if you don't agree with the GPL philosophy, locking them out of the standard is just mean-minded and petty. It also means that the design process should be open and transparent. That does not necessarily mean democratic, but it does mean that anybody can see the history and thoughts behind specific design decisions.

Secondly, a plug-in API standard needs to take in to account the nature of our industry. We have tens of host vendors, and hundreds or thousands of plug-in vendors. 80% of the plug-in developers don't really know how to program, and 80% of the rest don't have big enough budgets to do quality assurance properly. That's fine - the result is that there are lots of cheap/free/interesting/innovative/wacky tools around. But it means any API we adopt has to be SIMPLE. Not just "not too complicated", but AS SIMPLE A DESIGN AS CAN POSSIBLY GET THE JOB DONE. Anything else is just a breeding ground for bugs.

Thirdly, a plug-in API standard needs to respect the integrity of the host's code, and the plug-in's code, and stay out of the way. We all need to support multiple architectures, and no one vendor can know or assume what 3rd party components another vendor might need to use, or what architectural constraints they might have. A plug-in API is there to be a communication pipe between two different code worlds, and should not make any assumptions about the structure of either, beyond their implied ability to fulfil the 'contract' specified by the API.

Fourthly, a plug-in API standard needs to not be an SDK. An API (application programming interface) is the interface by which the plug-in and host communicate. An SDK (software development kit) is a set of code and tools to make it easy for devs to build plug-ins or hosts that implement a particular API. You can have more than one SDK for the same API, or indeed you can have an SDK that supports multiple APIs. Broadly speaking, an SDK will contain a lot more code than an API, various helper classes to make the plug-in developer's life easier; however, using an SDK to implement a particular API should always be optional - it should be possible (indeed, trivial if we are talking about an experienced dev working with a straightforward API) to implement the API without reference to any SDK.

Getting those four things right is actually FAR MORE important than any specific technical decision.. indeed, if you can get those four right, the technical stuff follows fairly easily!

Cheers,
Angus.

[DaveSonalksis]

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 ...

I agree.

In fact, if I may be more bold on your last point...
I don't believe that Steinberg understands what VST actually represents in the real world.

With VST - their badly designed, trivial plugin format, they created a VAST community of developers, who jumped in to this small, easy API, and built tens of thousands of plugins. Amazingly, the lack of design and simplicity turned out to be a miraculously huge advantage.

VST represents the largest community of audio developers in the world, by a huge margin - perhaps 10:1.

VST users have an incredible arsenal of plugins at their disposal.

By destroying VST2.4, they have begun the process of destroying that community, which will stand no chance of porting to VST3 - in fact, they're unlikely to even feel motivated to try.

I see this as a terrible shame.

Of course, I do see the business side of it - Steinberg aren't so financially interested in the little people (or at least haven't realised that they really ought to be), and want to build a new system to carry themselves forward for a few more years. But they've still made the #1 mistake (starting from scratch).

As a poor analogy, if Steinberg was a bird, all the developers represent small bubbles of turbulence under its wings. By sending them elsewhere, they will lose altitude quickly.

[arne]

Arne - I'll rise to the bait:-

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

It's hard to predict anything for the future, but after profiling and debugging 8 core systems, I think that regarding to low latency current operating systems are already at a dead end. And I don't think that these problems will be solved only by hardware. Think of it as a distributed system today where the connection is done via ethernet. These technics may be the way to go in the future in a single system where you may don't have access to all cores in a single process.

arne

[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?

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

Ahh. Got the problem now. Shit...

[Angus_FX]

It's hard to predict anything for the future, but after profiling and debugging 8 core systems, I think that regarding to low latency current operating systems are already at a dead end. And I don't think that these problems will be solved only by hardware. Think of it as a distributed system today where the connection is done via ethernet. These technics may be the way to go in the future in a single system where you may don't have access to all cores in a single process.

I agree with you there - however, mandating model/view/controller at API level is IMHO not the way to go - host-mediated RFB (remote framebuffer) is *so* much safer.

Going off at a bit of a tangent.. if we are talking multi-core systems and 3-5 years in the future, why are we talking about running plug-ins in-process at all? Shouldn't a latency-agnostic, multi-core friendly plug-in API of the future be spec'ed up as a full IPC architecture, so we can get back the advantages of protected memory (remember that? it were nice!) and not having to worry about the state of process-global OS resources?

[whyterabbyt]

So... a VST2.4->VST3 wrapper by Angus, and everyone else sticks with the old standard, then?


But seriously, on a first glance Im not seeing a great deal of technical advantages over 2.4, despite what Steinberg tout as 'new'. Anything noticable as a 'thank god this finally happened' feature? (and no, the additional proprietary host-molesting API doesnt count.)

[Aleksey Vaneev]

Think of it as a distributed system today where the connection is done via ethernet.

There are better general ways exist to spread any kind of processing over any number of abstract processors, even allowing one to run a plug-in on a super-computer. Hence you do not have to divide UI and audio code of a plug-in strictly as AudioUnit API suggests. It's a matter of design considerations, and the AU and VST could leave things as they are, because their approach still does not allow to run a plug-in on a super-computer: it's a half-way solution if we consider a scalable computing.

[arne]

Going off at a bit of a tangent.. if we are talking multi-core systems and 3-5 years in the future, why are we talking about running plug-ins in-process at all? Shouldn't a latency-agnostic, multi-core friendly plug-in API of the future be spec'ed up as a full IPC architecture, so we can get back the advantages of protected memory (remember that? it were nice!) and not having to worry about the state of process-global OS resources?

Yes, this is another workable approach, but you forget the UI aspect of it. If you have all plug-ins in separate processes you also have the UI there. If I'm thinking about MS Windows in this case I get a big headache from a users viewpoint.

arne

[arne]

There are better general ways exist to spread any kind of processing over any number of abstract processors, even allowing one to run a plug-in on a super-computer. Hence you do not have to divide UI and audio code of a plug-in strictly as AudioUnit API suggests. It's a matter of design considerations, and the AU and VST could leave things as they are, because their approach still does not allow to run a plug-in on a super-computer: it's a half-way solution if we consider a scalable computing.

Can you describe why the VST3/AU approach doesn't work on a super-computer ?

arne

[Aleksey Vaneev]

Can you describe why the VST3/AU approach doesn't work on a super-computer ?

Because super-computers may not have an x86 or x64 architecture, each core of a super-computer may have access to several megabytes of memory only, or processors may require additional communication as they all are working in different address spaces. You just can't load ANY AudioUnit or VST plug-in. So, even separating view from DSP part won't help there.

[arne]

Firstly, a plug-in API standard needs to be open. That means dropping the business dogma that is locking the GPL guys out - even if you don't agree with the GPL philosophy, locking them out of the standard is just mean-minded and petty. It also means that the design process should be open and transparent. That does not necessarily mean democratic, but it does mean that anybody can see the history and thoughts behind specific design decisions.

Yes I agree here. As an engineer this is obvious but business people living on the other side of the moon then we do.

Secondly, a plug-in API standard needs to take in to account the nature of our industry. We have tens of host vendors, and hundreds or thousands of plug-in vendors. 80% of the plug-in developers don't really know how to program, and 80% of the rest don't have big enough budgets to do quality assurance properly. That's fine - the result is that there are lots of cheap/free/interesting/innovative/wacky tools around. But it means any API we adopt has to be SIMPLE. Not just "not too complicated", but AS SIMPLE A DESIGN AS CAN POSSIBLY GET THE JOB DONE. Anything else is just a breeding ground for bugs.

Yes, I also agree. And I think that VST3 is much simpler to understand than AU. Sure the first step is harder than VST2 but I think if this step is done it's actually easy to understand.

Thirdly, a plug-in API standard needs to respect the integrity of the host's code, and the plug-in's code, and stay out of the way. We all need to support multiple architectures, and no one vendor can know or assume what 3rd party components another vendor might need to use, or what architectural constraints they might have. A plug-in API is there to be a communication pipe between two different code worlds, and should not make any assumptions about the structure of either, beyond their implied ability to fulfil the 'contract' specified by the API.

I'm not sure I understand you here. Can you elaborate a little bit more.

Fourthly, a plug-in API standard needs to not be an SDK. An API (application programming interface) is the interface by which the plug-in and host communicate. An SDK (software development kit) is a set of code and tools to make it easy for devs to build plug-ins or hosts that implement a particular API. You can have more than one SDK for the same API, or indeed you can have an SDK that supports multiple APIs. Broadly speaking, an SDK will contain a lot more code than an API, various helper classes to make the plug-in developer's life easier; however, using an SDK to implement a particular API should always be optional - it should be possible (indeed, trivial if we are talking about an experienced dev working with a straightforward API) to implement the API without reference to any SDK.

Sure, VST3 is an SDK, or did I miss something ?

Getting those four things right is actually FAR MORE important than any specific technical decision.. indeed, if you can get those four right, the technical stuff follows fairly easily!

Yes, I think that VST3 is much better in this four categories than VST2.

arne

[duncanparsons]

GMPI just needed a better acronym. GMPI sounds a bit silly. VST and AU roll off the tongue so well. Vs, Us and Xs are always good. I propose the new UVX plugin standard.
Doesn't stand for anything, but we all know what it means, and it sounds good

sadly it's taken

VUX gone too

that's not saying they couldn't be used.

Altho' Unified Audio eXtension might be OK (only a few takers)



Lets' get a spec first, then talk to the indie host devs to get an implementation out!

DSP