Don't know if anyone noticed... VST3

[arne]

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.

VST3 is not bound to the x86 or x64 architecture. And VST3 has a communication interface between processor and controller.
So it should very well be possible to use VST3 plug-ins with super-computers.

arne

[Rangtangtang]

What happens if someone comes up whith a new computer and operating system from a different angle that is so much better, no-bugs, all the software needed is done, and cheaper......?



---

[Angus_FX]

Hi Arne,

Firstly I should say, my four points are not specifically criticism of VST3, but apply to plug-in APIs in general.

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.

From my reading of the VST mailing list, the design process has not been what I would understand as 'open'.. however maybe we have different understandings of that term. For instance, posting a public alpha or beta of the API specification and inviting public discussion of it would be open. I understand re the business people vs the GPL... sad, is all I can say.

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.

From my first look, the VST3 _SDK_ is broadly OK from this point of view - yes, a 400 line file for the AGain example is a bit worryingly large, and there are other things that could have been hidden in a base class, but that's no big deal, easy to refine later. However, the underlying API looks to be about the same complexity as AU, once you strip out AU's instrument support (as a lot of that - note lists, patch lists etc. - doesn't seem to be present in VST3 - I'm not sure if that is because the instrument side isn't finished yet, or if there is a deliberate design decision to live without all that. If so, it's not explained in the documentation).

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.

OK.. my main criticisms here relating to VST3 would be:-

- the C++ ABI, which mandates people to use certain compilers that can generate code compatible with the host's ABI

- the implied use of model-view-controller at API level, meaning code has to be rewritten _around_ VST3, instead of simply interfaced _to_ VST3 in a single place.

- the use of macros and a COM-like, but not 100% compatible, system, which together can clutter up the code space simply by the fact of including the API headers. It's fine to have this kind of stuff in an SDK (in fact, possibly unavoidable - a lot of people don't understand template syntax, after all), but in an API, it's bad!

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 ?

You did.. it's an API (a plug-in specification) *AND* an SDK (tools for making plug-ins that conform to that specification), and the separation between the two is not clear. Clean separation is vital otherwise you end up forcing all developers to use the SDK in its entirety, which a lot of developers don't want to do!

For instance, in VST1 and VST2, the API was pretty much defined in AEffect.h and AEffectX.h - with one minor modification (moving struct ERect from AEffEditor.hpp to AEffect.h) it was possible to compile working hosts using JUST the API definitions. The SDK was implemented in the .hpp and .cpp files.

Cheers,
Angus.

[asseca]

For instance, in VST1 and VST2, the API was pretty much defined in AEffect.h and AEffectX.h - with one minor modification (moving struct ERect from AEffEditor.hpp to AEffect.h) it was possible to compile working hosts using JUST the API definitions. The SDK was implemented in the .hpp and .cpp files.

This is exactly the beauty of the real low-level API, the whole interface is basically one simple structure EAffect and one pointer to a "listening" host jump-table ...

It is also possible to compile plugins using just AEffect.h and AEffectX.h, I have done this in Delphi, it resulted in a GUI-less plugin of on 24kB in size.

Better still, when you combine AEffect.h and AEffectX.h into a single header file, things suddenly look much more logic ...


Regarding multiple ports in VST2.x: This could be easily implemented by using the reserved midiData[3] of the VstMidiEvent structure

Regarding sample accurate setParameter changes: VST2.3 had the kVstParameterType VstEventType, which could easily be sent via the effProcessEvents.

[arakula]

Regarding multiple ports in VST2.x: This could be easily implemented by using the reserved midiData[3] of the VstMidiEvent structure

Regarding sample accurate setParameter changes: VST2.3 had the kVstParameterType VstEventType, which could easily be sent this via the effProcessEvents.

My thoughts exactly.

What I really, truly, personally hate about this VST 3 SDK is that it isn't compatible with Visual Studio 6 any more.

[Ben [Camel Audio]]

Someone please make all this go away.

To illuminate the mistake made here, please first enlighten yourself to the writings of Joel Spolsky (joelonsoftware.com). Once you're in touch with the fact that his word is close enough gospel, read this:
http://joelonsoftware.com/articles/fog0000000069.html

Totally agree about Spolsky being practically gospel and also agree that that article is spot on. I've learnt by bitter experience just how true the above article is. The other thing I've learnt is that everything should be designed to be as simple as it can possibly be, and that some of the complex things that I was taught about programming methodoly at university, don't actually make sense in the real world.

I haven't even looked at the VST3 SDK yet, but is it really unwrappable? It sounds like Angus point about the use of model-view-controller at API level is the main problem. Anyone have any ideas on how a GUI built around the VSTGUI might most easily be transitioned to work under VST3?

Ben

[BazzaTron]

What I really, truly, personally hate about this VST 3 SDK is that it isn't compatible with Visual Studio 6 any more.

Please tell me this isn't true.

[aMUSEd]

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?

Well, these aren't my ideas, but they do bear repeating:
1) Move VST to an open-source licence - VSTGUI already is. It would be great to be able to open-source plugins.
2) Patch the 2.4 sdk to incorporate trivial fixes for the issues that we really do have. For instance, adding sidechains to 2.4 could be implemented in three lines of code.

To illuminate the mistake made here, please first enlighten yourself to the writings of Joel Spolsky (joelonsoftware.com). Once you're in touch with the fact that his word is close enough gospel, read this:

http://joelonsoftware.com/articles/fog0000000069.html

Dave.

Very good. How I wish Jorgen had read this before rewriting Energy XT (or NI when they brought out KORE 2). If it ain't broke....

[duncanparsons]

they've been listening to vurt: If it ain't broke, break it...

DSP

[Aleksey Vaneev]

http://joelonsoftware.com/articles/fog0000000069.html

Totally agree about Spolsky being practically gospel and also agree that that article is spot on.

I do not totally agree here (actually, you can't be competitive with an old code base - think first Voxengo plug-ins were made in Delphi, now I have 'hardcore' C++ code, ready to be ported anywhere).

VST3 is probably a well thought-out project which included system refactoring, not just a rewrite. The problem we have is that plug-in developers (and most host developers I believe) DO NOT need it in its presented form. It's called "bear service" here in Russia, or "a way to hell is made of good intentions" (meaning good intentions without discussion).

[stefancrs]

Very good. How I wish Jorgen had read this before rewriting Energy XT (or NI when they brought out KORE 2). If it ain't broke....

While I wholeheartedly agree with the article, I don't think it's completely fair to apply that view upon what Jorgen did. As it would seem to me, it wasn't mainly a complete rewrite, it was mainly a change of programming language, and there's a huge difference in the reasoning behind it.

There actually are cases when complete or close-to-complete rewrites can be justified. The VST case is not one of those, imo.

I do hope however that good will come out of all this, and who knows, maybe it will?

From my perspective, even VST 1.x and 2.x are unnecessarily complex. A good audio and event plugin API could be reduced to almost nothing, could it not? Without sacrificing functionality and extendability, no?

[stefancrs]

Aleksy, wtf, it's called the same here! Didn't expect that. What is the Russian word for it? The Swedish is "björntjänst", where björn of course is bear and tjänst is service.

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

From my reading of the VST mailing list, the design process has not been what I would understand as 'open'.. however maybe we have different understandings of that term. For instance, posting a public alpha or beta of the API specification and inviting public discussion of it would be open. I understand re the business people vs the GPL... sad, is all I can say.

No, we don't have different understanding of 'open'. In a perfect world this would be possible. Market economy forces such processes and I'm not a friend of that.

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.

From my first look, the VST3 _SDK_ is broadly OK from this point of view - yes, a 400 line file for the AGain example is a bit worryingly large, and there are other things that could have been hidden in a base class, but that's no big deal, easy to refine later. However, the underlying API looks to be about the same complexity as AU, once you strip out AU's instrument support (as a lot of that - note lists, patch lists etc. - doesn't seem to be present in VST3 - I'm not sure if that is because the instrument side isn't finished yet, or if there is a deliberate design decision to live without all that. If so, it's not explained in the documentation).

It's present in VST3, but yes, the documentation in that part is not where we wanted it to be. I hope that Steinberg will give us time in the coming month to work out documentation issues in the SDK.
But I don't agree that if you strip the SDK classes that the API is as complex as the AU API.

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.

OK.. my main criticisms here relating to VST3 would be:-

- the C++ ABI, which mandates people to use certain compilers that can generate code compatible with the host's ABI

- the implied use of model-view-controller at API level, meaning code has to be rewritten _around_ VST3, instead of simply interfaced _to_ VST3 in a single place.

- the use of macros and a COM-like, but not 100% compatible, system, which together can clutter up the code space simply by the fact of including the API headers. It's fine to have this kind of stuff in an SDK (in fact, possibly unavoidable - a lot of people don't understand template syntax, after all), but in an API, it's bad!

Noted. The first and the third part is mostly not avoidable if you want to have an API that is flexible. But I wasn't the one who wanted it that way in the first place. An opcode based system has advantages in supporting different languages very easy. But this has no high priority in an API. Wrapping COM or COM-like interfaces to other languages is possible after all.
The model-view-controller at API level is discussable, but from what I see in possibilities this design gives the host is cool. Some ideas I have for a host won't be possible if this separation isn't done at that level. It would at least be very hard and cumbersome to implement.

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 ?

You did.. it's an API (a plug-in specification) *AND* an SDK (tools for making plug-ins that conform to that specification), and the separation between the two is not clear. Clean separation is vital otherwise you end up forcing all developers to use the SDK in its entirety, which a lot of developers don't want to do!

For instance, in VST1 and VST2, the API was pretty much defined in AEffect.h and AEffectX.h - with one minor modification (moving struct ERect from AEffEditor.hpp to AEffect.h) it was possible to compile working hosts using JUST the API definitions. The SDK was implemented in the .hpp and .cpp files.

But that is true for VST3 too. The API is in the pluginterface folder while the SDK is in public.sdk. You don't need to use the stuff in public.sdk folder. I did this already for something I will hopefully announce in a few weeks.

arne

[WilliamK]

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.

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.

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)

I already did something on my code that makes our VST goes into IDLE mode when nothing is happening. CPU usage drops to near 0% when it does. Also, what's up with the resizable thingy? Doesn't all hosts support that already? Of course, like you said, maybe you can resize the outer window and the VST resizes itself. But to be honest, no way I would use that.

I don't see any advantages of going into VST3 for us right now.

Wk

[Aleksey Vaneev]

Aleksy, wtf, it's called the same here! Didn't expect that. What is the Russian word for it? The Swedish is "björntjänst", where björn of course is bear and tjänst is service.

It's "medvezhia usluga" in Russian.