The library, which is also the engine behind our popular live looper app Loopy, defines protocols for recording, playback, and audio output capture for easy inclusion with existing or new projects.

It’s designed to be really easy to work with, in order to get new audio projects off the ground quickly, and to dramatically cut down the iOS audio learning curve.

Find out more, download an evaluation version of the framework and a complete sample synth app here.

This dramatically simplifies the use of a circular buffer — you can use chunks of the buffer without any need to worry about where the wrap point is.

See the new implementation, which is thread-safe with one consumer and one producer, with no need for locks, making it perfect for use with high-priority Core Audio threads, on GitHub: TPCircularBuffer.

There’s a basic example of its use over on the original post.

I bet I’m not the only one, but of course reality struck and we realised that the App Store aint that kind of beast. Like any other product, an app needs to be actively presented to the world on a regular basis, and needs to be nurtured to keep it fresh and relevant.

I say “we” because at this point, my partner Katherine joined me after this particular revelation, and became A Tasty Pixel’s part-time marketing director and PR strategist — it’s taken two of us to keep A Tasty Pixel’s wheels turning smoothly, and we still have a lot to learn.

I thought I’d take a moment to reflect on some of the lessons we’ve learned in the past year, in which we’ve released a relatively successful travel planning and travel assistant app, The Cartographer, a very successful live looping app, Loopy, and its big brother Loopy HD, and tried a bunch of promotion strategies, some successful, some not, and some that haven’t yet run their course.

Stating the obvious: It’s not enough to just build it

Just for the record, and I’m sure we all know this now, but “build it and they will come” doesn’t cut it on the App Store. Maybe it did in Month One, but now, you might as well not start if you’re not going to devote a goodly amount of time to promoting your app, because it just won’t get anywhere amongst the hoards of other apps.

Don’t expect everything to work

Perhaps the biggest, or at least most helpful, lesson we learned was not to expect everything to go as planned, and not to get too down if a strategy didn’t pan out.

It’s often impossible to predict which things will be successful and which not, but we found it helpful to consider the payoff for the successful strategies being spread around amongst all the strategies, successful or not — that way, we could be pleased about the ones that paid off, and philosophical about the ones that didn’t! The trick is just to keep at it, and keep being creative.

High quality attracts attention

Please excuse a moment of immodesty: I’d like to think my apps have a fairly high standard of quality, and it would appear that making “premium” apps really does pay off!

It’s not entirely “build it and they will come”, but having an app that looks great and that customers love gives you a big head-start in the PR game. Word of mouth is huge on the App Store, and the mouths in question produce more words about great apps.

What’s more, a feature by Apple, which generally only happens to high-quality apps, can make a massive difference, both in the short and long term, and gives an app a great “social proof” bump.

Incidentally, this goes for the app site too. Sites like App Sites reward beautiful designs, and you can get picked up on various design blogs too — we’ve had quite a bit of traffic lately from Blog Du Webdesign, for example. And the same goes for demo videos. The Cartographer’s demo got a huge response, and got a lot of word of mouth, just about the video itself:

So: Put in the extra sweat-and-tears. It’s worth it.

Influencers

Sometimes, depending on the nature of the app, a good word from an influencer in the area can be huge.

For example, when Loopy was in pre-release, I made contact with a musician I’m a big fan of, Dub Fx (you might know him from this video, which went viral a couple of years ago). Ben was very interested in the app, and threw his not inconsiderable support behind it, unleashing this amazing demo video:

…our jaws were dangling around our knees when I found that in my inbox! We’ve since decided to work together — look out for the Dub Fx app some time next year!

That was the success story — our experience with The Cartographer was quite different, though. Katherine spent months upon months getting to know travel bloggers, interacting on their blogs and via various social media, hoping to make connections and get to introduce the app to some of them.

The good news is that we made some really good new friends out of the process, which makes it all worthwhile as far as I’m concerned. But as a marketing strategy, it was a total bust. As it turns out, many travel bloggers seem to be quite unresponsive — some of them, despite lots of friendly comments and other interactions, never even noticed us! Some did, and kindly give us a mention on their blogs, but this didn’t seem to have any effect!

It turns out, as Katherine discovered in an industry report, the places that travellers (our target audience) go on the Internet: Not travel blogs! Travellers visit airline sites, hotel websites, TripAdvisor and forums, Lonely Planet’s forums…all places that we have no hope of exerting any influence at all (those forums, by the way, are militantly moderated for anything that even loosely resembles product mentions). So, we did the best we could, given the options, but it’s a really difficult market.

So, I suppose the lesson there is tread carefully, do your research, and spend the time strategically — be aware that the payoff might be huge, or it might be nil. If we’d known in advance how poorly the months of work Katherine put into meeting travel bloggers would turn out, we might have invested less time in it. We may have even decided to find an alternative target market.

Reviewers

There are a lot of app review sites out there, now. It’s just insane — it seems like every man, his dog, and several of his goldfish have app review blogs. Back at the start, Katherine put in a huge number of hours and built us a spreadsheet of the most important reviewers. With that done, whenever we do a release, she spends half a day (that’s how long it takes, or more!) emailing and filling out web forms of reviewers.

Most of them never respond, especially the big ones — they get such a barrage of review requests, it’s not hugely surprising. Many blogs offer paid reviews, but we haven’t gone down that track yet, so, nothing to report there. But many have responded, and every review helps, both for the social proof and word-of-mouth, and for the SEO.

Honestly, we haven’t yet collected hard stats about the proportion of reviewers who contact us in response to our initial contact, and how many are contacting us of their own accord. Many of the significant reviews we’ve had have happened independently of us tracking down and contacting the reviewers in question, though.

So, we’re still undecided about whether the amount of time invested in telling reviewers about our products is really paying off. I think we’ll always do it for initial releases, and possibly for major, major updates, though.

Journalists

This is something we want to do, but haven’t really pursued a whole lot — finding relevant journalists and contacting them directly. We’ve found contacts for a few, but they always seem to be out-of-date and emails just bounce.

So, this seems like a good thing to do, but still TBD.

Press releases

Press releases seem to have two main benefits — they help with SEO, which helps users find your app — and they marginally increase the likelihood of getting picked up and getting some free media.

We’ve been doing regular monthly press releases via PRWeb (a.k.a. Vocus) for a few months now, after previously only doing a big one (via PRWeb) for launch, and a couple smaller ones (via the much cheaper PRMac service) for updates.

Vocus talked us into signing up for a 12 month subscription (for a thousand-and-something $), which includes one release a month, and a representative who helps suggest topics, and checks over our drafts. Our representative Rebecca has been great with both, and has been very responsive with answering our dumb questions along the way.

We’ve been pseudo-picked up by a few nice sites like the San Francisco Chronicle, although it’s automated and I don’t know how much of a direct difference it actually makes. At the moment, loopyapp.com’s page rank is at 4, which is not bad at all, some of which is presumably thanks to our releases, and we seem to rank fairly well with most of the google searches we want to be associated with. An interesting side note is that quite a lot of our referred web traffic is coming straight from PRWeb, which surprised me.

As with a lot of these strategies, I can’t say for sure whether it’s been a huge success so far — it’s hard to determine the cause of a good page rank, for example — but my gut feeling is that it’s worthwhile; it makes sense.

Social media

I never “got” Facebook up until quite recently, but now I can’t get enough — after being a staunch Twitter user for quite a long time, I’ve discovered that Facebookers are amazingly engaged. I remember hearing somewhere that one Facebook follower (…”like”-r?) is worth several Twitter followers, and that rings true. I have a great time hanging around on the A Tasty Pixel Facebook page and interacting with people there, as opposed to Twitter, which is sometimes a little bit like shouting into a black hole.

Google+? I have no bleeding idea. Anyone?

Anyway, it’s important to engage with your customers on both, but particularly Facebook, and there’s lots of scope for interesting interactions with customers. For example, I’m about to start building effects into Loopy, and I was curious about what people most wanted to see. So, I created a poll on the Facebook page, and got a great response (“More Cowbell” coming right up…).

I quite like being able to “be me” on Twitter and Facebook, to show what I’m up to, get feedback on stuff as I’m making it, and to respond straight away to people. I get to present a personal face, instead of being A Company.

As Loopy is a music-creation app, it also hooks straight into SoundCloud, and has a very active SoundCloud group which I find myself trawling every morning — a great entertainment. One of the unexpected benefits is that I’ve met quite a few talented and lovely people though SoundCloud, some of whom have gone on to become testers and advisors, and help shape Loopy.

Customer support

While this isn’t promotion-related, I’ve been in the position (being a one-person dev company) to interact with customers directly, and I make a point of responding almost immediately when possible, and doing my best to address problems straight away. On a couple of occasions, the customer’s helped me identify a time-sensitive issue — they’re using The Cartographer and are about to go away on holiday — and I’ve had a fixed ad-hoc build out to them within a couple of hours, which has been very satisfying on both sides!

Customers love the straight-to-developer contact and the fast replies, and quite a few people have gone on to become very vocal supporters, which has been great. A very positive support experience goes a long way towards building goodwill, and I think it’s super-important. It also feels really satisfying, so in my option, there’s no reason not to go all-out!

Expertise

Tim Ferriss encourages product creators to position themselves as authorities in the area targeted by the product, to give the product more clout and attract more attention. The idea is, if your app is targeted at a particular area, and you have experience in that area, then write: write on your own blog, and seek out others to do guest posts on (make sure it links back to you!).

We’re spending a few years travelling in a motorhome around Europe as we set up A Tasty Pixel and Katherine’s art business, and The Cartographer was built as a result of our experiences travelling. So, (I say “so”, but actually we were already blogging as a journal for ourselves — but let us conveniently ignore that fact) we keep a travel blog, which brings in some traffic. But not much — honestly, this is a terrible example, and we’ve had very few results, possibly because of the nature (and diminutive size!) of our audience. Were we to focus on promoting our blog more and making it less “this-is-what-we-did” and more “this-is-what-you-can-do”, we might see more response, but our priorities lie decidedly elsewhere — traditional travel blogging: not our bag, baby.

But, I know this can work — I know it’s an extreme example, but look at Trey Ratcliff, the HDR photography authority, and his app 100 Cameras In 1. They got onto CNN, ferchrissake, and pretty much every other media outlet you can imagine!

Paid advertising

This is the next frontier, for us, and I’m fairly excited about it. Everything I’ve mentioned up to this point has been about “free media”, but advertising is a whole new category to explore.

With that said, I’ve had two initial forays into ads: Facebook, and AdMob, and both have been total failures.

To an advertiser, Facebook is like a giant damn candy shop. (I felt really weird when I read this recent Joy of Tech, and found myself drooling a little bit by the fifth panel…). The kind of targeting options available are just a-mazing — you can target people from their age, gender and location, right down to their areas of interest (which is insanely cool), and even down to targeting users who like one particular competitor’s product.

Despite the cool factor, it turned out to be pretty much a total bust for attempt 1 — we were paying a stupid amount per click, compared to the actual amount we would earn per sale. We spent $75, and got…45 clicks. That’s $1.60 per click, which represents about 75% of our actual take per sale, and it’s very unlikely even 10% of those clicks resulted in a sale.

At the time, I was choosing to bid per thousand clicks (CPM), instead of per click (CPC), but the reason I chose to was that the recommended CPC was well above what I was prepared to spend.

The lesson there is that Facebook users aren’t ready to buy straight away. A friend who works in advertising reported good results marketing the Facebook page instead of the product, so that users who are interested can hang around for a while, get to know you, and then you can market to them later. I’ll try this soon, and I’m hoping that the mechanics of a social ad (with a “Like” button on the ad, instead of a click to navigate away from the current page) will result in higher (and cheaper!) conversions.

I found similar results with AdMob — we got a much, much better cost per click (I was playing with the minimum bid of 29c per click), but even at 29c/click, in order to break even for our $2.99 app, 1 in 7 people who click the ad would have to buy it, which I think is far-fetched.

So, as far as direct advertising goes: As someone who earns just over $2 per sale, we just can’t afford it! My next experiment: Trying to use Facebook to increase our social reach, instead.

Summary

It’s become abundantly clear to us that app promotion is a job in itself, and it’s one that can scale right up to the amount of time you have available. They key is to be constantly creative, and to be out there, all the time, chipping away.

Almost everything’s a shot in the dark, and while many strategies may yield no results at all, some might be a big break (like meeting Dub Fx, for us), so it’s important to just keep on trying.

Apple give you absolutely no help in tracking the success of any particular strategy, unfortunately, although there are tricks you can use to help track where some of your sales are coming from.

The PR thing is just as important as actually creating the app; it’s hard, and it’s constant, and it means that running a software development company is anything but a “passive income”. Fortunately for me, I love it to bits!

I’m very pleased to announce that Loopy HD has arrived! A Tasty Pixel HQ has been a-buzz with activity these last few months, and we have a solid iPad live looper with top-notch features to show for it.

Loopy HD takes Loopy, doubles the number of tracks to fill up that big iPad display (6, 9 or 12 tracks), adds a beautiful big control panel with more session controls, and brings an even more polished audio engine and spot-on time accuracy.

We’ve got huge plans for this app and it’s just going to keep getting better. Right around the corner is MIDI support, so you can control the app with a pedal, and sync the tempo with other devices and other apps, over the network or even on the same device. Fun!

If you already own Loopy, Loopy HD will be on sale for $3.99 for a few days, so you don’t have to pay full price. We’ll also be giving away some promo codes from our Facebook page, so join us over there if you’re interested.

We’ve already given away some promo codes on our newsletter, but we do this from time to time, so subscribe if you’d like to nab one the next time.

Loopy has been updated too! Version 2.1 includes all of the improvements to the audio and timing engines from Loopy HD, as well as a smaller version of Loopy HD’s control panel. There’s a number of new features, as well, like count-in muting and unmuting, the ability to turn off track sync, and zip file support.

Thanks, Steve.

Hands up, backing away

Disclaimer: I am not at all an expert in realtime programming, or Mach, or iOS-device optimisation, so this is pretty much a fumble in the dark. I won’t be at all offended if anyone wishes to shoot me down and offer a more sensible solution — in fact, please do! Until then, watch as I stumble on…

Also note that there are often ways to eliminate the need for precise timing of this nature, by architecting code appropriately — when it comes to audio, for example, CoreAudio provides a very accurate time base in render callbacks. For things like metronomes or audio synthesizers, it’s always better to establish a starting time, and use the difference between the current time and the starting time in order to determine state, rather than using a timer to advance the state. Still, sometimes, you just need a timer…

What the blazes?

So, I’m working on an update to Loopy, which uses a shared clock object to synchronise tracks and a variety of events (like user interface updates or timed track manipulations). A tester noted that the mute/unmute quantisation feature that I’ve recently implemented, which will mute or unmute a loop at its starting point (rather than whenever you tap it), tends to overshoot a little, resulting in a small part of the beginning of the loop being audible.

Of course, there are other solutions to this particular problem (like stopping or starting playback from the audio render callback, and using Core Audio’s timestamps for exact timing), but I use timers in other places outside Core Audio’s domain, which makes Core Audio’s timing mechanism unavailable, and I wanted to see how accurate I could get the timing.

Our friend, mach_wait_until

I read in several places mention of the Mach API utility mach_wait_until (from mach/mach_time.h), which is very low-level and supposedly fairly accurate. So, based on that lead, I put together an Objective-C singleton class that launches a high-priority thread, and uses said thread to schedule events.

An NSArray of events are maintained, and a scheduleAction:target:inTimeInterval: routine creates and adds events to this array, then pokes the thread.

The thread grabs the next event in sequence, then uses mach_wait_until to sleep until the time of the next event arrives, then performs the specified action on the target. It’s kinda a DIY NSRunLoop.

Here’s a comparison between this technique, and just using performSelector:withObject:afterDelay: (which schedules a timer on the NSRunLoop), observed while performing various scheduled events within Loopy running on my iPhone 4 with the debugger, and derived by comparing the time of event execution with the event’s scheduled time:

That was attempt number 1: This seems to give us about 11.4ms better accuracy on average (three times more accurate).

Not bad, but it turns out mach_wait_until isn’t really that accurate, particularly if there’s a bunch of other stuff going on in other threads.

Spinning, for fun and profit

For my second attempt, the thread performs a mach_wait_until until just before the event is due, then performs a spin lock until the time arrives, using mach_absolute_time to compare the current time with the target time.

This gave further improved results — here’s that table again, but with the new scheme added, with a few different spin lock times:

It appears that the more stuff there is going on in other threads, the more likely the mach_absolute_time call is to overshoot. So, the more time spent in the spin lock, the more leeway mach_absolute_time has to wait too long. Of course, that’s at the cost of making the CPU twiddle its thumbs for the duration.

Better than a punch in the knee

The results weren’t quite as fantastic as I’d hoped — still within the same order of magnitude, that’s for sure — but the average case for the 200ms spinlock approach is 14ms, or 5.8 times, more accurate than the traditional approach, and the minimum case is dramatically better.

You know, I think if I was aware of the results in advance, I might not bother, but I’ll stick with my hard-won 14ms now that I’m here (that’s 617 audio samples, I’ll have you know).

If anyone’s curious about the implementation (or wants to take a stab at doing better), here it is, along with a wildly simplistic commandline test app: TPPreciseTimer.zip

Now to get back to some real work.

Addendum: GCD follow-up

Chris in the comments below suggested trying a GCD-based approach, using dispatch_after. Curious, I rigged it up, and these are the stats, collected the same way as above, added to the prior table:

So, they appear pretty much the same as the NSRunLoop stats.

So, I create two different views within the nib, one portrait, one landscape, each with the same view hierarchy, but with a different layout.

When the orientation changes, I set self.view to the appropriate view. I initialise both views on load, and keep both of them synced to properly reflect the app’s state — basically, I’m double-handling everything, which bloats my code and increases the chance I’ll make a mistake.

So, here’s an easier way: Rather than maintaining two separate view hierarchies and switching between them when the orientation changes, why not just change the layout of one single view hierarchy? The only changes between the portrait and landscape views are layout changes, so if we can extract just the layout information from each view, then we don’t have to worry about maintaining both view hierarchies.

Basically, we’re talking about using each view version as a layout template only.

That’s what TPMultiLayoutViewController class does. It’s a drop-in UIViewController subclass that automatically manages switching between different view layouts for portrait and landscape orientations, without the need to maintain view state across two different view hierarchies.

It works by defining portraitView and landscapeView outlets which it traverses upon loading the nib. It matches each subview element to its counterpart in the other layout (based on tag, target/action, title, etc.), and stores just the layout attributes of each element.

Then, when the orientation changes, the view hierarchy is traversed and these layouts are applied to each subview.

To use it,

1. Set the superclass for your view controller to TPMultiLayoutViewController.
2. In Interface Builder, create two different views: one for portrait orientation, and one for landscape orientation.
3. Attach your portrait orientation root view to the “portraitView” outlet, and the landscape orientation root view to the “landscapeView” outlet.
4. Attach one of the views (whichever you prefer) to the “view” outlet, and connect any actions and outlets from that view.

Grab it from the TPMultiLayoutViewController GitHub repository, and let me know what you think.

Update: It’s now available!

The new version includes:

• Full-featured noise gate/expander, with auto-calibration
• Bigger panel and clock controls
• Document support: Import loops from Mail and other apps
• Play/pause button on main screen (great for breaks)
• Option to add track to Loopy’s SoundCloud group when publishing
• Many more improvements and bug-fixes

Expect it to land in a week or so. Now, off to work on the next version..

• A much bigger bottom display, with paged clock manipulation controls for easier access to the most-used functions
• A play/restart button on the main loops screen
• Clearer distinction between muted and unmuted tracks
• The option to automatically begin overdubbing after first record
• Import loops from Mail and other applications straight into a Loopy 2 session
• Single sign-on for SoundCloud, including Facebook link support

Look out for it soon.

It’s currently on sale for launch, so take a look! We’re very proud of it.

This version brings new features from Google Maps to the iPhone: Routes and shapes. Now you can plot hiking routes, cycle paths or road trips on your computer using Google Maps, then sync them to your iPhone and take them with you.

Combined with The Cartographer’s existing offline mapping features, we think this is a really exciting feature for outdoorsy types and travellers.

So, we hope you enjoy 1.4! It’s available right now from the App Store.

I thought I’d put together a relatively universal, drop-in solution: UIScrollView and UITableView subclasses that handle everything.

When the keyboard is about to appear, the subclass will find the subview that’s about to be edited, and adjust its frame and content offset to make sure that view is visible, with an animation to match the keyboard pop-up. When the keyboard disappears, it restores its prior size.

It should work with basically any setup, either a UITableView-based interface, or one consisting of views placed manually.

For non-UITableViewControllers, use it as-is by dropping the TPKeyboardAvoidingScrollView source files into your project, popping a UIScrollView into your view controller’s xib, setting the class to TPKeyboardAvoidingScrollView, and putting all your controls within that scroll view.

To use it with UITableViewController, pop the TPKeyboardAvoidingTableView source files in, and just make your UITableView a TPKeyboardAvoidingTableView in the xib — everything should be taken care of.

You can grab the source files, which includes a sample project, over on the GitHub project page

Apple’s produced some sample code (iPhoneExtAudioFileConvertTest), which demonstrates how it’s done, but their implementation isn’t particularly easy to use in existing projects, as it requires some wrapping to make it play nice.

For my upcoming looper app Loopy, I’ve put together a simple Objective-C class that performs the conversion of any audio file to an AAC-encoded m4a, asynchronously with a delegate, or converts any audio provided by a data source class (which provides for recording straight to AAC) and I thought I’d share it.

Grab the code, and a sample project demonstrating its use at the GitHub repository for TPAACAudioConverter.

To use it:

• Include the class in your project, and make sure you’ve got the AudioToolbox framework added, too.
• Audio session setup:

If you already have an audio session set up in your app, make sure you disable mixing with other device audio for the duration of the copy operation, as this stops the hardware encoder from working (you’ll see funny errors like kAudioQueueErr_InvalidCodecAccess (Error 66672)). I know that AVAudioSessionCategoryPlayAndRecord, AVAudioSessionCategorySoloAmbient and AVAudioSessionCategoryAudioProcessing work for sure. TPAACAudioConverter will automatically disable kAudioSessionProperty_OverrideCategoryMixWithOthers, if it’s set.

If you’re not already setting up an audio session, you could do so just before you start the conversion process.

You’ll need to provide an interruption handler to be notified of audio session interruptions, which impact the encoding process. You’ll also need to create a member variable to store the converter instance, so you can tell it when interruptions begin and end (via interrupt and resume).

// Callback to be notified of audio session interruptions (which have an impact on the conversion process)
static void interruptionListener(void *inClientData, UInt32 inInterruption)
{
	AACConverterViewController *THIS = (AACConverterViewController *)inClientData;
 
	if (inInterruption == kAudioSessionEndInterruption) {
		// make sure we are again the active session
		checkResult(AudioSessionSetActive(true), "resume audio session");
        if ( THIS->audioConverter ) [THIS->audioConverter resume];
	}
 
	if (inInterruption == kAudioSessionBeginInterruption) {
        if ( THIS->audioConverter ) [THIS->audioConverter interrupt];
    }
}
 
/*snip*/
 
-(void)startConverting {
 
    /*snip*/
 
    // Initialise audio session, and register an interruption listener, important for AAC conversion
    if ( !checkResult(AudioSessionInitialize(NULL, NULL, interruptionListener, self), "initialise audio session") ) {
        [[[[UIAlertView alloc] initWithTitle:NSLocalizedString(@"Converting audio", @"")
                                     message:NSLocalizedString(@"Couldn't initialise audio session!", @"")
                                    delegate:nil
                           cancelButtonTitle:nil
                           otherButtonTitles:NSLocalizedString(@"OK", @""), nil] autorelease] show];
        return;
    }
 
 
    // Set up an audio session compatible with AAC conversion.  Note that AAC conversion is incompatible with any session that provides mixing with other device audio.
    UInt32 audioCategory = kAudioSessionCategory_MediaPlayback;
    if ( !checkResult(AudioSessionSetProperty(kAudioSessionProperty_AudioCategory, sizeof(audioCategory), &audioCategory), "setup session category") ) {
        [[[[UIAlertView alloc] initWithTitle:NSLocalizedString(@"Converting audio", @"")
                                     message:NSLocalizedString(@"Couldn't setup audio category!", @"")
                                    delegate:nil
                           cancelButtonTitle:nil
                           otherButtonTitles:NSLocalizedString(@"OK", @""), nil] autorelease] show];
        return;
    } 
 
 
    /*snip*/
}

• Make the relevant view controller implement the TPAACAudioConverterDelegate protocol: That means implementing AACAudioConverterDidFinishConversion:, and AACAudioConverter:didFailWithError:, and optionally AACAudioConverter:didMakeProgress: to receive progress updates.
• Create an instance of the converter, pass it the view controller as the delegate, and call start:

audioConverter = [[[TPAACAudioConverter alloc] initWithDelegate:self 
                                                         source:mySourcePath
                                                    destination:myDestinationPath] autorelease];
 
[audioConverter start];

Alternatively, if you wish to encode live audio, or provide another source of audio data, you can implement the TPAACAudioConverterDataSource protocol, which defines AACAudioConverter:nextBytes:length:, which provides a buffer to copy at most “length” bytes of audio into, and then expects you to update “length” to the amount of bytes provided. For that you’ll need to use the second initialiser, initWithDelegate:dataSource:audioFormat:destination:.

I noted previously that you can’t encode AAC live, which is what Apple’s docs say, but Alex in the comments informed me that it wasn’t so. So, I added the datasource method, and sure enough, it does work live!

The one caveat is that it’s a relatively heavy process. As it turns out, because my app Loopy is busily mixing and displaying visualisations and such, it was too much to also encode straight to AAC, and I was getting glitches. But it would probably work fine for plain recording. Thanks, Alex!