Just a question to FXpansion I hate installing VST anything as I am an AU purist and wondered if you will come out with A pure AU version not a wrapped VST to AU version?

Thanks

Never. The whole concept of a 'pure AU' is completely, utterly bogus and without merit.

If you're prepared to read a long post about abstraction, class hierarchies and dynamic linking, I'll gladly elaborate.. if not, please take my word for it as - and I don't mean to be rude here - but if you don't understand the above, it makes no more sense for you to hold an opinion about it than it would for me to hold an opinion about what kind of material Boeing should make their jets out of.

Best regards,
Angus.

Heheheh. "Rar!"

But seriously, I wouldn't mind seeing your explanation about it. Not in a roast-your-nuts kind of way, but more as a fellow programmer who's a touch curious.

Agreed I am ready to hear the explanation and I am ready to read a big post on abstraction I guess my thing is Everyone else has the OPTION of installing AU or VST why does'nt BFD? Why do we NEED to install both. Also,
do you not think Apple will write better option for an AU plug-in I.E. resolution independence in leopard or whatever for that standard? I personally think that they will but then again I am NOT a developer so I dunno.
But Angus I totally respect you I feel you should know that.

Thanks.

Simply: 99.9% of code in a VST or AU plugin has nothing to do with either specification, but is completely internal to the plugin. Both formats have a small number of interactions between host and plugin - "the sample rate is..." ,"change parameter X to value Y" and "Make me some audio, minion!". The two specifications call these interactions slightly different names, but at the end of the day, they are basically the same. The plugin author will be translating BOTH specifications into their own internal synth or effect's workings, so what the two specifications call any one operation is largely neither here nor there.

Plugin manufacturers putting out "native AU" (or VST, RTAS etc) plugins will simply be doing a "wrap" internally to their own plugin's workings. Some (Waves, Native Instruments, TC) have developed their own; others license ours (some talk about it, others do not) or others.

By separating the AU abstraction layer from our "native" VST plugins (which all translate VST into their own internal functions anyway), we can build stable AU components that do not need updating when the rest of the code changes - nor does the core plugin need to be updated when Apple "revises" the AU spec for the umpteenth time - a modular approach to keep the busiwork down. It also means we don't need to duplicate the core plugin code (which is many, many times larger) in AU, RTAS and VST versions.

With something like BFD already requiring 12 builds of the core plugin ((stereo, groups, all, ultra) x (Win, MacOSX10.2.8, MacOSX10.4 unibin)), just doing the core "VST" components is enough work already - knowing that the wrappers are there to take care of DXi, RTAS, Rewire and AU is a great relief.

There are probably 4 too many plugin formats in the market now. Each does have something to add to the technology mix, but some kind of rationalization is really long overdue. Whilst we have a running joke in the FX office that "anytime a major music software company wants to come up with a new plugin format, its fine by us - more adapters!", the truth is we all lose out in terms of less interoperability, a fragmented technology market especially at the sometimes highly innovative low budget developer end (not many bedroom developers making free RTAS plugins...?), and multi-format busiwork.

Currently, we at FX feel (quite strongly) that VST provides the most "bang for buck" (most features for least squirrelling about) for the sort of plugins we write*, and will remain our "first" format until something better comes along. This isn't out of any VST loyality (notice we aren't leaping to develop VST2.4, urgh), but because VST gives us the superset of features we need.

Nobody is claiming VST is perfect - it has some glaring design flaws and some more subtle ones. But in terms of fitness for purpose it is simply streets ahead of AU, RTAS or DXi.

* One particular thing you can all help us campaign for in certain plugin formats: MIDI Out!
Last edited by SKoT_FX on Wed Jul 26, 2006 12:44 am; edited 3 times in total

finally!! somebody said it. now go everybody, put these words in a nice little frame above your beds. and everytime you go to sleep, remember: it's all in your mind.

Make the campaign for multi-port midi out SKoT and I'll not only join, I'll paint the placards.

After sending numerous e-mails to Apple about the 32 outputs for AU, I think we could push them to implement midi out for AU and also midi in, so we could use Jamstix on a Mac in the future (when it gets ported, hopefully).

Hi SKoT

I really enjoyed your description of the lie of the land here; could I pester you for a little more information here please? It really helps to understand how these things all fit together!

What is it that VST lacks, and what do the others lack that VST includes? And where, say, VST lacks a feature that the others have, does this mean that your plug-ins do not support this feature on other formats?

Many thanks,

I defer to Angus's more intimate knowledge of the non-VST specs, I see he has been raising the temperature on some of my text with edits, so he clearly has an agenda to push here... (eg "glaring" wasn't in text v1.0, hee hee)

I'll only compare VST and AU in depth here.

RTAS is under NDA, and in any case not intended as a plugin format for hosts other than Digidesign's own and DAE apps to use. As it is not generally legal (never mind technically problematic) for a developer to write an RTAS host, that also rules it out as a core development-base API.

DXi is effectively obsolete, its main flaws were a large and vastly over-complex audio streaming interface (inherited from MS DirectShow) and a moderately over-complex MIDI streaming interface derived from Cakewalk's MFX API (which is/was a reasonably good API for doing heavily look-ahead, musical time oriented MIDI processing, but not well suited to realtime synthesis).
Also, being based on top of COM and DirectShow, it couldn't readily be ported to the Mac; a good development-base plugin API needs to be portable.

So that leaves VST and AU. There's plenty of brain-dead stuff in VST..

- the whole concept of having multiple states (aka programs) in a plugin. There is just no reason for the way this is designed in VST. Plugin developers are free to ignore it (support only a single state) but hosts must account for it, which is a real bore.

- the method for uniquely identifying plugins is not clearly documented (although most developers have found hacks that work adequately).

- VST 2.4 is a disaster, on the Mac platform in particular. Whoever came up with the 2.4 amendments (a different team to the original developers of VST, I think) did not take proper account of backwards-compatibility, and made some short-sighted and incorrect decisions.

- VST has rather poor handling of connection semantics. This is actually a hard problem to get right (no format has really aced it, to my knowledge), but the simple and common cases should be handled better and more clearly.

- Some aspects of the call sequence are less-than-ideally documented, the spec is not adequately policed, there is no validation tool, and, basically, Steinberg/Yamaha just does not dedicate adequate resources to maintaining it. Worse than that, they have a tendency to add functions because they wanted it for a particular plugin or host, rather than deciding if it's actually the best way for the good of the API or the larger development community.

- There is some cruft and ugliness left over from the early days in the SDK (arbitrary use of direct function calls vs dispatcher; various bits of API that were never implemented etc.; "VST-Carbon" hangover and the old style GUI event dispatcher on Mac hung over from OS 9), part of 2.4 was intended to address that but they broke it so badly in other respects that, well, it's a futile effort IMHO.

- The event format is MIDI. MIDI has had a good run, but it has some pretty severe known limitations (very limited, arbitrary and weakly standardized controller space, else resort to hacky NRPNs; many messages imply state change which should be conveyed only via the plugin API). A well defined sub set of OSC or similar would likely be a much better choice for a plugin API these days (MIDI->OSC is easy to do in the host).

- Event data (aka MIDI in this case) and parameter change data are non-orthogonal, second class citizens next to audio. You can have arbitrary numbers of named, sample-accurate audio in and out ports, why not the same for event and automation ports? Automation in VST is only block accurate, and the threading model for it is unclear.

- Parameter-value to string and string to parameter-value translation is a bit of a pain - it's not possible to do this without setting the param to the value you want to translate. This creates some minor user experience issues when working with automation editors. AU handles this better.

- There's no support for migration of persistency or automation data between major versions of, or subtypes of, a plugin. AU handles this rather better, but if you have your own built in patch management, it's largely a non-issue anyway.

- There's little or no support for internationalization.

- There are some nasty gotchas and corner cases in the processing functions which have to be taken in to account and which slow everything down. EG, weak specification as to whether buffer pointers can point to the same buffer; no specification of FPU state at plugin entry meaning plugins that care (rounding control, precision!) have to set & restore the FPU state on every process.

To sum up.. VST has its problems, but it's nothing that couldn't be fixed with a clean slate (VST3) and a thorough understanding of the issues involved (unfortunately even a lot of experienced developers don't understand some aspects all that well ). By and large, VST's problems are not fundamental deep design flaws, but hangovers from earlier days when the plugin dev world was smaller, expectations were lower, and not all of the problems had even been encountered.

On to AU:-

- It only works on OS X. Although in theory it'd be possible to port it to Windows and use it as a core platform, it'd make about as much sense as porting DXi to the Mac.

- It's dependent on rather a large set of classes to even compile.

- Because it's tied to the OS X SDK, it tends to be the case (although it can be avoided) that if you want to support the newest features in AU, you have to target the newest versions of OS X. People with older OSes are left out in the cold. There are ways around this, but they don't seem to be officially supported or recommended.

- From a cultural point of view, I'm really not sure how well Apple's team has understood the situation of plugin developers. While their active stewardship looks good compared to Steinberg's handling of the VST SDK, there's a bit of an Apple-wide assumption that developers have the time spare to update all their products every few months to accomodate the constant tweaks and revisions (and that customers will want to run the latest OS). That sort of thing has caused quite some resentment among the developer community. Most plugins from a Win98 PC will still work today, and most plugins written on a modern XP SP2 PC will equally run on the old Win98 box. On a Mac, something built two years ago probably won't even install properly.

- Again, parameter changes and event data are second class citizens, there is only a single event input port (no event output port at all!) and parameters are not sample accurate (at least last time I checked).

- Again, the event data protocol is pure 100% MIDI, with all of the limitations and complications that implies.

- Again, connection semantics are a bit of a mess... Apple have put a lot more work in to *trying* to solve the problem, but I'm not sure how much more succesful it is.. really you just want a good enumerated API for the simple cases (MM, MS, SS; paired and unpaired output ports for synths) and a good UI in the host for everything else -- no point in creating a whole lot of API complexity for surround support, as 95% of plugin processing (on the 5% of systems where surround work is being done) is done *before* surround placement in the mix.

- The preset/persistency support APIs are better than VST, but the system for providing factory presets is still fugly. What's wrong with using the file system and a properly specified file format, for crying out loud?

- The API has grown worryingly large, while large parts are still unimplemented or under-implemented by plugins and hosts. It's hard to say how well plugins that make heavy use of some of AU's cleverer and supposedly more elegant features will actually hold up.

- The Component Manager, atop which AU sits, has some horrible cruft surviving from OS 9 (resource forks, four-CC type identifiers), I just don't understand why they used this at all when they have the nice, modern CFBundle APIs and info.plist files.

- The idea of exposing real world values at machine level on the automation ports was a really bizarre and not terribly useful decision. Yes, users should see real world values, but normalized floats have major advantages for host<->plug parameter automation control (allows plugins to support arbitrary range curves, for a start)

- The host callback mechanism is grafted on and hacky, and has nasty bugs or nearly-bugs in some hosts (DP especially). VST's host callback mechanism is more thorough and better supported.

- The windowing and GUI event dispatch mechanism (based on Apple's View classes) is a huge breeding ground for bugs, it creates far too much interface exposure between the host and plug. Microsoft's approach to this (every pane is a fully qualified window) creates far fewer problems, as does VST's prior to 2.4 (the plugin's view is a full window on both platforms). There's no real difference from a host development point of view as to whether the plugs use windows or views, but from a plugin development point of view owning your window makes development ever so much easier.

- AU Validation, whilst a noble idea in theory, has been badly implemented from a political/user-experience/marketing/honesty point of view in practice. It will fail plugins and give dire warnings over some very minor oversights on the plugin developer's part, but is unable to pick up potentially more serious problems and gives users a false sense of security about plugins that pass. It's really a pretty weak guide as to whether a plugin is buggy or not, but is presented to the user as if it were something much more trustworthy.

- The recommended mechanism for AU GUI support (a completely indepdenent process and view) is a nice idea in theory, but a million miles from practical and commercial reality for many developers. "Nice in theory" is roughly equivalent to "A one legged man at a football match" when you're talking about a real world API.

- The dispatcher mechanism is somewhat obfuscated via a template class. In VST, it's plain as day.

- The documentation is better than VST, but large parts are still very inadequate - even to the extent of not documenting what units certain properties are expressed in. Multithreading is badly underdocumented, but the same is true in VST.

...right, I'm detatching the tractor from the agenda wheelbarrow for a bit, it needs a service and quite frankly, a little rest. This should be a fun thread.

Wow. =O.o= I owe you guys for a quick and not-too-dirty education.

And I'd wear the Teeshirt...If it came in my size

You know, this is probably way left-field, but has anyone in the professional developer realm ever spent serious time thinking about this functionality in the world of JAVA? I mean, its multi-platform compatibility is quite easy, for the most part, and from my experience with it it's fairly straightforward. Like instead of every one and their mother having their own plug-in format, go the Steinberg route and make a universal format, implemented in the form of JAVA. I realize it would take some time to really kick off, but would that not be a lucrative approach even simply by the fact of its universal capability?

The thought has even danced in my mind about using JAVA to run say Windows-only or Mac-only plugins on their respective counterparts, through a sort of translator approach with JAVA as a host framework. Would this be far beyond the realm of possibility?

*edit: When I said go the Steinberg route, I meant *take the initiative and make a plugin format* but then have it be universal
Last edited by Chris Roberson on Wed Jul 26, 2006 8:07 am; edited 1 time in total