Produceren met apple

Is het dan niet zo dat er meer VST's zijn voor windows dan voor apple? Ik las ook iets over "VST to AU Adapter v2.0 (http://www.fxpansion.com/index.php?page=5)... werkt dat ook goed?

New in version 2.0:-
* Support for Intel-based Macs (Universal Binary VSTs only)

* "OS X Carbon" and "OS X Mach-O" VST plug-ins on OS X / PPC; "OS X Intel" plug-ins on OS X / x86. "Mac OS 9" VST plug-ins are not supported; "Mac OS X PPC" plug-ins can not be used on Intel-CPU Macs, and vice versa. >>>Windows VST plug-ins cannot be used<<<.

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.