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 doing some experiments with advertising my live looper app Loopy lately, and want a way to track the success of various approaches. It occurred to me that the totally freeform nature of the LinkShare “signature” field (which you can use to track traffic sources) lends itself to an even more flexible approach than that presented in the Mobile Orchard article.

Here’s a way to use that signature field to report the domain name of any referrer who links either to the app page, or to a download link (like, say, http://loopyapp.com/download).

This way, if, say, TUAW link to your app site, if someone clicks through then clicks the download link on your app site and buys, the resulting order will be reported as coming from TUAW. If someone clicks through from your Facebook page, it’ll come up as coming from Facebook. You can even modify the script further to report more precise details (like the path), if you like.

It assumes you’re using PHP, but the principle’s the same for any other language (BYO code, though ;-)).

Step 1: Sign up to LinkShare

First, if you haven’t already, Sign up to the LinkShare program — Once you’ve created a LinkShare account, join the Apple affiliate program via the “Programs” tab. After 3 days, you’ll get an email welcoming you to the program, and you’ll be good to go.

Step 2: Create a product link

Once you’re admitted to the program, open up the “My Advertisers” sub-tab from the LinkShare Programs tab, and open the “Link Maker Tool”. This lets you search for products, and create a link that will open up your app’s App Store page, and will be associated with your LinkShare account.

Step 3: Create a download redirection script

Now we’re going to set up a script on your app site which will redirect the visitor to the URL you just created (which in turn, redirects straight to the App Store page). It’ll add a “signature” parameter to the URL, which corresponds to the original referrer, so you can track where orders came from.

Create a file called ‘download.php’ in the root of your app site, with the following content, with your LinkShare URL inserted where indicated:

<?php
// Replace the following URL with the LinkShare URL you created
$linkshare_url = "http://click.linksynergy.com/fs-bin/stat?id=/yGrgMJzFG0&offerid=146261&type=3&subid=0&tmpid=1826&RD_PARM1=http%253A%252F%252Fitunes.apple.com%252Fapp%252Floopy%252Fid300257824%253Fmt%253D8%2526uo%253D4%2526partnerId%253D30";
 
session_start();
$referer = $_SESSION['original_referer'];
if ( !$referer ) $referer = $_SERVER["HTTP_REFERER"];
 
if ( $referer ) {
    $signature = preg_replace("@https?://(?:www\.)?([^/]+?)(?:\.com)?/.*@", "$1", $referer);
} else {
    $signature = preg_replace("@^(?:www\.)?(.+?)(?:\.com)?$@", "$1", $_SERVER["HTTP_HOST"]);
}
 
$signature = preg_replace("@[^a-zA-Z0-9]@", "", $signature);
 
header("Location: ".$linkshare_url."&u1=".$signature);
?>

This script looks for the original referrer in a session variable (which we’ll set up in the next step), so that the domain of the site that links to your app site is used, not just your app site’s domain. Then it creates a properly-formatted signature parameter (just alphanumeric), appends it to your LinkShare URL, and sends the viewer onwards.

Bonus points: I prefer to get rid of the ‘php’ extension to make the URL a bit cleaner. Pop the following into your .htaccess file to access ‘download.php’ as just ‘download’:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule . %{REQUEST_FILENAME}.php [L]
</IfModule>

Step 4: Remember the referrer

Now, on the landing page script for your app site (or the site header), pop this in at the very start:

<?php
session_start();
if ( !$_SESSION["original_referer"] ) $_SESSION["original_referer"] = $_SERVER["HTTP_REFERER"];
?>

This stores the original referrer URL in a session variable, to use when we actually link the viewer through to the App Store.

Step 5: Test it

To make sure everything’s working properly, open download.php again, and replace “header” at the bottom with “echo”, so that instead of redirecting the browser, we just print out the URL where we would be redirecting to.

Open your appsite/download URL, and make sure the URL ends with “&u1=appsite“. That’s for direct visitors. Now, click through to your app site from another site, then click your “download” link. You should now see the name of the original site you linked from as the “u1″ parameter at the end of the URL.

Once you’re satisfied that you’re good to go, make sure you replace “echo” with “header” again.

Step 6: Track

Now that you’re ready to track referrals, you can give out your http://yourappsite/download URL as your app’s direct iTunes download link (to reviewers, in your press releases, etc).

You can view a report showing clicks and orders associated with each referrer on the LinkShare page — create an advanced report by clicking the “Advanced Reports” sub-tab, then select your desired date range (I use “Since Last Payment”, and under “Report Type”, select “Signature Activity”. Hit “View Report”, and you’ll see your clicks and sales versus each referrer (“Member ID”, on the report).

Voila! Omnipotence achieved.

Addendum: This technique works for tracking referrers, but if you’re wanting to track the performance of ads (say, with AdMob), you’ll want to use your original LinkShare URL, with a custom “&u1″ signature parameter. As ad platforms like AdMob link directly (and don’t, as far as I know, send a referer parameter), this script won’t pick up that it’s from your ad platform.

Addendum 2: LinkShare’s reports don’t distinguish between products, so if you’ve multiple apps, you might want to add a prefix to your signature parameter to tell ‘em apart. You could, say, replace that header("Location: ".$linkshare_url."&u1=".$signature); line with something like header("Location: ".$linkshare_url."&u1=myapp".$signature);.

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.

I’ve just discovered a critical issue with Sparrow that I thought others should be warned of. It just bit me, big-time, when in the middle of an important negotiation with a third party, an earlier unpolished draft was sent out instead of the final email, when I experienced a momentary Internet connection dropout.

Sparrow has an issue where hitting “Send”, in unreliable network conditions, on a draft message that has been modified, results in a prior copy of the message being sent, rather than the latest version.

To replicate this issue reliably:

1. Create a new message (Cmd-N)
2. Specify a recipient (oneself), subject, and some body content (say, the letter “A”)
3. Hit “Save”, to save the draft
4. Change “A” to “B”, then disconnect the network connection (in my case, turning off the radio on my external WiFi adapter), then hit “Send”. Sparrow will report a failed connection, and will keep the outgoing message with state “Pending”
5. Restore network connection. Upon detecting the restored connection, Sparrow will proceed to send the message
6. Check email. Received test email will have “A” in the email body.

Scary stuff. I hope they’ll fix this soon, but it’s going to make the app difficult to trust in future!

Update: I should mention, a probable workaround for this is to never, ever hit “Send” until you’ve saved the draft, and verified that the save operation has completed (perhaps even restart the app first).

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.

Anyway, after plenty of frustration, I noticed some chatter about the damn thing being busted in Xcode 4. Figures!

There’s an alternate third party version on GitHub, but this didn’t really help me – I still got inscrutable errors, so I took a look at the original.

The version that comes with Xcode 4 appears to have some problems distinguishing, say, an iPhone Simulator build of the app from a native build sitting in the Archives folder. I’d just see an error about otool and some binary living in the iPhone Simulator folder.

Digging into the errant symbolicatecrash source, I noticed that the code that finds the executable path tests each candidate using otool, but doesn’t seem to be able to comprehend the output from otool caused by running it on the wrong architecture.

So, replacing the rather unhelpful ‘die’ statement on line 323:

die "Can't understand the output from otool ($TEST_uuid -> '$otool -arch $arch -l $path')";

With a “No, it ain’t this executable” response:

return 0;

…solves the problem immediately. Now I can drag crash logs straight into the Organizer in Xcode, and it’ll symbolicate correctly.

A little utility I just put together does that for you: Post Grabber detects POST data and generates an equivalent “curl” command that can be used in shell or Automator scripts.

Post Grabber works with its own internal browser, so it can intercept POST submissions directly. That means it works with HTTPS, unlike the traditional web sniffer approach.

Download the app, or see the source on GitHub.

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!

They’re designed for FIFO (first-in-first-out) use, like storing audio coming in the microphone for later playback or processing.

Consider a naive alternative: You copy the incoming audio into an NSData you allocate, and then pass that NSData off. This means you’re allocating memory each time, and deallocating the memory later once you’re done processing. That allocation incurs a penalty, which can be a show-stopper when part of an audio pipeline – The Core Audio documentation advises against any allocations when within a render callback, for example.

Alternatively, you can allocate space in advance, and write to that, but that has problems too: Either you have a synchronisation nightmare, or you spend lots of time moving bytes around so that the unprocessed audio is always at the beginning of the array.

A better solution is to use a circular buffer, where data goes in at the head, and is read from the tail. When you produce data at the head, the head moves up the array, and wraps around at the end. When you consume at the tail, the tail moves up too, so the tail chases the head around the circle.

Here’s a simple C implementation I recently put together for my app Loopy: TPCircularBuffer

typedef struct {
    void             *buffer;
    int32_t           length;
    int32_t           tail;
    int32_t           head;
    volatile int32_t  fillCount;
} TPCircularBuffer;
 
bool  TPCircularBufferInit(TPCircularBuffer *buffer, int32_t length);
void  TPCircularBufferCleanup(TPCircularBuffer *buffer);
void  TPCircularBufferClear(TPCircularBuffer *buffer);
 
// Reading (consuming)
void* TPCircularBufferTail(TPCircularBuffer *buffer, int32_t* availableBytes);
void  TPCircularBufferConsume(TPCircularBuffer *buffer, int32_t amount);
 
// Writing (producing)
void* TPCircularBufferHead(TPCircularBuffer *buffer, int32_t* availableBytes);
void  TPCircularBufferProduce(TPCircularBuffer *buffer, int32_t amount);
int   TPCircularBufferProduceBytes(TPCircularBuffer *buffer, const void* src, int32_t len);

Update: The implementation has been recently amended to make use of a neat virtual memory mapping technique that inserts a virtual copy of the buffer memory directly after the buffer’s end, negating the need for any buffer wrap-around logic. Clients can simply use the returned memory address as if it were contiguous space.

The virtual memory technique was originally proposed by Philip Howard, and adapted to Darwin by Kurt Revis.

Use TPCircularBufferHead to get a pointer to write to the buffer, followed by TPCircularBufferProduce to submit the written data, then TPCircularBufferTail to get a pointer to the next data to read, followed by TPCircularBufferConsume to free up the space once processed.

TPCircularBufferProduceBytes is a convenience routine for writing data straight to the buffer.

The implementation is thread-safe (no need for locks) in the case of a single producer and single consumer.

Here’s an example, using circular buffers to implement a simple playthrough scheme that plays audio coming in the microphone:

@interface MyAudioController : NSObject {
  TPCircularBuffer buffer;
}
 
@end
 
#define kBufferLength 1024
 
@implementation MyAudioController
 
- (void)setup {
    // Initialise buffer
    TPCircularBufferInit(&buffer, kBufferLength);
 
    // Setup audio, etc
}
 
- (void)dealloc {
    // Release buffer resources
    TPCircularBufferCleanup(&buffer);
 
    [super dealloc];
}
 
static OSStatus audioInputCallback(void *inRefCon, 
                                   AudioUnitRenderActionFlags *ioActionFlags, 
                                   const AudioTimeStamp *inTimeStamp, 
                                   UInt32 inBusNumber, 
                                   UInt32 inNumberFrames, 
                                   AudioBufferList *ioData) {
    MyAudioController *THIS = (MyAudioController *)inRefCon;
 
    // Render audio into buffer
    AudioBufferList bufferList;
    bufferList.mNumberBuffers = 1;
    bufferList.mBuffers[0].mNumberChannels = 2;
    bufferList.mBuffers[0].mData = NULL;
    bufferList.mBuffers[0].mDataByteSize = inNumberFrames * sizeof(SInt16) * 2;
    OSStatus err = AudioUnitRender(THIS->ioAudioUnit, ioActionFlags, inTimeStamp, kInputBus, inNumberFrames, &bufferList);
    if ( !checkResultLite(err, "AudioUnitRender") ) { return err; }
 
    // Put audio into circular buffer
    TPCircularBufferProduceBytes(&THIS->buffer, bufferList.mBuffers[0].mData, inNumberFrames * 2 * sizeof(SInt16));
}
 
static OSStatus audioOutputCallback(void *inRefCon, 
                                    AudioUnitRenderActionFlags *ioActionFlags, 
                                    const AudioTimeStamp *inTimeStamp, 
                                    UInt32 inBusNumber, 
                                    UInt32 inNumberFrames, 
                                    AudioBufferList *ioData) {
    MyAudioController *THIS = (MyAudioController *)inRefCon;
 
    int bytesToCopy = ioData->mBuffers[0].mDataByteSize;
    SInt16 *targetBuffer = (SInt16*)ioData->mBuffers[0].mData;
 
    // Pull audio from playthrough buffer
    int32_t availableBytes;
    SInt16 *buffer = TPCircularBufferTail(&THIS->buffer, &availableBytes);
    memcpy(targetBuffer, buffer, MIN(bytesToCopy, availableBytes));
    TPCircularBufferConsume(&THIS->buffer, sampleCount);
 
    return noErr;
}
@end

It’s often too much trouble to create a new XCode project and set up the framework to do one simple test, which is why I put together this little shell script that lets you run Cocoa code from the command line:

$ runcocoa 'NSDateFormatter *formatter = [[[NSDateFormatter alloc] init] autorelease]; [formatter setDateFormat:@"d MMM, h:mm a"]; NSLog(@"%@", [formatter stringFromDate:[NSDate date]]);'

2011-02-23 20:02:10.313 runcocoa-output[28025:903] 23 Feb, 8:02 PM

You have full access to all Cocoa libraries, and in iOS mode, access to most iOS stuff too, straight from the command line.

Update: This is now available as a GitHub project

You can invoke it either by specifying the code to execute on the command line as a parameter, or through standard input, so you can pipe stuff to it. This is particularly convenient for use with TextMate: Type some code, hit Cmd-Option-R, type “runcocoa”, hit enter, and the result appears as a tooltip.

Awesome, no?

You can include other frameworks (use “-include AudioToolbox/AudioToolbox.h -framework AudioToolbox" as command line arguments, for example), and run the code in gdb (with -gdb as a command-line argument).

You can also run it as iOS code by supplying the -ios commandline parameter — try this:

runcocoa -ios 'UIGraphicsBeginImageContext(CGSizeMake(100,100)); CGContextRef ctx = UIGraphicsGetCurrentContext(); CGContextSetFillColorWithColor(ctx,[[UIColor whiteColor] CGColor]); CGContextBeginPath(ctx); CGContextMoveToPoint(ctx, 50, 0); CGContextAddArc(ctx, 50, 50, 50, M_PI/2.0, M_PI/2.0 + (2*M_PI), 0); CGContextFillPath(ctx); UIImage *icon = [UIImage imageWithData:[NSData dataWithContentsOfURL:[NSURL URLWithString:@"http://atastypixel.com/favicon.ico"]]]; [icon drawAtPoint:CGPointMake((100-[icon size].width)/2.0,(100-[icon size].height)/2.0)]; UIImage *i = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); [UIImagePNGRepresentation(i) writeToFile:@"output.png" atomically:NO];'; open output.png;

Any other libraries to link in can be specified — command line arguments will be passed on unmolested to GCC. Add #imports with the -include parameter.

Grab the script from the Commandline-Cocoa GitHub project — make it executable (chmod +x runcocoa.sh), and move it to /usr/local/bin/runcocoa.

Developing software for me is an expression of my creativity, and an outlet for my compulsion to find order in the world — not to put things in boxes, but to shape the boxes around the things.

And if ever there’s an apt medium: If French is the language of love, Cocoa is the software development environment of it, too.

Anyone downloading the gazillion-gb iOS/Mac SDK + XCode on a slow and/or expensive connection will know the sheer fisticuffs-inspiring irritation this creates — speaking personally, living on a mobile broadband connection that’s usually changed at £3 per gig and often runs about as fast as I could send the data via carrier pigeon, this usually makes me want to storm Cupertino with a pitchfork.

Okay, so I could probably use Firefox or something else, but instead I figured I’d whip up^* a shell script that lets me use my favoured long-haul download tool – curl. And in case there were any other sufferers of insanely-priced broadband and Safari’s antisocial behaviour, I thought I’d share it.

It’ll ask for your Apple ID and password, and store it in the keychain for you, and it’ll resume from the current working directory.

Chuck it somewhere like /usr/local/bin, make sure it’s executable (chmod +x /usr/local/bin/adc_download.sh) and call it from Terminal like:

adc_download.sh https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_4_gm_seed/xcode_4_gm_seed_.dmg

If you’ve already started the download in Safari, just grab the partially-downloaded file from within the .download package Safari creates.

Here ’tis:

adc_download.sh

Update: Now includes team support, thanks to Christopher Bowns — see the comments at the top of the script for usage instructions.

P.S. I’d be interested to see how incremental updates fare when transferred from an intermediate server with rsync. It’s rather bizarre that Apple reissue the whole 3.x gb SDK with each update, rather than offering a ‘patch’ (I guess Apple lives blithely in the world of cheap bandwidth!), and it makes me wonder whether there’d be sufficient correlation between versions to save some bandwidth by avoiding transferring the similarities…

^* read: spend hours on, as is my way.