My custom Audio Unit opens in AU Lab but not Garag

问题:

I created a filter AU in Xcode as a project for a signals class I'm taking,and I can open it just fine in AU Lab from my components folder, but I cant seem to open it in a DAW. Can anyone help me get to the bottom of this? Could it be a setting in the .plist file? There is no error in the code because the AU works perfectly in AU lab. If anybody has an idea help would be much appreciated and I can supply any information you might need.

回答1:

I made the investigation I mentioned in my comments thus I'm writing a real answer now.

I confirmed my suspicions. In case you don't have the issue with 32/64 bits build mode (like others said), you may well have the same issue as I had.

GarageBand and Mainstage (presumably others) don't read the keys of the AudioComponents key of the bundle's plist. They only read the deprecated crappy Carbon resources.

I have a proof of this (at least on my system: Lion, GarageBand 6.0.5):

• most of the AU I've downloaded only provides Carbon resources and don't have AudioComponents key in their plist (because it was the way to go before Lion and only noob like me ignores this fact)
• as soon as I properly added the Carbon resources to my unit, it starts appearing in GarageBand and MainStage (youhou!)

If you started your project from a copy of TremoloUnit or some others project Apple provides, you must fix them because their projects are screwed. Obviously, the poor soul who maintains them is as noob as I am about AudioUnit programming, he believed (like I did) that those horrible Carbon things from a dark age must be completely deprecated by now and he unchecked them from the build phase. Since the resulting AU loads fine in AU Lab and validates fines with auval he was happy and committed his work.

To fix the project, you must add the Resource source file (the one ending with .r) to the build phase (it is already in the project). If you click on it from the file inspector, XCode will figure itself (from the file extension) that you want to build hideous Carbon Resources. After that, you will certainly have obscure build failures because the Rez search path is wrong. You must also double check that .r file describes the same things as your AudioComponents because Apple's sample project AUPinkNoise was broken on that topic (the 4 letters code of the sub-type had a mismatch between the plist and the .r resource source)

Congratulation to Apple to build a validation tool that just ignores how most Apple products currently load AudioUnit.

回答2:

This All Things Arcane article is a great place to start.

Additionally, for xcode 5.x and now current (2015-05) examples from Apple there are a few extra steps that may also help:

1. In "Build Settings, Apple LLVM - Preprocessing" add the Preprocessor Macro "CA_USE_AUDIO_PLUGIN_ONLY=0" which enables the ability to use the old style entry point in your .r file and .exp file (allows you to add _SinSynthEntry as well as _SinSynthFactory)

2. Remove and re-add "AUDispatch.cpp" and "AUDispatch.h" to your project (this is to resolve the missing "CMgr_AudioUnitBase…" link references)

3. If you are building for OS X 10.8 or older you have to modify Apple's AUBase.cpp to carve out kAudioUnitProperty_NickName which was added in 10.9 conditionally compiling based on OS X version. An example:

#if (MAC_OS_X_VERSION_MIN_REQUIRED > MAC_OS_X_VERSION_10_8)    //ADD ME!
    case kAudioUnitProperty_NickName:
        ca_require(inScope == kAudioUnitScope_Global, InvalidScope);
        outDataSize = sizeof(CFStringRef);
        outWritable = true;
        break;
#endif                                                         //ADD ME!

回答3:

As @admsyn suggested, the issue is most likely that you are building a 64-bit plugin, which Xcode will do for you by default. You should either build a 32/64 bit Universal Binary (in both Debug and Release builds), or just 32-bit.

Also it probably helps to run auval -v to verify the AU, just to make sure that something isn't wrong.