VST vs Audiounits

[James Steele]

There are some old 32bit AU plugs that no longer work in 64bit as expected.

You can always run the AUs in 32 Lives. I've found 32 Lives to be pretty good now. A lot of older AUs work, including... lol... Plugsound Pro! A blast from the past, but it's kind of fun to see it running fine.

[nk_e]

I recall the guy from AudioDamage being very vocal on the subject in one of his (typically) curmudgeonly posts. AD develops for both standards and he believes VST the better default choice whenever you have a choice between versions.

I think the advice earlier was spot on: If you are dealing with a plug in from a primarily Windows developer, the VST version is likely the stronger choice.

[bayswater]

Supersonic, if I understood your question, it's not whether AU or VST is better in some way, but whether DP users would be concerned if developers stopped producing AU versions of future plugins.

[David Polich]

Gotta disagree, David. It may not be a big enough point to fret about, but there can be such a thing as an objectively better or worse standard. If memory handling and CPU usage is streamlined, then you can easily have one flavor that I would think you can call superior. Yes, there is the inherent comfortability factor as well, but I don't believe it's wrong to point to one or the other and be able to make a judgement call... though I doubt many here can make that kind of judgement.

My point is, developers should man up and deal with AU issues, or they shouldn't be in
the development business. If you're going to do an AU version, then you've made your bed
so to speak.

I don't feel sorry for developers.

AU was Apple's plug-in and VI protocol. At least Apple came up with it. Microsoft's idea of an audio standard was .wma, but it couldn't be applied to plug-ins and VI's.

Anyway, thankfully us DP users don't have to be concerned. We can use either VST or AU.

[James Steele]

I thought about starting to use VSTs for possible Windows compatibility, but then I realized I don't really exchange projects with anyone running DP for Windows, so I've fallen back on AU.

[Dan Worley]

It's always something. It seems that the "best" is most often the opposite of what I'm using, and yet I'm still at it. I've heard developers complain loudly about DP, too.

[Prime Mover]

Does sort of remind me of being a web designer, actually. The independent W3C spends a lot of time creating these really nice logical standards and try to get all browser developers to be on board with, but time and time again, Microsoft thinks it "knows better" and IE doesn't adhere. It's gotten better, but back when I was doing a lot more commercial web design, it was a nightmare, and you practically had to build the site from scratch twice.

Now, this isn't as egregious, as no one expects all plugin types to be equal, but it's easy to understand that one ends up becoming the "Primary" that developers always hold up as the standard, and the other is just a nuisance.

[Michael Canavan]

So as a layman I spent the first couple years when AU came out on OSXAudio, and a lot of developers at one point would chime in:

FXPansion: AU is a PITA because it only supports OSX and requires a complete rewrite of the GUI code for a plug in to port it from VST. They acknowledged that VST wasn't a holy grail either, They developed the AU wrapper for VSTs, and have long since stopped upgrading it because 99% of OSX VST plug ins also have an AU version now. (Side note, the porting technology is still used, and that might be responsible for the very slight CPU hit that AU gives. The hit is less than 3% from what I recall, and not worth mentioning IMO)

Audio Damage: The developer doesn't do much talking, it's mainly the graphic guy, and their development environment that they first test on is Nuendo, Windows, VST. The Graphic guy has a lot of opinions, including that DP is the most impenetrable DAW he's run across.

Uh-He: Urs Heckman started developing because Audio Unit development papers are super easy to get into apparently compared to VSTi. His first "pro" synth Zebra 1 was AU only. Unlike the FXPansion guys or Audio Damage he prefers AU because if the guidelines are followed, it tends to not need as much debugging. This I would guess is easier for him because he's not trying to port VST GUI code to AU, and failing AU tests in DP and Logic etc.


The main reason for AU development was to get away from being beholden to Steinberg. Cubase is always the first to run the latest version of VST smoothly because Steinberg may publish great information on plug in development, the hosting is always geared towards a certain DAW. This IMO is why you see DP8 and the newly released Bitwig Studio not supporting VST3. I think it's at about 50% adoption among plug in developers but hosts wise it's only two or three… AU also was developed because Apple felt that VST plug in developers where leaving Windows code in by mistake, causing VST to crash on OSX but not Windows. Basically the end user would blame OSX as a lousy environment for plug ins if they used VST. This is why the AU validation test exists. I can attest to having way more crashes using VST in Logic than when AU was developed. VST does offer developers some shortcuts when porting a Windows VST to OSX, and that's going to appeal to developers even with possible bug fixing because of incompatibilities. AU offers no such thing, your C++ code will require an entirely new GUI.


All that said, AU needs to be updated, Logic is probably holding that back though, but the failure of VST3 to be widely adopted is IMO also holding that back for Apple. Why bother releasing a new version that causes developers hassle when they aren't adopting the universal standard VST when it presents a new version?

[reedster]

Does anyone have links handy for developer packs for each standard? I'm curious now to look at the code and evaluate it.

xcode updates and apple moving some things around seems to have made the audio unit information a little obscure. Hope the below is of some use.

building an audio unit in xcode without starting from a template:
http://sample-hold.com/2011/11/23/getti ... ode-4-2-1/

note the: "EDIT for XCode 4.3.2 users:" paragraph - seems to still pertain to xcode 5.1 and led me to here from xcode:

https://developer.apple.com/downloads/i ... 0Xcode%20-
Look for Audio Tools for Xcode Oct 2013

Core Audio Utility Classes:
http://tinyurl.com/o4frs3n

[artfarm1]

I've loaded in a VST version of a plugin instead of the AU when it had the capability to do something the AU version wouldn't do.

I've discovered that certain VST versions will be better at responding to the 'MIDI learn' function.

[nk_e]

So as a layman I spent the first couple years when AU came out on OSXAudio, and a lot of developers at one point would chime in:

FXPansion: AU is a PITA because it only supports OSX and requires a complete rewrite of the GUI code for a plug in to port it from VST. They acknowledged that VST wasn't a holy grail either, They developed the AU wrapper for VSTs, and have long since stopped upgrading it because 99% of OSX VST plug ins also have an AU version now. (Side note, the porting technology is still used, and that might be responsible for the very slight CPU hit that AU gives. The hit is less than 3% from what I recall, and not worth mentioning IMO)

Audio Damage: The developer doesn't do much talking, it's mainly the graphic guy, and their development environment that they first test on is Nuendo, Windows, VST. The Graphic guy has a lot of opinions, including that DP is the most impenetrable DAW he's run across.

Uh-He: Urs Heckman started developing because Audio Unit development papers are super easy to get into apparently compared to VSTi. His first "pro" synth Zebra 1 was AU only. Unlike the FXPansion guys or Audio Damage he prefers AU because if the guidelines are followed, it tends to not need as much debugging. This I would guess is easier for him because he's not trying to port VST GUI code to AU, and failing AU tests in DP and Logic etc.


The main reason for AU development was to get away from being beholden to Steinberg. Cubase is always the first to run the latest version of VST smoothly because Steinberg may publish great information on plug in development, the hosting is always geared towards a certain DAW. This IMO is why you see DP8 and the newly released Bitwig Studio not supporting VST3. I think it's at about 50% adoption among plug in developers but hosts wise it's only two or three… AU also was developed because Apple felt that VST plug in developers where leaving Windows code in by mistake, causing VST to crash on OSX but not Windows. Basically the end user would blame OSX as a lousy environment for plug ins if they used VST. This is why the AU validation test exists. I can attest to having way more crashes using VST in Logic than when AU was developed. VST does offer developers some shortcuts when porting a Windows VST to OSX, and that's going to appeal to developers even with possible bug fixing because of incompatibilities. AU offers no such thing, your C++ code will require an entirely new GUI.


All that said, AU needs to be updated, Logic is probably holding that back though, but the failure of VST3 to be widely adopted is IMO also holding that back for Apple. Why bother releasing a new version that causes developers hassle when they aren't adopting the universal standard VST when it presents a new version?

This was a fantastic post. Thanks.

[Shooshie]

VST does offer developers some shortcuts when porting a Windows VST to OSX, and that's going to appeal to developers even with possible bug fixing because of incompatibilities. AU offers no such thing, your C++ code will require an entirely new GUI.

When writing in the Cocoa environment, you can compile things easily for Windows and Mac from the same project. Is there no carry-over when doing AU (in Cocoa) to VST? Seems as though most components of a GUI should be reusable in either version. But I know absolutely nothing about how VST plugins are written, so maybe that's just not the case here.

Shoosh

[Michael Canavan]

VST does offer developers some shortcuts when porting a Windows VST to OSX, and that's going to appeal to developers even with possible bug fixing because of incompatibilities. AU offers no such thing, your C++ code will require an entirely new GUI.

When writing in the Cocoa environment, you can compile things easily for Windows and Mac from the same project. Is there no carry-over when doing AU (in Cocoa) to VST? Seems as though most components of a GUI should be reusable in either version. But I know absolutely nothing about how VST plugins are written, so maybe that's just not the case here.

Shoosh

From the Cocoa Wiki:

There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, and Cocotron.

While to me or you this might read as "Develop in Apple's Cocoa framework, then easily port.." but it never is easy. Plus both those porting frameworks are open source…. Mostly developers get the Windows and Mac OS VST working properly then port to AU. Mostly developers start in Windows and port to OSX, so using a native OSX framework that has some nods to Windows in the open source community isn't going to work so well for them.

Urs and U-He may be one of the few companies to do Cocoa first, and their stability on OSX is a testament to that.

Plus Cocoa as a 100% thing in GUI development is relatively new from what I recall? Funny story is Steinberg were getting complaints from people about their slow GUI on OSX about 7 years ago and they retorted on their forums that the 100% Cocoa build they made in house was about five times more sluggish! This of course was years ago, but it outlines why the slow adoption of Cocoa by the industry happened.

[bayswater]

Funny story is Steinberg were getting complaints from people about their slow GUI on OSX about 7 years ago and they retorted on their forums that the 100% Cocoa build they made in house was about five times more sluggish! This of course was years ago, but it outlines why the slow adoption of Cocoa by the industry happened.

I remember that too well. The annoying thing was Cubase graphics were so much more sluggish than with similarly complex Mac programs. And you had to wonder what the programmers were up to. Now and then you'd get an error dialog, not only in German, but actually in a Windows style dialog box, as if they'd actually hard coded a windows formatted box, and didn't know about localization. It all seems to be fixed now.

[mhschmieder]

Unfortunately, I've hit two showstopper problems since I made my request for developer toolkit links, so I can't look at them right now (also, my Apple Developer ID only works from one specific computer and login credentials so I don't think I can do this from home).

Thanks for the links though. Maybe in a few weeks I can look at them. I feel like Mavericks is the most unstable OS I have used in a decade or more, from any vendor.