Thanks Urs for your very detailed and straight to the point response! I understand now alot more clearly. Your understandable frustration with VST2 comes across in this post - vst2 on mac sounds like a pain in the ass for developers.Urs wrote:Well, in AU we can put multiple plugins into a single component file. I don't see this done very often, but it makes a lot of sense. We can easily share code, resources (images etc.) among multiple instances of different plugins. This is also possible in RTAS, AAX and VST3.
In VST2 this is doable via the shell API. This is however not supported in any host as far as we know, because a certain manufacturer of shell-based VSTs has done it, uhm, in such an exotic way that host manufacturers have only bothered with their way. That's what I heard from several host developers.
So what we do is, we deliver a single VST2 once per bundle and our installer makes exact copies of the binary for each plugin that's normally contained within a shell. This works well, but on Mac we additionally have to patch each single copy to tell it what it actually is (yep, we simply alter the binary after delivery, works like charme)
Now, in future we need to do "code signing" or the stuff won't run on a Mac by default. Thus we can't patch binaries during installation anymore. We'll have to deliver the full throttle 100MB+ downloads with individually signed VSTs.
That's doable, but there's another issue. 64-bit processing on Mac requires the use of Cocoa classes. Those are prone to so called name collisions. In order to avoid name collisions in our framework, we have to do single projects and single compilations for each single VST. And that just totally freaks me out. So, no 64-bit means all Carbon and no such hassle.
Other than that, well, AU has loads of advantages for us. One example: Parameters are not normalised. If we e.g. made a parameter like "Chorus mode" available for automation with, say, 3 states and later on we add a 4th mode, the automation will still be fine in AU, but it'll be f**ked up in VST. This is why we don't make those parameters automatable. I found it a hilarious move to keep parameters normalised in VST3. Facepalm from my side.
Next, VST2 does not have a definition for inputs on instruments, even though nothing speaks against it. We didn't do it in the past because some old hosts can't handle it. AU, RTAS, VST3, AAX, RE have clearly defined input and side chaining behaviour that VST2 completely lacks for instruments. We will disregard this flaw in future and simply add input handling, but we will not advertise this as a feature in VST2 because many hosts don't handle it.
Next. Program Banks. Useless concept for us. Good for small synths, but not for anything in the realm of Zebra.
Ok. VST has a defined MIDI out. CoreMIDI lets you do any number of virtual MIDI outs in an AU that can be routed into any MIDI device on the machine, not just the next plugin. So, hmmm, I don't see why there's a big problem, but then, we haven't done that yet.
Nevertheless, the bundle issue, the code signing issue and the Cocoa name collision hassle are what make me want to drop VST2 support on Mac as soon as possible. It'll take years, but it'll eventually happen. (Note, non of these issues pose a problem on Windows)
So do you think there will ever be a holy grail of a type of plugin which has cross platform compatibility and adequate features for future development of plugins (that adequately accommodates the various imaginations of you intrepid developer types
)? Do you think the industry needs a bit of a shake up and would have a huge list of desires for the "perfect" plugin type?I suppose with the 3 main OS, to bridge the linux gap a "perfect" plugin type would by necessity have to be open source. Whether this would ever be possible without the commercial weight behind it of a major DAW developer is probably up in the air.
, but there's a case that AU isn't just pointlessly reinventing the VST wheel. I certainly assumed it was for a long time, and I guess for users and many developers it's somewhat pointless in practice 
)
