Instead of reducing the number of plug-in formats, Mac OS X has added one more to the mix. Furthermore, many Windows-based developers have not found the AU format easy to develop for, and the rollout of AU plug-ins has been slow. Finally, as with other plug-in formats, not all AU plug-ins function equally well in all host applications. Read the article here. Also, make sure you read MacDevCenter, as it contains a number of interesting Mac development articles lately.
that is HOT news on http://www.steinberg.net ´s frontpage seems to have support for AU on the mac. Thats very sad and if Logic did have native support for VST-plugins i would be the first to change track
VST is the dominant standard. Apple should have just licensed VST.
Is VST similar to AU? i was lead to the believe that apple had based AU on VST.
any comments on developing for opposing platforms (VST vs. MAS vs. DirectX)
Cakewalk had to backtrack and support VST (on the PC) after years of bashing it. That says a lot.
on cubase SX3. Here is an interesting new feature.
“External FX Plugins allow for direct integration of external hardware effects processors into the VST audio mixer. Use your favorite outboard gear just like plugins ? including automatic delay compensation.”
Ryan: That seems like a nice new feature. The sad thing is that i have sold all my hardware for go on the lighter and softer side .
Nisse: i agree on that being a nice feature. Steinberg and consequently VST continues to demonstrate consistent leadership.
You cant distribute the VST header files, effectively killing source-distribution of VST modules, or VST support in open source projects.
I’m not sure whether AU allows redistribution of the AU headers/supporting libs, but if so it will probably see support on Linux as well as OS X – since Steinberg seem hell-bent on leaving free/open source developers out in the cold.
Anyone know Apple’s policy on SDK/runtime lib/header redistribution policy?
One major point of AU is that host applications only need to support one plugin format, then all other formats can be wrapped around AU. Thus, one app can just host AudioUnits and get access to wrapped VST plugins, in addition to the special AudioUnits.
I love OS X! It gives me so many choices! Take for example, downloadable formats: we’ve got sit, pkg, dmg, mpkg, gz, sea, bin, hqx and a couple of zillion more. OS X is all about choice! even more so than OSS!
One thing that your all forgetting is the extremley low latency that AU provides as well as the integration in the OS, the VST plug in architecture can as has been said sort of wrapped around an AU host that that the host app that supports AU can use VST, there are also convertors that convert real time VST’s to AU just search google.
I can understand steinburg not putting AU support in the OS X version of Cubase SX 3 due to them wanting to support and promote their own plug in architecture but it is a sad loss that they havn’t
AU gets round some of the problems with VST –
Badly defined host behaviour (Who does the preset handling etc)
Dumb ports (An output is an output, you cannot inform the host about what is it and how it should be treated+a plugin cannot be multiple mono, stereo or multiple stereo, seperate plugins are required for each configuration)
Reliance on MIDI for note passing. (AU has some neat microtonal etc capabilities I don’t know if anyone actually uses this yet)
All port numbers are between 0 and 1 (Great as you are dealing with float most of the time, annoying as you have to convert every number to float and back for controls etc)
So, wrapping VST in AU may work, but you don’t get the benefits of AU. The way you test VST plugins is to try them in every app you can then bugfix or kludge to deal with an apps peculiarities, in theory AU host behaviour is better defined and will save a load of trouble.
I’ve have not written a complete AU plug yet, and have only messed with VST so I would welcome clarification on this.
PS RE: Cubase SX3… Ardour allows you to route external hardware into an insert point too. I don’t think there is automatic delay compensation, but that would be fairly trivial to implement. (And I don’t know how Cubase could magicly know the latency of my outboard gear anyway, I suspect they just compensate for buffers+A/D D/A latency and assume the analog side has zero latency)