This is from a huge thread on osxaudio.com
Why is AU better than VST?
GUIs:
The GUI stuff is thoroughly defined and sanely designed in AU. In VST, there's a lot of completely ambiguous or undefined stuff. Handling of mouse clicks, what happens while the mouse drags, keyboard events, keyboard focus, etc. is all a mess. The most obvious fallout of this is that, if the plugin wants keyboard events, they just don't work right in most hosts (there are no fewer than 3, yes 3, ways to do keyboard input for VST plugins, with none of them documented, and vastly unsupported). Or text edit boxes crash in some hosts because the behavior for keyboard focus was never defined. Host GUIs freeze when you drag your mouse. Also, a really basic thing, but VST didn't define a way to say to a plugin, "hey, I actually want you to draw your GUI at this position in the window, rather than right in the top left." As a consequence, tons of hacks in plugins and hosts have made this mostly work okay, thought there are always new problems it seems. In AU, all of this stuff is defined and there are ways to do things right. Here's one example: keyboard navigation for SFX Machine RT works in every single AU host, no problems. But the VST version only works in like 2 hosts out there. Oh yeah, and just to add one more thing, AU allows a plugin to specify more than one custom GUI for an AU. This unfortunately still belongs in the category of no-one-has-taken-advantage-of-this-yet, but it's still a good thing. It means that there is a straight-forward system for presenting the user with multiple skins, expert and simple modes, different sections of the GUI, etc.
multiple i/o configurations:
This is just so basic and VST always frustrated me with this, but in VST, there's no way for a plugin to say "I can do stereo and I can do surround" or "I can do mono or stereo" or "I can do any number of channels, just tell me what you want." AU can. There are several problems that come along with this severe shortcoming of VST's. Well, basically the result of this problem is that most developers simply release plugins that present themselves as handling 2-in and 2-out. You can then do this stupid VST hack thing (canMono) that says, "well, if you want, I can do mono input also, but ummm, not really, you just have to fake it and make it look like stereo to me by doubling the input signal," if you want, but that's really just meaningless anyway. So what you get as a result of this is plugins that, when processing "mono", actually do everything in stereo and spit out stereo in the end. In most cases, this means that the plugin is using twice as much CPU to do the work and almost twice as much memory. This can vary, but that's a general tendency. I for one do a lot of tracks recorded in mono when I do multitrack recordings, and I for one sometimes run out of CPU power with plugins (I think I'm not the only one who does, either), and so I have always frickin hated that VST was so stupid in this respect. Most of the time, you're just throwing away half of your CPU resources. Then on the other side of things, what about when you want to do surround or other multichannel output? You'll find that virtually no VST effects can do this. Now technically, the vast majority of effects could do it, but it's stupid VST preventing them from providing this functionality. So that's it, dead in the water, no chance for surround processing with VST plugins in 99.9% of cases. With AU, however, a plugin can specify any number of input/output counts that it can support. It just provides a list to the host. Or, if it doesn't provide a list, then the host assumes that the plugin can do any number of channels, as long as the number of inputs equals the number of outputs. And for most effects, this is entirely feasable. Sometimes an effect really only makes sense as stereo or mono-in/stereo-out or surround whatever, something specific, but in the vast majority of cases, the algorithms are generalizable to any number of channels, no problem. With AU, this is simple. So with AU, your effects can be less wasteful and be more useful and flexible, in this basic way that really matters.
parameters:
Parameter handling in VST is totally inadequate. All you can do is give a parameter a name, a "units" text, and some display of what the value is at the current moment. You can't do totally basic things like saying: is this integer or continuous, is this a list of choices not a numerical value, is this an on/off switch parameter, is there a specific range (min and max values) for this parameter. And you can't do other interesting things like say: is this parameter hidden, or only for looking at, or only for input or output, is it part of a cluster of parameters that all go together, etc. AU provides all of this, though. Just take a look at some AUs with generic interfaces (not with Logic, but in other apps, Logic's generic interface is not so great). You see popup menus, check boxes, clusters of parameters, meter displays, text input boxes where you can enter in specific values, etc. Now look at some VST plugins. It's just a bunch of sliders or knobs. You can't type in values ever. Even ridiculous stuff like an on/off parameter will be presented as a slider. The generic interfaces are terrible. Now I know that some of you may say, "But I want a custom GUI anyway," well, but sometimes you do still want to use a generic interface. Like, for example, editing automation data in Logic. Hey, have you noticed how incredibly nice that has gotten with AUs (as long as they were decently made AUs)? Or if you use a hardware control surface like the Logic Control, or if you are disabled in certain ways, or if you are using some hosts that don't support custom GUIs (FCP, Sonasphere, etc.), you really need a decent generic interface, and VST simply cannot offer that, while AU really can very well.
One thing that I want to just mention again is the issue of parameter ranges. In VST, every parameter value ranges from 0 to 1. There's nothing that you can do about this. The plugin will hide this from you, though, by displaying a meaningful value, while actually mapping back and forth between that 0 to 1 range internally. I always found this annoying as a developer, but it has important drawbacks for us as users, too. Remember how I mentioned that you can type in exact values in the AU generic interface, but not with VST? Well, that's because AU is working with literal values. If you type in 6, the generic interface knows how to deal with that because it can just say to the AU, "Now this parameter's value is 6." A VST generic interface, on the other hand, can't know what to do. It can only communicate in the 0 to 1 range. What you get here is a situation in VST where you only know what the parameter value is after you set it. You can't say "Go to 6." Instead, you have to twiddle around until you reach 6, until the plugin says back to you, "Okay, I'm showing you 6 now." This really sucks in apps like Max/MSP, for example. So much of the power of Max comes from connecting its event structure to anything, but when you try to do that with VST parameter changes, you always just have to guess. "Yeah, so I want that delay time to go to 12 ms now, ummm, maybe 0.138 will do that???"
presets:
VST doesn't actually have a real notion of presets. Instead, it does what it calls "programs." From everything I've managed to determine from talking to other folks, no one seems to like this (so I'm not alone). AU presets are actually presets. Let me elaborate...
In a VST plugin, let's say that you've switched to program 3 and then adjust some parameters after that. Then you switch to program 6. Then back to 3. The parameter changes that you made after first loading program 3 are back. The original state of the preset is not recalled. In AU, presets are simply presets, they are read-only and applied to the current state. The AU just has a single state, not multiple ones which also correspond to each program, like with VST.
There are a few reasons why I think that the AU way is better. One is that I find that most users seem to either be confused by the VST behavior, or they understand it but dislike it. It also can lead to a lot of unexpected behavior when restoring settings, I've found from many support emails that I've handled. So basically I think that folks just seem to like the AU behavior better, and expect it. Another problem is that most VST hosts will save the entire set of programs when saving settings in a song document. After all, the host doesn't know if you're using state data from more than one of the programs, although 99.9% of the time users are not, but to make sure, the host has to just save everything. This leads to way more bloated song files than need be. It varies from plugin to plugin, and depends on how many programs the plugin has, but for example, with the VST version of SFX Machine RT, the settings are almost 1 MB per instance for VST, as compared to 4 KB for AU (SFX has about 300 presets).
busses:
AU allows plugins to use multiple "busses". In this context, a bus is a set of audio channels. A set can mean just 1, or more. You would use multiple busses if, for example, you had a vocoder with carrier and modulator signals. It makes a lot more sense than for the plugin to say "left input is carrier and right input is modulator" or something annoying like that. It also allows for switching of context from 3 channels for each bus or 2 channels or whatever. And most importantly, it means that the plugin is presenting this i/o configuration in a way that the host can make sense of, and when the host can make sense of it. That means that the host can know that there are 2 distinct sets of i/o, and present that informtation in a meaningful way to the user. In Logic, for example, Logic would know to present a sidechain input for the plugin for its secondary bus. This also allows for what folks call "multi-out" instruments to present their output in a saner way, as sets of stereo outputs or whatever they actually are. So for the user, this means that hooking up audio can actually make sense when using these plugins. VST has no way of presenting this information. The plugin just says that it has X total number of inputs and Y total number of outputs and who knows what they are for, if anything special.
notifications:
In VST, if something changes about your plugin (like maybe the latency due to a parameter change, or the number of parameters due to a preset change, or the currently selected preset, or a parameter value, whatever), you can't do anything to tell other interested "listeners" (like the host, a hardware control surface, etc.). This can mean that interfaces will no longer represent the current state, or that things just won't work right. VST simply has no system for saying, "Hey, this just changed internally, pay attention!" You just have to hope that the host might eventually do that, or simply expect that it won't and therefore don't implement something useful in your plugin. In AU, it is possible to broadcast notifications about changes of any property or parameter. It's a very basic and necessary thing, but VST does not offer it, whereas AU does.
extended music API:
AU gets around the limitations of MIDI (7-bit all da way!) by providing an extended music data API. It allows for fractional note values, multiple same-note instances, continous fractional values for any controller messages, etc. Now, this is another thing in the as-yet-to-be-taken-advantage-of category, but I'm still glad that it's there and personally I plan to take better advantage of it in my projects. VST, on the other hand, can only send a stream of raw MIDI data to plugins.
initialization after creation:
One issue that's always plagued VST is the problem of when a host will "scan" your plugin collection while launching in order to collect information about features of the plugins. With VST, this can be quite inefficient because basically you have to fully create the plugin before you can ask it anything. In AU, however, there are 2 stages of creation: Open and Initialize. When you Open an AU, you can start querying any of its properties, configure its audio stream format, etc. But once you want to actually start rendering audio, you Initialize it and then the plugin may allocate heavy resources, do calculations to prepare for rendering, etc. It of course varies from plugin to plugin how this goes, but this does provide a way to allow plugins to be created more efficiently. Now some VST developer may say, "but hey, VST has suspend and resume," but those are not the same, they are more for clearing the DSP state, although sometimes they're used in the same way as Initialize/Uninitialize (VST is very muddled), but on top of that, in order to determine if a plugin uses MIDI, you have to do a suspend/resume pair anyway.
you can make a host without constant struggle:
Yes, Apple came up with this brilliant idea when they created the AU docs and SDK: "Let's tell people how to host AU plugins." Whoa, what a breakthrough! You'd think, if all you knew was VST, that this was a total revelation. Yeah, VST may have been around for 5 years or so before AU came along, yet it still doesn't have any host documentation, example code, or anything!!! Every developer who wants to host AUs faces a constant uphill battle, trying to figure out how to host VSTs via reverse psychological analysis of the plugin SDK, which is pretty damn pathetic itself already. On the other hand, you look at even the very first release of the AU SDK and it was filled with pages and pages of pretty thorough host documentation and full source code for 3 yes 3 example AU host apps. They even created a wonderful convenience API for hosting AUs called AUGraph, which can make it really really easy to add good AU support to your app. In the Panther SDK, they've begun a project of creating a handy C++ class encapsulating an AU instance in a similar way that the AUBase SDK helps plugin developers. Apple are very committed to helping both host and plugin developers do AU. I think that this is evident by the fact that new AU host apps keep sprouting up every month it seems. And every new app that appears that hosts plugins only hosts AU, no one is bothering with VST for new apps anymore, and who can blame them. You only get so many years until you die, ya know...
AUValidation:
Apple provides a commandline tool which will analyze your AUs for conformance. This is sooooo far beyond what Steinberg have ever provided with VST. This is a pretty new thing from Apple (only publicly released last week), but it is very good news for developers and for users, who I think will benefit from this very useful tool to help developers make sure that they got their stuff right. And basically it's part of a larger aspect of what I like about developing AU rather than VST, which is that Apple really support developers in meaningful ways, and are always improving this.
What are the main problems that can arise from "wrapping" VST to AU (in any sense) that a user might care about?
I'm writing about this because of that other Hypersonic-spawned thread. As some folks said, the whole wrapper thing only matters, ummm, when it matters. So here are a few things that might make it matter for a given plugin, so you can keep these in mind when you're trying to decide whether this is "an issue" or not:
First, it means that the plugin can't take advantage of any of the above features. So if a plugin is one that could benefit from those advantages, then you lose out. This of course varies from plugin to plugin, how much of which things matter.
The presentation of parameters are messed up. They all show up as 0 to 1 continuous. This irritates me to no end, it's one of the really significant nice improvements that we get from AU. But instead, with wrapped plugins you just get generic interfaces that are unusable, just showing totally meaningless parameter values.
Along the same lines, presets don't work right, since the VST approach is fundamentally different.
If you're using a multi-bus-ish plugin, the bus stuff just won't work right. As of right now, things haven't moved along enough to see just how this might play out, but let's take an example of an instrument with 3 stereo output busses. If you're wrapping VST, that will be presented as 1 bus with 6 outputs. If the host is written properly to only show multiple output sections for each bus, then the plugin just will not be working as you would expect. It will either be shown to be incompatible with a stereo output, or it will lose the last 4 outputs, or it will ouput to surround, or maybe something else (depending on the host implementation). This is still newish territory for some hosts supporting this part of AU, since only recently have some multi-bus AUs appeared on the scene, so again I'm not sure how this will play out, but it is a possible serious problem for some plugins.
Are AUs hard to make than VST plugins, or is the API too complex?
No. It has some capabilities that VST doesn't have, and in that sense, a bit more complexity. But in my opinion, not much more than simply what was needed in order to get above VST's mediocrity and overcome some of its glaring shortcomings. I think that the main pebble in the road for some folks is that there are a couple of pretty fundamental things that aren't really spelled out explicitly anywhere in the AU docs or SDK so far, and that unfortunately makes some of it hard to understand quickly. But it's a little pebble, ask a couple of questions to someone on the CoreAudio dev list or something like that and you'll be hopping over it in no time. At any rate, I do definitely still hope that this is improved in future SDK updates.
On the other hand, because the AU API is actually decently and sanely designed (which VST is not by a long shot), that means that it is a lot simpler to get into it, in a number of ways. I think the good ole "what the fuck" count test is probably the appropriate measure to use here. In my dealing with VST and getting deeper into it, I've probably shouted out "What the fuck?!?" in desparate, befuddled frustration about 80 to 90 times. With AU, this has only happened fewer than 10 times. AU just makes sense in a basic way, there's consistency in how things are done, there are systems for the most basic things like reporting any sort of internal state change, saying whether an operation was successful or not, I mean really really basic stuff that just is confusing, inconsistent, or nonexistent all throughout VST.
So then why are some developers lagging with making AUs, or not doing them well?
I have a few ideas about that...
[begin purely biased, speculative theorizing]
One is that, in my experience, I've found that unfortunately a lot of developers resent learning new stuff. For me, that's one of my favorite things about doing this stuff as a job. I mean, that's one of the big things lacking from so much work out there, that you just don't get the chance to develop or learn more while working. So I don't identify with that perspective at all, but it's out there (well, also maybe it helped that I recognized pretty quickly that, hey, learning AU will actually make my programming life a lot easier since it solves just about all of the infuriating and frustrating problems that I've struggled with in VST). But yeah, that's that, it's pretty simple, some folks just resent having to learn anything new. And to make things worse for them, the introduction of AU pretty much coincided with the introduction Mac OS X, which is a much bigger thing in terms of learning new developer stuff, so that can make things overwhelming.
There are developers who primarily use Windows but are doing Mac development as a job and just don't have that personal attachment or motivation to do a good job. Of course, this stretches beyond just doing AU well, these sorts of folks tend to do Mac software poorly in a lot of other ways. But it's just something that happens, they just don't have their hearts in it and hence go for the least possible work solution. I'm not saying that they're terrible people because of this, but they're just not going to be excited about what they're doing in these cases. And I'm also not saying that this applies to 100% of Windows users who make Mac software, but it's a general sort of problem. And it goes the other way too, of course.
Some developers don't understand CoreFoundation, at all. This kind of ties in with the above point. CoreFoundation is basically new with Mac OS X (okay, that's a big oversimplification, but I'll spare you the boring details). This is the sort of thing where, if you handle the stuff wrong, you'll either see: 1) memory leaks or 2) crashes. While it's not really the CoreAudio team's responsibility to cover this (Apple already provides plenty of really thorough documentation of CoreFoundation), I do still think that it could behoove them to recognize that it's probably a weak point in a lot of AU developers' knowlege, that a lot of them probably only need to think about CoreFoundation in the context of AUs, and hence a little CoreFoundation Primer For AU Developers I think would be a good thing to publish.
Some people are doing a half-assed job. They're porting plugins from VST code and simply not accommodating for the differences between the 2, and taking the shortest possible road to completion. These people need to be konked upside the head with a frying pan because, HELLO! WAKE UP! most hosts in Mac OS X support AU and only AU for plugins, and most that support VST also support AU. AU is THE format to do for OS X plugins. You can forget about VST, in fact, it's virtually irrelevant at this point. Only a small number of laggard apps remain that support VST and not AU, and they have all promised AU support to come. On the flipside, not a single one of the 15 or so AU-only hosts has any plans to add VST support. Again, these plugin developers need to wake up and see what matters for Mac OS X plugins: it's AU (with VST being a possible afterthought, and RTAS if you want the Pro Tools kidz and can get Digi's blessing).
I'll close this off by copy'n'pasting something that I wrote recently to someone who said something along the lines of, "I don't know, you say VST sucks, but it sure works great for me!" Here was my response (some of which is redundant, but oh well, I don't feel like editing it right now):
Sort of. For some simple things, it's totally fine and sufficient. But there are many problems. Some of that is more experienced on the side of people actually trying to implement it (make plugins or hosts), either making things more difficult or impossible (and when it's impossible, you never know it because the result is that that thing just doesn't happen), but some definitely leaks down to the users.
Have you ever found it annoying that most VSTs only do stereo processing and can't really do mono processing? They just do a fake mono where the input is doubled and the output is stereo? And hence you use twice as much CPU processing as necessary? Or have you ever wanted an effect to work on a surround signal, but it's stuck just as stereo or mono only? That's because VSTs are unable to function with more than one channel count. AUs can, though.
Have you ever used an app like Max/MSP where you would want to send parameter changes as events in part of your arrangements/structures, but you have no idea which magic value to send, since every parameter value is technically squashed somehow into a 0 to 1 range? With AU, parameter values are literal.
Have you ever noticed how many things can go out of sync between the VST host and plugin? Like if the plugin lets you switch presets, and the host updates the current preset in its UI, the host never updates when you choose a preset from the plugin's UI? That's because VST has no system for sending notifications when a plugin's properties or parameter values have changed. There are other common symptoms of that problem, but that's just one. AU doesn't have those problems.
Have you ever noticed how VST plugins with lots of presets generate enormous settings data? That's because every preset gets saved whenever you save the data (well, usually, it can vary). Even though you're probably just using one setting, the whole collection gets dumped to disk. In AU, presets are just that: presets. They are not also considered the user state. And hence the entire preset collection is not needlessly included whenever you save an AU's settings.
Have you ever seen a VST plugin get updated with a changed range for a parameter, and then your settings don't work right anymore? That's because of all parameters being squashed to 0 to 1 ranges. Or have you seen if a parameter gets removed, then settings don't work right? That's because in VST, all parameter IDs need to be consecutive starting with 0, whereas in AU that can be however the author wants.
Have you ever noticed how you can't use keyboard control over hardly any VST plugins, and then only in a small minority of hosts? That's because the implementation of that is optional for hosts, and the specification of expectations does not exist, so hardly anyone except Steinberg can know how to do it correctly. In AU, this is not a problem.
Have you ever noticed how there are all kinds of little, and sometimes big, quirky differences between behavior in all sorts of different VST hosts? That's because there's no documentation on how to make a VST host, none at all, even after the 5 or so years that it's been public.
Anyway, I could go on, but that's probably enough. The point is that, without being someone who has actually programmed VST stuff, it's easy to not be aware of when a shortcoming is a result of VST's problems, so I don't blame you or anyone else for not knowing, but anyway, I'm just saying that there are many things.
Why is AU better than VST?
GUIs:
The GUI stuff is thoroughly defined and sanely designed in AU. In VST, there's a lot of completely ambiguous or undefined stuff. Handling of mouse clicks, what happens while the mouse drags, keyboard events, keyboard focus, etc. is all a mess. The most obvious fallout of this is that, if the plugin wants keyboard events, they just don't work right in most hosts (there are no fewer than 3, yes 3, ways to do keyboard input for VST plugins, with none of them documented, and vastly unsupported). Or text edit boxes crash in some hosts because the behavior for keyboard focus was never defined. Host GUIs freeze when you drag your mouse. Also, a really basic thing, but VST didn't define a way to say to a plugin, "hey, I actually want you to draw your GUI at this position in the window, rather than right in the top left." As a consequence, tons of hacks in plugins and hosts have made this mostly work okay, thought there are always new problems it seems. In AU, all of this stuff is defined and there are ways to do things right. Here's one example: keyboard navigation for SFX Machine RT works in every single AU host, no problems. But the VST version only works in like 2 hosts out there. Oh yeah, and just to add one more thing, AU allows a plugin to specify more than one custom GUI for an AU. This unfortunately still belongs in the category of no-one-has-taken-advantage-of-this-yet, but it's still a good thing. It means that there is a straight-forward system for presenting the user with multiple skins, expert and simple modes, different sections of the GUI, etc.
multiple i/o configurations:
This is just so basic and VST always frustrated me with this, but in VST, there's no way for a plugin to say "I can do stereo and I can do surround" or "I can do mono or stereo" or "I can do any number of channels, just tell me what you want." AU can. There are several problems that come along with this severe shortcoming of VST's. Well, basically the result of this problem is that most developers simply release plugins that present themselves as handling 2-in and 2-out. You can then do this stupid VST hack thing (canMono) that says, "well, if you want, I can do mono input also, but ummm, not really, you just have to fake it and make it look like stereo to me by doubling the input signal," if you want, but that's really just meaningless anyway. So what you get as a result of this is plugins that, when processing "mono", actually do everything in stereo and spit out stereo in the end. In most cases, this means that the plugin is using twice as much CPU to do the work and almost twice as much memory. This can vary, but that's a general tendency. I for one do a lot of tracks recorded in mono when I do multitrack recordings, and I for one sometimes run out of CPU power with plugins (I think I'm not the only one who does, either), and so I have always frickin hated that VST was so stupid in this respect. Most of the time, you're just throwing away half of your CPU resources. Then on the other side of things, what about when you want to do surround or other multichannel output? You'll find that virtually no VST effects can do this. Now technically, the vast majority of effects could do it, but it's stupid VST preventing them from providing this functionality. So that's it, dead in the water, no chance for surround processing with VST plugins in 99.9% of cases. With AU, however, a plugin can specify any number of input/output counts that it can support. It just provides a list to the host. Or, if it doesn't provide a list, then the host assumes that the plugin can do any number of channels, as long as the number of inputs equals the number of outputs. And for most effects, this is entirely feasable. Sometimes an effect really only makes sense as stereo or mono-in/stereo-out or surround whatever, something specific, but in the vast majority of cases, the algorithms are generalizable to any number of channels, no problem. With AU, this is simple. So with AU, your effects can be less wasteful and be more useful and flexible, in this basic way that really matters.
parameters:
Parameter handling in VST is totally inadequate. All you can do is give a parameter a name, a "units" text, and some display of what the value is at the current moment. You can't do totally basic things like saying: is this integer or continuous, is this a list of choices not a numerical value, is this an on/off switch parameter, is there a specific range (min and max values) for this parameter. And you can't do other interesting things like say: is this parameter hidden, or only for looking at, or only for input or output, is it part of a cluster of parameters that all go together, etc. AU provides all of this, though. Just take a look at some AUs with generic interfaces (not with Logic, but in other apps, Logic's generic interface is not so great). You see popup menus, check boxes, clusters of parameters, meter displays, text input boxes where you can enter in specific values, etc. Now look at some VST plugins. It's just a bunch of sliders or knobs. You can't type in values ever. Even ridiculous stuff like an on/off parameter will be presented as a slider. The generic interfaces are terrible. Now I know that some of you may say, "But I want a custom GUI anyway," well, but sometimes you do still want to use a generic interface. Like, for example, editing automation data in Logic. Hey, have you noticed how incredibly nice that has gotten with AUs (as long as they were decently made AUs)? Or if you use a hardware control surface like the Logic Control, or if you are disabled in certain ways, or if you are using some hosts that don't support custom GUIs (FCP, Sonasphere, etc.), you really need a decent generic interface, and VST simply cannot offer that, while AU really can very well.
One thing that I want to just mention again is the issue of parameter ranges. In VST, every parameter value ranges from 0 to 1. There's nothing that you can do about this. The plugin will hide this from you, though, by displaying a meaningful value, while actually mapping back and forth between that 0 to 1 range internally. I always found this annoying as a developer, but it has important drawbacks for us as users, too. Remember how I mentioned that you can type in exact values in the AU generic interface, but not with VST? Well, that's because AU is working with literal values. If you type in 6, the generic interface knows how to deal with that because it can just say to the AU, "Now this parameter's value is 6." A VST generic interface, on the other hand, can't know what to do. It can only communicate in the 0 to 1 range. What you get here is a situation in VST where you only know what the parameter value is after you set it. You can't say "Go to 6." Instead, you have to twiddle around until you reach 6, until the plugin says back to you, "Okay, I'm showing you 6 now." This really sucks in apps like Max/MSP, for example. So much of the power of Max comes from connecting its event structure to anything, but when you try to do that with VST parameter changes, you always just have to guess. "Yeah, so I want that delay time to go to 12 ms now, ummm, maybe 0.138 will do that???"
presets:
VST doesn't actually have a real notion of presets. Instead, it does what it calls "programs." From everything I've managed to determine from talking to other folks, no one seems to like this (so I'm not alone). AU presets are actually presets. Let me elaborate...
In a VST plugin, let's say that you've switched to program 3 and then adjust some parameters after that. Then you switch to program 6. Then back to 3. The parameter changes that you made after first loading program 3 are back. The original state of the preset is not recalled. In AU, presets are simply presets, they are read-only and applied to the current state. The AU just has a single state, not multiple ones which also correspond to each program, like with VST.
There are a few reasons why I think that the AU way is better. One is that I find that most users seem to either be confused by the VST behavior, or they understand it but dislike it. It also can lead to a lot of unexpected behavior when restoring settings, I've found from many support emails that I've handled. So basically I think that folks just seem to like the AU behavior better, and expect it. Another problem is that most VST hosts will save the entire set of programs when saving settings in a song document. After all, the host doesn't know if you're using state data from more than one of the programs, although 99.9% of the time users are not, but to make sure, the host has to just save everything. This leads to way more bloated song files than need be. It varies from plugin to plugin, and depends on how many programs the plugin has, but for example, with the VST version of SFX Machine RT, the settings are almost 1 MB per instance for VST, as compared to 4 KB for AU (SFX has about 300 presets).
busses:
AU allows plugins to use multiple "busses". In this context, a bus is a set of audio channels. A set can mean just 1, or more. You would use multiple busses if, for example, you had a vocoder with carrier and modulator signals. It makes a lot more sense than for the plugin to say "left input is carrier and right input is modulator" or something annoying like that. It also allows for switching of context from 3 channels for each bus or 2 channels or whatever. And most importantly, it means that the plugin is presenting this i/o configuration in a way that the host can make sense of, and when the host can make sense of it. That means that the host can know that there are 2 distinct sets of i/o, and present that informtation in a meaningful way to the user. In Logic, for example, Logic would know to present a sidechain input for the plugin for its secondary bus. This also allows for what folks call "multi-out" instruments to present their output in a saner way, as sets of stereo outputs or whatever they actually are. So for the user, this means that hooking up audio can actually make sense when using these plugins. VST has no way of presenting this information. The plugin just says that it has X total number of inputs and Y total number of outputs and who knows what they are for, if anything special.
notifications:
In VST, if something changes about your plugin (like maybe the latency due to a parameter change, or the number of parameters due to a preset change, or the currently selected preset, or a parameter value, whatever), you can't do anything to tell other interested "listeners" (like the host, a hardware control surface, etc.). This can mean that interfaces will no longer represent the current state, or that things just won't work right. VST simply has no system for saying, "Hey, this just changed internally, pay attention!" You just have to hope that the host might eventually do that, or simply expect that it won't and therefore don't implement something useful in your plugin. In AU, it is possible to broadcast notifications about changes of any property or parameter. It's a very basic and necessary thing, but VST does not offer it, whereas AU does.
extended music API:
AU gets around the limitations of MIDI (7-bit all da way!) by providing an extended music data API. It allows for fractional note values, multiple same-note instances, continous fractional values for any controller messages, etc. Now, this is another thing in the as-yet-to-be-taken-advantage-of category, but I'm still glad that it's there and personally I plan to take better advantage of it in my projects. VST, on the other hand, can only send a stream of raw MIDI data to plugins.
initialization after creation:
One issue that's always plagued VST is the problem of when a host will "scan" your plugin collection while launching in order to collect information about features of the plugins. With VST, this can be quite inefficient because basically you have to fully create the plugin before you can ask it anything. In AU, however, there are 2 stages of creation: Open and Initialize. When you Open an AU, you can start querying any of its properties, configure its audio stream format, etc. But once you want to actually start rendering audio, you Initialize it and then the plugin may allocate heavy resources, do calculations to prepare for rendering, etc. It of course varies from plugin to plugin how this goes, but this does provide a way to allow plugins to be created more efficiently. Now some VST developer may say, "but hey, VST has suspend and resume," but those are not the same, they are more for clearing the DSP state, although sometimes they're used in the same way as Initialize/Uninitialize (VST is very muddled), but on top of that, in order to determine if a plugin uses MIDI, you have to do a suspend/resume pair anyway.
you can make a host without constant struggle:
Yes, Apple came up with this brilliant idea when they created the AU docs and SDK: "Let's tell people how to host AU plugins." Whoa, what a breakthrough! You'd think, if all you knew was VST, that this was a total revelation. Yeah, VST may have been around for 5 years or so before AU came along, yet it still doesn't have any host documentation, example code, or anything!!! Every developer who wants to host AUs faces a constant uphill battle, trying to figure out how to host VSTs via reverse psychological analysis of the plugin SDK, which is pretty damn pathetic itself already. On the other hand, you look at even the very first release of the AU SDK and it was filled with pages and pages of pretty thorough host documentation and full source code for 3 yes 3 example AU host apps. They even created a wonderful convenience API for hosting AUs called AUGraph, which can make it really really easy to add good AU support to your app. In the Panther SDK, they've begun a project of creating a handy C++ class encapsulating an AU instance in a similar way that the AUBase SDK helps plugin developers. Apple are very committed to helping both host and plugin developers do AU. I think that this is evident by the fact that new AU host apps keep sprouting up every month it seems. And every new app that appears that hosts plugins only hosts AU, no one is bothering with VST for new apps anymore, and who can blame them. You only get so many years until you die, ya know...
AUValidation:
Apple provides a commandline tool which will analyze your AUs for conformance. This is sooooo far beyond what Steinberg have ever provided with VST. This is a pretty new thing from Apple (only publicly released last week), but it is very good news for developers and for users, who I think will benefit from this very useful tool to help developers make sure that they got their stuff right. And basically it's part of a larger aspect of what I like about developing AU rather than VST, which is that Apple really support developers in meaningful ways, and are always improving this.
What are the main problems that can arise from "wrapping" VST to AU (in any sense) that a user might care about?
I'm writing about this because of that other Hypersonic-spawned thread. As some folks said, the whole wrapper thing only matters, ummm, when it matters. So here are a few things that might make it matter for a given plugin, so you can keep these in mind when you're trying to decide whether this is "an issue" or not:
First, it means that the plugin can't take advantage of any of the above features. So if a plugin is one that could benefit from those advantages, then you lose out. This of course varies from plugin to plugin, how much of which things matter.
The presentation of parameters are messed up. They all show up as 0 to 1 continuous. This irritates me to no end, it's one of the really significant nice improvements that we get from AU. But instead, with wrapped plugins you just get generic interfaces that are unusable, just showing totally meaningless parameter values.
Along the same lines, presets don't work right, since the VST approach is fundamentally different.
If you're using a multi-bus-ish plugin, the bus stuff just won't work right. As of right now, things haven't moved along enough to see just how this might play out, but let's take an example of an instrument with 3 stereo output busses. If you're wrapping VST, that will be presented as 1 bus with 6 outputs. If the host is written properly to only show multiple output sections for each bus, then the plugin just will not be working as you would expect. It will either be shown to be incompatible with a stereo output, or it will lose the last 4 outputs, or it will ouput to surround, or maybe something else (depending on the host implementation). This is still newish territory for some hosts supporting this part of AU, since only recently have some multi-bus AUs appeared on the scene, so again I'm not sure how this will play out, but it is a possible serious problem for some plugins.
Are AUs hard to make than VST plugins, or is the API too complex?
No. It has some capabilities that VST doesn't have, and in that sense, a bit more complexity. But in my opinion, not much more than simply what was needed in order to get above VST's mediocrity and overcome some of its glaring shortcomings. I think that the main pebble in the road for some folks is that there are a couple of pretty fundamental things that aren't really spelled out explicitly anywhere in the AU docs or SDK so far, and that unfortunately makes some of it hard to understand quickly. But it's a little pebble, ask a couple of questions to someone on the CoreAudio dev list or something like that and you'll be hopping over it in no time. At any rate, I do definitely still hope that this is improved in future SDK updates.
On the other hand, because the AU API is actually decently and sanely designed (which VST is not by a long shot), that means that it is a lot simpler to get into it, in a number of ways. I think the good ole "what the fuck" count test is probably the appropriate measure to use here. In my dealing with VST and getting deeper into it, I've probably shouted out "What the fuck?!?" in desparate, befuddled frustration about 80 to 90 times. With AU, this has only happened fewer than 10 times. AU just makes sense in a basic way, there's consistency in how things are done, there are systems for the most basic things like reporting any sort of internal state change, saying whether an operation was successful or not, I mean really really basic stuff that just is confusing, inconsistent, or nonexistent all throughout VST.
So then why are some developers lagging with making AUs, or not doing them well?
I have a few ideas about that...
[begin purely biased, speculative theorizing]
One is that, in my experience, I've found that unfortunately a lot of developers resent learning new stuff. For me, that's one of my favorite things about doing this stuff as a job. I mean, that's one of the big things lacking from so much work out there, that you just don't get the chance to develop or learn more while working. So I don't identify with that perspective at all, but it's out there (well, also maybe it helped that I recognized pretty quickly that, hey, learning AU will actually make my programming life a lot easier since it solves just about all of the infuriating and frustrating problems that I've struggled with in VST). But yeah, that's that, it's pretty simple, some folks just resent having to learn anything new. And to make things worse for them, the introduction of AU pretty much coincided with the introduction Mac OS X, which is a much bigger thing in terms of learning new developer stuff, so that can make things overwhelming.
There are developers who primarily use Windows but are doing Mac development as a job and just don't have that personal attachment or motivation to do a good job. Of course, this stretches beyond just doing AU well, these sorts of folks tend to do Mac software poorly in a lot of other ways. But it's just something that happens, they just don't have their hearts in it and hence go for the least possible work solution. I'm not saying that they're terrible people because of this, but they're just not going to be excited about what they're doing in these cases. And I'm also not saying that this applies to 100% of Windows users who make Mac software, but it's a general sort of problem. And it goes the other way too, of course.
Some developers don't understand CoreFoundation, at all. This kind of ties in with the above point. CoreFoundation is basically new with Mac OS X (okay, that's a big oversimplification, but I'll spare you the boring details). This is the sort of thing where, if you handle the stuff wrong, you'll either see: 1) memory leaks or 2) crashes. While it's not really the CoreAudio team's responsibility to cover this (Apple already provides plenty of really thorough documentation of CoreFoundation), I do still think that it could behoove them to recognize that it's probably a weak point in a lot of AU developers' knowlege, that a lot of them probably only need to think about CoreFoundation in the context of AUs, and hence a little CoreFoundation Primer For AU Developers I think would be a good thing to publish.
Some people are doing a half-assed job. They're porting plugins from VST code and simply not accommodating for the differences between the 2, and taking the shortest possible road to completion. These people need to be konked upside the head with a frying pan because, HELLO! WAKE UP! most hosts in Mac OS X support AU and only AU for plugins, and most that support VST also support AU. AU is THE format to do for OS X plugins. You can forget about VST, in fact, it's virtually irrelevant at this point. Only a small number of laggard apps remain that support VST and not AU, and they have all promised AU support to come. On the flipside, not a single one of the 15 or so AU-only hosts has any plans to add VST support. Again, these plugin developers need to wake up and see what matters for Mac OS X plugins: it's AU (with VST being a possible afterthought, and RTAS if you want the Pro Tools kidz and can get Digi's blessing).
I'll close this off by copy'n'pasting something that I wrote recently to someone who said something along the lines of, "I don't know, you say VST sucks, but it sure works great for me!" Here was my response (some of which is redundant, but oh well, I don't feel like editing it right now):
Sort of. For some simple things, it's totally fine and sufficient. But there are many problems. Some of that is more experienced on the side of people actually trying to implement it (make plugins or hosts), either making things more difficult or impossible (and when it's impossible, you never know it because the result is that that thing just doesn't happen), but some definitely leaks down to the users.
Have you ever found it annoying that most VSTs only do stereo processing and can't really do mono processing? They just do a fake mono where the input is doubled and the output is stereo? And hence you use twice as much CPU processing as necessary? Or have you ever wanted an effect to work on a surround signal, but it's stuck just as stereo or mono only? That's because VSTs are unable to function with more than one channel count. AUs can, though.
Have you ever used an app like Max/MSP where you would want to send parameter changes as events in part of your arrangements/structures, but you have no idea which magic value to send, since every parameter value is technically squashed somehow into a 0 to 1 range? With AU, parameter values are literal.
Have you ever noticed how many things can go out of sync between the VST host and plugin? Like if the plugin lets you switch presets, and the host updates the current preset in its UI, the host never updates when you choose a preset from the plugin's UI? That's because VST has no system for sending notifications when a plugin's properties or parameter values have changed. There are other common symptoms of that problem, but that's just one. AU doesn't have those problems.
Have you ever noticed how VST plugins with lots of presets generate enormous settings data? That's because every preset gets saved whenever you save the data (well, usually, it can vary). Even though you're probably just using one setting, the whole collection gets dumped to disk. In AU, presets are just that: presets. They are not also considered the user state. And hence the entire preset collection is not needlessly included whenever you save an AU's settings.
Have you ever seen a VST plugin get updated with a changed range for a parameter, and then your settings don't work right anymore? That's because of all parameters being squashed to 0 to 1 ranges. Or have you seen if a parameter gets removed, then settings don't work right? That's because in VST, all parameter IDs need to be consecutive starting with 0, whereas in AU that can be however the author wants.
Have you ever noticed how you can't use keyboard control over hardly any VST plugins, and then only in a small minority of hosts? That's because the implementation of that is optional for hosts, and the specification of expectations does not exist, so hardly anyone except Steinberg can know how to do it correctly. In AU, this is not a problem.
Have you ever noticed how there are all kinds of little, and sometimes big, quirky differences between behavior in all sorts of different VST hosts? That's because there's no documentation on how to make a VST host, none at all, even after the 5 or so years that it's been public.
Anyway, I could go on, but that's probably enough. The point is that, without being someone who has actually programmed VST stuff, it's easy to not be aware of when a shortcoming is a result of VST's problems, so I don't blame you or anyone else for not knowing, but anyway, I'm just saying that there are many things.
