AU under XCode 4.4


Has anybody had any success building AU plugins under XCode 4.4? I’m using the GM for that version of XCode, and I’m really struggling. All of the AU support files have disappeared from the /Developer folder (which has disappeared in its entirety) and appear to have been replaced by files buried inside an AudioUnit.framework deep inside the XCode bundle. Apple being Apple, most of the names have changed.

I’ve made a lot of the errors go away, but I’m getting nailed now by an error in Compiler spits the bit on:

#include "AUMIDIEffectBase.h" #include "MusicDeviceBase.h"
and gets worse from there.

I’ve spoken with another developer friend who’s been mystified ever since everything went inside the XCode bundle (4.3.3?) so I wonder if anyone has had any luck.

Thanks much


4.4? The latest is 4.3.3 isn’t it?

There’s already a thread about it here:


[quote=“jules”]4.4? The latest is 4.3.3 isn’t it?
4.4 is in Gold Master form and is available to developers. I’m unsure of the differences, but Apple indicates it will be required for Mountain Lion target development. Given that Mountain Lion is in GM form (I’m using it, too) I’d assume 4.4 will be live before the end of the month.

Thanks for the link to the topic. I’ll resume there.


Oh god, they’re not changing everything yet again, are they…?


I didn’t use 4.3.x. 4.4 is my first step away from 3.2.6. I’ll try to keep my grumbling down, since it’s not good for my blood pressure, but …

I hate to tell you this when you’re looking forward to a nice weekend and all. But 4.5 Beta is already up and available. Not going there for a while, I assure you.


Oh, well that’s a relief. I don’t suppose much will have changed since 4.3 then, that other thread probably has the info you need.


XCode 4.5 (perhaps also 4.4) has much improved c++11 support, with LLVM 4.1. At least that was great news to me. Overall stability seems good


Hi there,

I lost two days with this &@%ù!# AU issue… trying to make my AU plugins compiling without success :evil:

Reading this post ( I just found this tech note from Apple: “Audio Unit AUPlugIn - Updating an existing Audio Unit for Mac OS X Lion”. Jules, maybe helpful to migrate the AU wrapper?



Sorry, I post too quickly and didn’t see the other thread talking about that. :arrow:


I’m now using 4.4 and everything seems to compile fine. :slight_smile:

After making 2 changes to the AU sdk files, but that has nothing to do with 4.4 specifically:

AUBase.h line 698:
comment out these lines to get rid of multiple base class error
// virtual OSStatus MIDIEvent( UInt32 inStatus,
// UInt32 inData1,
// UInt32 inData2,
// UInt32 inOffsetSampleFrame) { return kAudio_UnimplementedError; }

AUCarbonViewBase.cpp line 257:
add static cast
HISize originalSize = { static_cast(mBottomRight.h), static_cast(mBottomRight.v) };


Hi Mikey. You mention you somehow found the headers etc… I can’t find them at all. Where in the bundle did you find them?


You’ve got to put stuff in there yourself. Apple hasn’t even made an installer for the kit (growl, grumble).

Anyway, inside the bundle, find [color=#0000FF]/Contents/Developer.[/color] Inside Developer make a new folder (if it isn’t there) named [color=#0000FF]Extras[/color]. Assuming you’ve grabbed the audio support package package (Audio Tools for XCode, Feb 2012), drag the [color=#0000FF]CoreAudio[/color] folder from Apple into the [color=#0000FF]Extras[/color] folder you just created. That will give you all the headers and stuff you need. Too bad there’s a bug you’ll still have to fix (more grumbling). In the CoreAudio folder that you just copied, find AUMIDIEffectBase.cpp. At line 154, change:

to this:

There are probably other and better ways to do this, but it’s been working for me. By the way, just in case you didn’t know, XCode has an environment variable named [color=#0000FF]DEVELOPER_DIR[/color]. Depending on what version of XCode you’re using, it will always point to the Developer folder, whether it’s inside the bundle or in the old place. Then you can put [color=#0000FF]$(DEVELOPER_DIR)/Extras[/color] into your include path and it will always find the headers.

Apple has known about this ambiguity for a while (I’m not the only person to complain) but they still haven’t fixed it. Feel free to help me complain.


Aha. I can copy those files. Thanks.

But I assumed you where using the SDK from July specially made for Xcode 4.4. That package mysteriously contain exactly zero sources & headers.

Alright, as far I have found no one who hasn’t done it this way so I suppose I have to go that route too. Thanks for your help.

(And no, I’m not going to waste my effort complaining… to Apple!? Their engineers listen, they really do, but as it is elsewhere it’s not the engineers who’s in charge.)


So the Core Audio Utility Classes moved under Xcode 4.4 and Xcode 4.5. There’s a lot of disparate information on how to get AudioUnits up and running with those versions of Xcode. Here is my “step by step” of what to do under those versions of Xcode. Jules - maybe you want to promote this thread/post?

[]Make sure you’re running Xcode 4.4 or 4.5. Later should work, but I’ve not tested them.[/]
[]Get the “Core Audio Utility Classes” ZIP file from Apple using the “Download Sample Code” button at The current version is Version 1.01 released on 2012-06-26.[/]
[]The zip file contains installation instructions. It assumes that the CoreAudio folder will be placed (hopefully permanently) in the /Library/Developer folder.[/]
[]Patch the Core Audio Utility files with the attached patch file. It fixes compilation errors and warnings, and a MIDIEvents base-class error.[/]
[]Optional: To maintain backward compatibility, you may do the following. The current Introjucer assumes that the following has been done.
]Navigate to the /Applications/ folder.[/]
]Create an Extras directory if said directory does not exist.[/]
]Change directory to the new /Applications/ directory.[/]
]If a CoreAudio directory or symlink exists (with full path /Applications/, remove it (back it up first, though!).[/]
]Create a symlink via sudo ln -sv /Library/Developer/CoreAudio /Applications/[/]
]Note that modifying anything in the /Applications/ directory can invalidate Xcode’s digital signature, which may bring about strange behaviour with GateKeeper or the App Store. It has not been a problem for me as the digital signature seems to be validated only once during App Store installation… but you have been warned.[/][/list][/][/list]

A freshly-made Introjucer project should now compile cleanly (sans a few 10.8 deprecation warnings) and validate via auval.

Jules - do you want a friendly wager on whether /Library/Developer remains the home of CoreAudio? Box of pizza or keg of beer? :roll:



Excellent stuff, thanks Andrew! I think I’ll copy this into a sticky post…


nice! But it seems one of the three patches don’t work, or did i something wrong (first time i use the patch tool?!)

[code]Christians-Mac-mini:Developer christian$ patch -p0 -i patch.txt
patching file CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.h
Hunk #1 FAILED at 700.
1 out of 1 hunk FAILED – saving rejects to file CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.h.rej
patching file CoreAudio/AudioUnits/AUPublic/AUCarbonViewBase/AUCarbonViewBase.cpp
Hunk #1 succeeded at 166 with fuzz 2.
Hunk #2 succeeded at 260 with fuzz 2.
patching file CoreAudio/AudioUnits/AUPublic/OtherBases/AUMIDIEffectBase.cpp
Christians-Mac-mini:Developer christian$ cat CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.h.rej

*** 700,711 ****
// ________________________________________________________________________
// ________________________________________________________________________
// music device/music effect methods – incomplete

  • /*! @method MIDIEvent */
    virtual OSStatus MIDIEvent( UInt32 inStatus,
    UInt32 inData1,
    UInt32 inData2,
    UInt32 inOffsetSampleFrame) { return kAudio_UnimplementedError; }
  • /*! @method SysEx */
    virtual OSStatus SysEx( const UInt8 * inData,
    UInt32 inLength) { return kAudio_UnimplementedError;}
    — 700,711 ----
    // ________________________________________________________________________
    // ________________________________________________________________________
    // music device/music effect methods – incomplete
  • /*! @method MIDIEvent
    virtual OSStatus MIDIEvent( UInt32 inStatus,
    UInt32 inData1,
    UInt32 inData2,
    UInt32 inOffsetSampleFrame) { return kAudio_UnimplementedError; }
  • */
    /*! @method SysEx */
    virtual OSStatus SysEx( const UInt8 * inData,
    UInt32 inLength) { return kAudio_UnimplementedError;}


btw, its working anyway, great job!


was wrestling with AUs on XCode 4.5 and just about to tear out my hair - then found this useful thread - so thanks for this guys!

I can contribute the following from my experience: (XCode 4.5.2 and CoreAudio utility classes Version 1.0.2, 2012-10-31)

  1. If like me you are hesitant about messing up XCode, you can avoid having to copy CoreAudio utility classes into your XCode bundle by
    []copying them to /Library/Developer/Extras/CoreAudio instead[/]
    []in XCode, add a new sourcetree location (via preferences, locations). Name it LIBDEV_DIR and point it to /Library/Developer[/]
    []then edit the plugin’s project.pbxproj file generated by the Introjucer and replace the string DEVELOPER_DIR with LIBDEV_DIR[/]
    []@Jules: It would be really nice if Introjucer offered a setting to provide your own value for DEVELOPER_DIR, so this manual step becomes unneccessary[/][/list]

  2. I also needed to add an extra include header dir in Introjucer that an AU build seems to need:
    []@Jules: would be great if this include could be added to the default plugin introjucer project as well? (with DEVELOPER_DIR instead of LIBDEV_DIR is OK as well)[/][/list]

  3. I found that the patch of AUBase.h was not needed. But you do need the ones for AUCarbonViewBase.cpp, AUMIDIEffectBase.cpp

  4. there is a small bug in when compiling an AU synth:
    the line at 784 calls a base class member func ShouldBypassEffect(), but MusicDeviceBase lacks this method

else if (ShouldBypassEffect()) { juceFilter->processBlockBypassed (buffer, midiEvents); }

the fix that seems to work is

#if !JucePlugin_IsSynth else if (ShouldBypassEffect()) { juceFilter->processBlockBypassed (buffer, midiEvents); } #endif



FWIW, at AES last month I met briefly with Michael Wong (the audio developer liaison at Apple). Among other things, I brought up this very issue. He seemed quite surprised to hear about it, and perhaps not happy that the SDK hadn’t been tested. While he said he’d check into it, I doubt there will be a resolution unless he gets more griping from people (hint, hint). It’s definitely about the squeaky wheel down in Cupertino.


Thanks, I’ll add the extra path and #ifdef. Haven’t time to think about your LIBDEV_DIR idea right now, though it sounds sensible!