Archives for : February2012

The Audio Tools for Xcode 4.3 switcharoo

It’s great that Xcode 4.3 packs all the SDKs and essential helper apps into its own app bundle, which makes Mac App Store distribution more practical and elegant, and brings Apple into compliance with its own rules for MAS distribution. Adapting Xcode into this form is also a prerequisite for eventually delivering an iPad version, which I continue to believe is one of those things that may be impossible in the near-term and inevitable in the long-term.

However, this radical realignment means Xcode 4.3 has surely broken something in every Mac and iOS programming book. Lucky for me that mine are still in the works, though very close to being done. I updated the “Getting Started” material in iOS SDK Development this week to handle the changed install process, which along with the new chapter on testing and debugging should be going out to beta readers Real Soon Now.

And then there’s Learning Core Audio, where the situation is a little more involved. For one thing, the Core Audio book is content-complete and copy-edited, and we are now in the layout stage, with dead-tree edition just weeks away. In fact, I have to finish going over the layouts for the last half of the book by Friday, something I’m doing with iAnnotate PDF on the iPad:


So this is the wrong time to be making changes, since we can only fix typos or (maybe) add footnotes. And that’s a problem because while Xcode 4.3 includes Core Audio itself in the OS X and iOS SDKs, it doesn’t include the extras anymore. And that breaks some of our examples.

This doesn’t hit us until chapter 8, where we create an audio pass-through app for OS X. This requires using the CARingBuffer, a C++ class that was already a problem because many versions of Xcode ship a broken version that needs to be replaced with an optional download. CARingBuffer lives as part of Core Audio’s “Public Utility” classes in /Developer/Extras/CoreAudio/PublicUtility.

At least it did, until Xcode 4.3. Now that there’s no installer, there’s not necessarily a /Developer directory. Well, there is, but it lives inside the app bundle at, and includes only some of its previous contents. For the rest, we have to use the “More Developer Tools…” menu item, which takes us to Apple’s site and some optional downloads:

Xcode 4.3 downloads page: Audio Tools

This lets us download the optional Core Audio bits as a .dmg file, the contents of which look like this:

Contents of Audio Tools .dmg

So there’s our CoreAudio/PublicUtility folder, along with the AULab and HALLab applications that used to live at /Developer/Applications/Audio. We use AULab in chapter 12 to create an AUSampler preset that we can play with MIDI, but apps can live anywhere, so this isn’t a real big problem.

PublicUtility does pose an interesting problem, though: where does it go? The code example needs the source file to build, and up to this point, we’ve used an SDK-relative path, which means that the project can’t build anymore, since it won’t find PublicUtility along that path, since the SDK itself is now inside of Xcode’s code bundle. So where can we put PublicUtility where projects can find it? A couple options spring to mind:

  1. Leave the path as-is and move PublicUtility into the Xcode app bundle. Kind of nifty, but I have zero confidence that the MAS’ new incremental upgrade process won’t clobber it. And an old-fashioned download of the full surely would.
  2. Re-create the old /Developer directory and put PublicUtility at its previous path. This requires changing the project to use an absolute path instead of an SDK-relative one, but /Developer is a reasonable choice for a path on other people’s machines. It suited Apple all these years after all.
  3. Forget installing PublicUtility at a consistent location and just add the needed classes to the project itself. Probably the least fragile choice in terms of builds, but means that readers might miss out on future updates to the Audio Tools download.

In the end, I chose option #2, in part because it also works for those happy souls who have not had to upgrade to Lion and thus are still on Xcode 4.2, still with a /Developer directory. There is, however, a danger that future Xcode updates will see this as a legacy directory that should be deleted, so maybe this isn’t the right answer. A thread on coreaudio-api on where to put PublicUtility hasn’t garnered any followups, so we could be a long way from consensus or best practices on where to put this folder.

For now, that’s how I’m going to handle the problem in the book’s downloadable code. This afternoon, I ran every project on Xcode 4.3, changed the paths to CARingBuffer in the one example where it’s used, and bundled it all up in a new sample code zip, That will probably be the version we put up on the book’s official page once Pearson is ready for us.

Now I just have to figure out how to address this mess in a footnote or other change that doesn’t alter the layout too badly.

CocoaConf, NSBrief, etc.

Miscellaneous updates:

CocoaConf Chicago early bird pricing ends this weekend. I’ll be there, doing the Core Audio on iOS 5 talk (with MIDI and Audio Unit effects), and a new “Core What?” talk about neat stuff I’ve found over the years in the various C frameworks. A big piece of it will actually center on the CGPDF… stuff in Core Graphics, after all the PDF work I did last fall. Drawing into a PDF and drawing a PDF page into your view are common enough tasks, and the parsing of a PDF is another one of those tasks where the API makes absolutely no damn sense until you understand the problem domain behind it. Beyond that… CFUUID, CF-only collections, other curiosities and oddities.

Oh, and there’s a Fry’s Electronics in Downer’s Grove, about 20 minutes from the conference hotel. I have at least $500 worth of stuff on my shopping list (NAS, FCPX-compatible video card, Rock Band drums or Pro Guitar, out-of-print anime…). So that will add to the fun.

Speaking of CocoaConf, Saul Mora (who recorded our panel at CocoaConf Raleigh) had me on as a guest for NSBrief episode #33, in which we discuss audio theory, Core Audio, and AV Foundation for an hour. Plus, I lay out the plan for the “Reverse Q&A” we’re doing at CocoaConf Chicago, inspired by the Harmonix Reverse Q&A Panel at PAX East 2011. I wondered aloud about the idea of doing this in an earlier blog, and I’m glad we’ll have a chance to give it a shot. Hopefully, this will prove to be a good way to shake up the regular old panel format, and be fun and insightful for audience and speakers alike.

Learning Core Audio continues to work its way through Pearson’s production process. This week we signed off on author bios and cover blurbs. Copy-edit was a few weeks ago… admittedly a bit of a disappointment as I discovered all the third-person sentences had been somewhat mechanically rewritten to second-person (i.e., “we” becomes “you”). Sometimes it works, sometimes it really doesn’t, and I was too tired to fix all the cases of the latter. Still, it would have been nice to have been told about this house style two years ago when we started the damn thing.