Mojo Lama

Of the many changes introduced with Xcode 4, one of the least talked about is its new template format. A number of online posters have commented that the new format is difficult to work with. Personally, I don’t quite understand why: combining XML property list configuration mojo with a class-like inheritance scheme, it is extremely flexible and clearly rooted in the thinking behind the Cocoa APIs themselves. Perhaps the difficulty is simply that the new template format is, well… new. Of course, it doesn’t help that it’s also completely undocumented by Apple.

The big stumbler for Audio Unit developers, however, is that while most of the existing 3.x templates were converted to the new format and bundled with the first few (Snow Leopard-compatible) releases of Xcode 4.0, somewhere during the rollout of OS X 10.7 (“Lion”) the Audio Unit templates got yanked. Apple has – so far – not had much to say on this, and workarounds have not been too easy to come by either (one exception being Fred Ghilini’s very useful post over at Sample And Hold.)

Fortunately, reverse-engineering the new format from existing templates isn’t all that difficult, and a few enterprising individuals have made good progress in this direction. If you really want to get a jump on the new templates, a quick perusal of Bob McCune’s Creating Custom Xcode 4 File Templates, boreal-kiss’ A Minimal Project Template for Xcode 4 and yonishin’s very handy reference About Xcode 4 Project Template (How To Create Custom Project Template) should bring you up to speed nicely.

The thing of it is, once you have a grip on how the new format works, it’s a pretty straight shot to restoring the AU templates, updating them to compile with Lion (per Apple’s Technical Note TN 2276), and maybe even making a few tweaky improvements while you’re at it.

So buckle up, here’s what you need:

• The latest version of Apple’s Core Audio SDK;
• A copy of Apple’s StarterAUEffectWithCocoaUI Sample Code project (optional); and
• Copies of the AU templates from a Snow Leopard-compatible version of Xcode 4.

Getting The SDK and Sample Code Files

The Core Audio SDK used to live inside the /Developer directory that was created when the Xcode installer ran. Beginning with Xcode 4.3, however, this is no longer the case: Xcode itself now comes packaged as an application bundle, and to keep the size of that bundle manageable for downloading from the App Store, many of the tools and extras previously installed to /Developer now require separate downloads.

Getting those files is simple enough, though: the latest Core Audio SDK – as well as older, Snow Leopard-compatible versions of Xcode 4 – can be gotten from Apple’s Developer Connection, here. Alternatively, if you’re already using Xcode 4.3 or later just go to the Xcode menu and select Open Developer Tools −> More Developer Tools, which gets you to the same place.

You’ll need an Apple Developer ID, of course, but getting one – if you haven’t one already – is a simple, free registration away (repeat: you do not need a paid Developer account to access this stuff.)

[UPDATE: as of OS 10.8 (“Mountain Lion”) the Core Audio SDK files have been moved to the OS X Developer Library, and can be gotten here.]

The StarterAUEffectWithCocoaUI sample code, also from Apple, can be found here.

Getting The Snow Leopard Xcode 4 AU Templates

There are actually a couple of ways to get your hands on the Xcode 4 Snow Leopard templates. If you’re the kind of person who keeps old Xcode installations lying around on a spare drive (doesn’t everyone?) and one of those installations happens to be some flavor of Xcode 4.0, 4.1 or 4.2 – and its the Snow Leopard version, not Lion – then you already have the templates. Just jump inside the folder housing your Xcode archive – what would have been /Developer in its former life – and navigate down through Library/Xcode/Project Templates/Mac/ and then on to either System Plug-in or Application Plug-in (the location of the AU templates seems to have varied slightly from version to version of Xcode 4, as if they were already thinking about leaving town).

If you don’t have a suitable version of Xcode 4 on hand, you’ll need to get one from the Developer Connection link above. Be prepared to perform some trickery in order to run the installer if Lion is your only OS, these being Snow Leopard-compatible downloads.

A Few Preliminaries On The New Template Format

The Template Folder. The new templates are distinguished from the old by, among other things, a .xctemplate extension for the template folder. Take a look inside each of the three Audio Unit template folders (formerly!) provided by Apple and you will likely find some mix of the following:

• a TemplateIcon.icns file
• a TemplateInfo.plist file
• some combination of source files

The TemplateInfo.plist File. Most of the work that goes into defining a template centers around the TemplateInfo.plist file. This is a standard Apple property list file that specifies what the template does – and how it does it – when you run it from the Xcode New Project wizard.

Placeholders in the Source Code Files. A quick scan through some of the source code files included with the templates will reveal the liberal use of placeholders (actually, expansion macros) for those parts of the code that will be personalized to your project when you run the template wizard.

For example, “___PACKAGENAMEASIDENTIFIER___.h” refers to the main header file for a new project. That means if you create a new project called BingoTheChimp, all occurrences of ___PACKAGENAMEASIDENTIFIER___.h (both the file name itself as well as any references to it from other files) will show up in your project as BingoTheChimp.h.

Note, too, the new Apple standard of 3 underscores at the front and back end of these placeholder macros, replacing the << and >> markers used in the old Xcode 3.x templates.

For this walk-through we’re going to focus on audio effects, which are typically based on Apple’s AUEffectsBase class. And since AUEffectsBase subclasses AUBase, that means we’ll be working with two templates: Audio Unit Base.xctemplate and Audio Unit Effect.xctemplate.

Enough talk. Let’s walk.

Setup the SDK files

Decide where you’d like to keep your copies of the Core Audio SDK files, then take the CoreAudio folder that comes with the SDK download and put it there. I’ve set mine up as:

/Development/AppleDevExtras/CoreAudio

…but you can actually put it wherever you like. I don’t recommend using /Developer, though: prior versions of Xcode used to install to this folder, overwriting it’s contents in the process. Will future versions of Xcode do the same? I have no idea, but you don’t want to find out the hard way.

Set Up The Xcode Template Folders

Navigate to:

~/Library/Developer/Xcode

and create a new folder (if it isn’t there already) called “Templates”. “Templates” will now show up as a category in the New Project wizard, and any .xctemplate folders within it will show up as templates. But NOTE: you must call the folder “Templates” – call it anything else and it won’t work.

Now place the Xcode 4 Audio Unit template folders – there are three of them: Audio Unit Base.xctemplate, Audio Unit Effect.xctemplate and Audio Unit Instrument.xctemplate – into this new Templates folder.

Alternatively, you could create a subfolder within Templates called, for example, “Audio Units” and put them there. The subfolder would then show up as a additional category in the New Project wizard.

One more thing: if you’re thinking, as I did, that it might be nice to keep the templates in your day-to-day project development directory, and just place aliases to them in the Templates folder, sorry: that won’t work. The symlinks will simply not show up in the Project Wizard.

Some Additional Files For The Audio Unit Effect.xctemplate Folder

There are a couple of different ways you can go about defining templates in the new format.

One method involves adding blocks of code directly to TemplateInfo.plist. If you open the TemplateInfo.plist file inside Audio Effect Base.xctemplate and take a look (under Definitions) at the entries for ___PACKAGENAMEASIDENTIFIER___.cpp, you can get a feel for how this is done. (Note you will need to view the file in a text editor – as plain vanilla XML – in order to see the code blocks in their entirety. Xcode’s plist viewer only displays the first line of each block.)

Me? I like to see all my code in one place and prefer to add file templates directly to the project template folder. So that’s what I’m going to describe here. The file templates we want to add – because the Audio Effect Base template currently lacks them – are those for the Info.plist and .cpp files.

Now, if you have a pre-4.0 version of Xcode on hand, you could certainly grab copies of these files from the old-style templates in /Developer/Library/Developer/Xcode/Templates/etc, replace all instances of the old macro brackets (“<<” and “>>”) with three underscores (“___”), then make the changes we outline below.

But there’s any easier way:

• Download a copy of Apple’s StarterAUEffectWithCocoaUI sample code project from the link mentioned earlier.This particular sample project is notable in that it contains Xcode project files for both Snow Leopard and Lion. Hint: the Lion project files have already been, er, updated for Lion.
• Open the MyGreatAUEffectWithCocoaUI(Lion) project folder and take copies of the following files:

  
  Info.plist
  MyGreatAUEffectWithCocoaUI.cpp
  

• Drop the copies into the Audio Unit Effect.xctemplate folder. Then rename them, respectively, as:

  
  ___PACKAGENAMEASIDENTIFIER___-Info.plist
  ___PACKAGENAMEASIDENTIFIER___.cpp
  

Next we need to make some modifications to these files as well as to some of the others that came with the Snow Leopard templates. Let’s go right down the list.

Modify The Info.plist File

One of the requirements for updating Audio Units to Lion is the addition of an AudioComponents dictionary to the Info.plist file (Lion uses this dictionary in place of the ‘.r’ resource file formerly used by Snow Leopard and earlier. You can retain the .r file for backward compatibility, but that’s optional.)

Well, we’ve just saved ourselves some work: because we grabbed our Info.plist file from Apple’s own Lion-compatible sample code, the AudioComponents dictionary has already been set up for us. All we need to do is make a few adjustments:

Inside the Audio Unit Effect.xctemplate folder,

• Open the ___PACKAGENAMEASIDENTIFIER___-Info.plist file we just created.
• Expand the AudioComponents dictionary, then expand its Item 0 entry.
• In the description field, change “MyGreatAUEffectWithCocoaUI AU” to “___PACKAGENAMEASIDENTIFIER___ AU”.
• In the factoryFunction field, change “MyGreatAUEffectWithCocoaUIFactory” to “___PACKAGENAMEASIDENTIFIER___Factory” (no space before ‘Factory’).
• In the manufacturer field, replace ‘Demo’ with your 4-character manufacturer code.
• In the name field change “<whateveritcurrentlysayshere>: MyGreatAUEffectWithCocoaUI” to “___ORGANIZATIONNAME___: ___PACKAGENAMEASIDENTIFIER___”.
• Leave the subtype field (‘Pass’) as is for now.

That’s basically it for the AudioComponents dictionary. There are two more changes to make in Info.plist:

• In the Bundle identifier field, change com.audiounit to com.[yourcompanyname].
• Add a new entry, of type ‘string’, with its key set to ‘Copyright (human-readable)’ and its value set to ‘Copyright © ___YEAR___ ___ORGANIZATIONNAME___ All rights reserved.’

And so we’re done with Info.plist. My completed file looks like this (yours should look similar):

• Save and close.

Modify The .cpp File

Still in Audio Effect Base.xctemplate,

• Open the ___PACKAGENAMEASIDENTIFIER___.cpp file.

Another requirement for updating Audio Units to Lion is to replace:

COMPONENT_ENTRY(___PACKAGENAMEASIDENTIFIER___)

with:

AUDIOCOMPONENT_ENTRY(AUBaseFactory, ___PACKAGENAMEASIDENTIFIER___)

Once again, because we’ve copied our .cpp file from a Lion-compatible sample project, the correct entry has already been set up. The only change we need to make is to replace ‘MyGreatAUEffectWithCocoaUI’ with our package name identifier macro. But we’re going to do that for the entire file anyway:

• Run a global search for all instances of “MyGreatAUEffectWithCocoaUI” and replace them with with “___PACKAGENAMEASIDENTIFIER___”.
• Next, scroll down to the GetProperty and GetPropertyInfo method blocks and completely replace them with the following:

  
  //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  //	___PACKAGENAMEASIDENTIFIER___::GetPropertyInfo
  //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  OSStatus			___PACKAGENAMEASIDENTIFIER___::GetPropertyInfo (AudioUnitPropertyID	inID,
                                                          AudioUnitScope		inScope,
                                                          AudioUnitElement	inElement,
                                                          UInt32 &		outDataSize,
                                                          Boolean &		outWritable)
  {
  	return AUEffectBase::GetPropertyInfo (inID, inScope, inElement, outDataSize, outWritable);
  }
  
  //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  //	___PACKAGENAMEASIDENTIFIER___::GetProperty
  //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  OSStatus			___PACKAGENAMEASIDENTIFIER___::GetProperty(	AudioUnitPropertyID inID,
                                                          AudioUnitScope 		inScope,
                                                          AudioUnitElement 	inElement,
                                                          void *			outData )
  {
  
  	return AUEffectBase::GetProperty (inID, inScope, inElement, outData);
  }
  

These versions of the methods are taken (and adapted) from the old Xcode 3.x templates (all they actually do here is call the superclass’ GetProperty and GetPropertyInfo methods.)

The reason for our making this switch: without it, Logic Pro (Logic Pro!) will refuse to recognize your plugins. Don’t ask. I don’t know.

• Finally – and this step is optional, but naturally we want a nice block of copyright and version information – scroll to the top of the file and replace:

  
  File: MyGreatAUEffectWithCocoaUI.cpp
  Abstract: Audio Unit class implementation.
  Version: 1.0
  
  

  with:

  
  File:		___FILENAME___
  
  Version:	1.0
  
  Created:	___DATE___
  
  Copyright:  Copyright ___YEAR___ ___ORGANIZATIONNAME___. All rights reserved.
  
  

• Save and close.

Modify The .exp File

Hop over to Audio Unit Base.xctemplate, open the .exp file and make the following change:

• Change

  
  ____PACKAGENAMEASIDENTIFIER___Entry
  
  

  to

  
  ____PACKAGENAMEASIDENTIFIER___Entry
  ____PACKAGENAMEASIDENTIFIER___Factory
  

IMPORTANT: Note the additional leading underscore for both macro entries (because the final replacement text needs to include a single leading underscore.) Also note there is an additional return after the last line (not shown here in the HTML, unfortunately.) Both are required.

That, btw, takes care of requirement #3 for updating AUs to Lion.

Modify the Version.h File

In Audio Unit Base.xctemplate:

• open the ___PACKAGENAMEASIDENTIFIER___Version.h file and replace ‘Demo’, in the ___PACKAGENAMEASIDENTIFIER____COMP_MANF define, with the same four-character manufacturer code you used in the Info.plist file (except in this instance be sure to retain the surrounding single quotes).
• Save and close.

All that’s left to do now is modify the TemplateInfo.plist files for both AUBase and AUEffectBase.

Modify the AUBase TemplateInfo.plist file

In Audio Unit Base.xctemplate, open the TemplateInfo.plist file and do the following:

1. Project Section

• Expand the Project disclosure triangle
• Add a new dictionary item called ‘Configurations’ and give it two dictionary sub-items: one called “Debug” and another called “Release”. Then add the following item to both Debug and Release:

  
  ONLY_ACTIVE_ARCH [type: string] NO
  

• Still under Project, expand the ‘Shared Settings’ disclosure triangle and add the following 2 items:

  
  ARCHS [type:string] $(ARCHS_STANDARD_32_64_BIT)
  SDKROOT [type:string] Current Mac OS
  

The entire Project section should now look something like this:

• Close the Project disclosure triangle

2. Nodes Section

• Expand the Nodes disclosure triangle and remove the following 3 items:

  
  ___PACKAGENAME___-Info.plist:audioUnit
  ___PACKAGENAME___-Info.plist:NSHumanReadableCopyright
  ___PACKAGENAMEASIDENTIFIER___.cpp
  

• Still under Nodes, add a new item (type: ‘string’) with a value of ___PACKAGENAMEASIDENTIFIER___-PREFIX.pch
• Further down, but still under Nodes, change the entries for AUDebugDispatcher.h and AUDebugDispatcher.cpp to AUPlugInDispatch.h and AUPlugInDispatch.cpp, respectively (watch the spelling here: that’s cap ‘P’, cap ‘I’, cap ‘D’)

The Nodes section should now look something like this:

• Close the Nodes disclosure triangle

3. Definitions Section

• Expand the Definitions disclosure triangle
• Scrolling down a bit, change the entries for AUDebugDispatcher.h and AUDebugDispatcher.cpp to AUPlugInDispatch.h and AUPlugInDispatch.cpp, then expand their disclosure triangles and change the final section of each of their Paths – the AudioUnits/AUPublic/Utility/AUDebugDispatcher part – to AudioUnits/AUPublic/AUBase/AUPlugInDispatch (obviously, you’ll want to retain the .cpp and .h file extensions; we’ll replace the root part of the path – the part that points to the location of your SDK folder – a few steps down.)

The reason for making this switch between AUDebugDispatcher and AUPlugInDispatch is that Lion no longer uses AUDebugDispatcher – in fact, it’s no longer included in the Core Audio SDK – whereas the addition of AUPlugInDispatch is another requirement for updating Audio Units to Lion.

And with this step completed, all four of those requirements have now been satisfied.

• Jumping back up towards the top of the Definitions section, remove the following item:

  
  ___PACKAGENAME___-Info.plist:audioUnit CFBundleDevelopmentRegion
  

We’re providing our own Info.plist file in the template folder, so these entries aren’t needed.

• Still under Definitions, add a new dictionary entry called ___PACKAGENAMEASIDENTIFIER___-PREFIX.pch and give it a Path (type: string) of ___PACKAGENAMEASIDENTIFIER___-PREFIX.pch, and a TargetIndices array containing a sub-entry ‘Item 0’ (type: string) set to a value of ‘0’. (If reading that last sentence makes your head hurt, have a look at the screen shot below – it’s actually simpler than it sounds – then go ahead and just copy/paste the TargetIndices array from one of the other ___PACKAGENAMEASIDENTIFIER___ dictionary entries)

Finally, we need to change the SDK Path (and we’ll want to change the PathType) for all those SDK files listed under Definitions. Here’s the easy way:

• Run a search for:

  Extras/CoreAudio

  and replace all instances with:

  /[FullPathToYourCoreAudioSDKFiles]/CoreAudio

  Hint: make sure you include the leading ‘/’ in your replace string or you’ll end up with a full set of empty SDK files added to your project.

  Then, run another search for:

  DeveloperDir

  and replace all instances with:

  Absolute

The choice of PathType is a personal one (the other choices are ‘Relative’ and, obviously, ‘DeveloperDir’.) I find ‘Absolute’ PathTypes to be the most reliable so I tend to choose them over ‘Relative’ ones.

‘DeveloperDir’ will in fact work here just fine, but something tells me Xcode may use this PathType for internal purposes. Given that the /Developer directory has recently been moved from the root drive to inside the application bundle – who knows where it may travel in the future? – I’m not especially enthusiastic about using it to map to my SDK files. So, ‘Absolute’ it is.

The Definitions should now look something like this:

Note the AUPlugInDispatch entries, which I’ve expanded in the screen grab. The other SDK files will have similar entries and, obviously, the paths to your SDK files will be different than mine.

• Save and close the TemplateInfo.plist file

Modify the AUEffectBase TemplateInfo.plist file

Finally, open the TemplateInfo.plist file in Audio Unit Effect.xctemplate and make the following changes:

1. Options Section

• Expand the Options disclosure triangle, then expand the Item 0 and Units dictionaries, then further expand the true and false sub dictionaries.
• Expand the Definitions dictionaries under both true and false, and remove the ___PACKAGENAMEASIDENTIFIER___.cpp:middle items from both.
• Close the Options disclosure triangle.

2. Nodes Section

• Expand the Nodes disclosure triangle and remove the suffix “:middle” from the entry for ___PACKAGENAMEASIDENTIFIER___.cpp
• Also under Nodes, add a new item (type: string) with the value ___PACKAGENAMEASIDENTIFIER___-Info.plist
• Close the Nodes disclosure triangle.

3. Definitions Section

• Expand the Definitions disclosure triangle, then expand the dictionary item for ___PACKAGENAMEASIDENTIFIER___.cpp
• Remove the two string entries labeled “Beginning” and “End”
• Add a new Path string item with the value ___PACKAGENAMEASIDENTIFIER___.cpp.
• Still under Definitions, add a dictionary item for ___PACKAGENAMEASIDENTIFIER___-Info.plist with a Path string set to ___PACKAGENAMEASIDENTIFIER___-Info.plist and an empty TargetIndices array containing an Item 0 string set to ‘0’.

[UPDATE: What you want to do here is add the TargetIndices array but do not add the Item 0 string to it. Specifying an empty TargetIndices array will prevent the Info.plist from being added to the Copy Bundle Resources build phase (see my original reference to this issue below, under ‘Try It Out!’). Thanks to TJ Usiyan for the tip.]

• Finally, we need to change the SDK Path, as well as the PathType, for AUEffectBase.h and AUEffectBase.cpp, just as we did for the SDK files in Audio Unit Base’s TemplateInfo.plist file. There are only two files to change here, so you may as well just type the changes by hand. Once again, you need to change Path (for both files) from:

  Extras/CoreAudio

  to:

  /[FullPathToYourCoreAudioSDKFiles]/CoreAudio

  …making sure to include the leading ‘/’ in your replace string.

  And then change PathType from:

  DeveloperDir

  to:

  Absolute

Save and close the TemplateInfo.plist file.

Try It Out!

At this point you should be able to launch the New Project wizard in Xcode, select ‘Audio Unit Effect’ from the Mac OS X −> Templates project category, give your project a name, save it to a location of your choice and build a working component.

Well, actually, you’ll most likely get a single compiler warning to the effect that the ‘Target may contain unnecessary Build Files.’ The reason: our Info.plist file is being added to the Copy Bundle Resources phase.

Honestly, I haven’t figured out how to turn this option off from within the TemplateInfo.plist file (if and when I do, I’ll post an update here.) In the meantime, the fix is simple enough: select the project’s Target in the Xcode Project Navigator, click the Build Phases tab, open the Copy Bundle Resources disclosure triangle and delete the Info.plist file from the build phase. [UPDATE: No longer necessary; see fix above, under ‘Modify the AUEffectBase TemplateInfo.plist file.’]

Another thing to watch out for: I’ve had several emails regarding corrupt Info.plist files, something I myself experienced while writing this post. In every case I’ve investigated so far, the cause(s) turned out to be typographical coding errors.

If you run into this, the first thing to check is the generated Info.plist file (~/Library/Developer/Xcode/DerivedData if you’re running Mountain Lion; inside the Xcode project file if you’re running anything earlier). If the reported file size is zero bytes, that’s a clear indication that the file is not corrupted per se, but is simply empty. And that in turn points back to the TemplateInfo.plist file in charge of creating the file. Check it carefully for typos: I’ve seen everything from easy-to-miss spelling errors (lower case ‘i’ in ‘Info.plist’) to hidden text that’s been accidentally pasted into the path key field (hint: take a look at the plist file in a text editor to ferret this out). Any problems here will result in an empty Info.plist file. But Xcode won’t tell you this — it will simply report the file as being ‘corrupt’.

Finally – the 800 lb. gorilla in the room – will these templates work on Mountain Lion?

Yes, they will!

Sure, you’ll see a couple of compiler warnings (specifically, ComponentBase’s RegisterComponent and SetDefaultComponent methods are being deprecated as of OS 10.8) but other than that you’ll be all set to hit the ground running when Apple releases its new OS later this month.

Tweaks and Improvements

And that’s it. We can stop right here, make backups of our new templates, store them in a safe place and we’re all done.

Except now we’re starting to feel our oats a little bit and thinking maybe there are a couple of small refinements we’d like to make to the templates. Well, let’s indulge!

One thing about the old templates that always annoyed me was having to remember to overwrite the subtype code in various locations after the project wizard did its thing. A prompt to enter the subType code when creating the project, which then got populated to all the the necessary places, might be a friendlier touch.

Well, we can do that! Here’s how:

• Back in Audio Effect Base.xctemplate, re-open the TemplateInfo.plist file.
• Expand the Options array and add a new dictionary item to it.
• Add the following entries to the new dictionary:

  
  Identifier [type: string] effectSubType
  Name [type: string] Effect SubType
  Description [type: string] A Unique AUEffect SubType code
  Required [type: string] YES
  NotPersisted [type: string] YES
  Type [type: string] text
  

• Next, open ___PACKAGENAMEASIDENTIFIER___-Info.plist, expand the AudioComponent dictionary item, and replace the value for subtype (currently ‘Pass’) with:

  ___VARIABLE_effectSubType:identifier___

• Finally, open ___PACKAGENAMEASIDENTIFIER___Version.h in Audio Unit Base.xctemplate and replace ‘Pass’, in the subType define#, with the same ___VARIABLE_effectSubType:identifier___ macro.
• Save and close all 3 files.

Now rerun the New Project wizard and create a new Audio Effect project. This time, you should be greeted – in the same window where you enter the name of your project – with a field for entering the subtype code (and notice that you cannot proceed to saving the project until you do so).

Enter the subtype code and save your project. Then, when the Project Navigator loads, take a look at Info.plist and Version.h to view your handywork. Neat, eh?

Let’s make one final adjustment to our new templates. Notice how all the SDK files are being lumped together in the Project Navigator under a single “AUPublic” group. A tidier arrangement might be to have file groupings that reflected the hierarchy of the original SDK directories. Let’s do that now:

• Open Audio Unit Base.xctemplate and re-open its TemplateInfo.plist file.
• Under Definitions, expand the disclosure triangles for each SDK file and change the Group value to point to the file’s actual containing subfolder in the SDK directory. For example, for CAAUParameter.cpp and CAAUParameter.h change:

  
  AUPublic
  

  to:

  
  PublicUtility
  

…and so on, for all the SDK file entries.

• Repeat for the 2 SDK entries in Audio Unit Effect.xctemplate’s TemplateInfo.plist file.
• Save and close both files.

 

Now when you create a new Audio Unit Effect project, all your SDK files will be neatly sub-grouped in the Project Navigator.

And there you have it. So, who says the new templates are difficult to work with?