A Tasty Pixel » Posts

Parsing iOS watchdog 0x8badfood hang reports

During beta testing of Loopy Pro, a tester had the misfortune to come across a hang-on-launch bug of the “exhausted real (wall clock) time allowance” kind that I couldn’t reproduce at all.

Annoyingly, when that happens, iOS often produces an unusable “ips” crash log which doesn’t at all resemble the normal, symbolicate-able kind – it’s pretty much just bunch of JSON with very little helpful content.

I got desperate, and wrote a parser to convert that JSON log into the normal kind, which can be symbolicated by the tool provided by Apple (which lives at /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash, by the way).

It’s just a quick-and-dirty PHP script, but it does the job, and I was finally able to see what was happening during the hang.

Loopy Pro: First Look

Exciting times, people. This is a first look at LOOPY PRO: A professional live-looper, sampler and sequencer for iPad and iPhone. Coming very soon – subscribe at loopypro.com for news, and beta access when the time comes (VERY soon)!

It’s been a long time coming. But I think you’ll agree, it’ll be worth the wait.

Put on your sampling pants: The Samplebot has arrived!

On sale, and available for iPhone and iPad!

Samplebot is a collector of sounds. It’s a crafter of songs. It’s a finger-drummable looping sequencer of rainbow glory, and it wants to be your friend. Come. Play. Robo-boogie.

Record sounds. Make songs. Do a dance.

Record or import samples, then play them back on beautiful, sproingy rainbow pads!
Then record or input arrangements using the sequencer
Revel in the power of built-in drum patterns, loop record and playback, quantization and copy/paste
Trim samples, and adjust volume and balance for the perfect mix
Share your creations to Facebook, or export them to other music apps
Comprehensive MIDI control with velocity, for play using a grid controller like the Launchpad
Helpful and fun-loving intro tutorial

Announcing: Samplebot

Hello, friends!

I’ve finally emerged from the depths of coding – and, I might add, the joyous but rather engaging throes of new parenthood of a quite charming little boy! – to make an announcement.

No, it’s not what you think: Loopy Masterpiece Edition, now named Loopy Pro, is still a little ways off. But I have something to tide you over.

Samplebot: Beta test me!

It’s a new app! A taste of things to come, if you will. It shows off some of the features to come in Loopy Pro, but with a special focus of its very own.

It’s called Samplebot, it’s a sampler/sequencer, and I hope you’ll love it.

Now’s the part where you come in: I need your help, right now, to test it, stretch it, break it, find its weaknesses and crush them. Because this bad boy is coming out this month.

So, interested? If yeah, head on over to samplebotapp.com, pop your email in and tick the box, and let the robo-boogie begin.

Loop the World

Musician and Loopy user Gaspard Bonnefoy has just set out on an adventure around the world, live-looping with people from all around the planet. His first stop is Dubai, where he met up with sax player Daniel Contreras. Definitely a journey worth following! (Facebook, YouTube)

Local Continuous Integration Setup With Git Post-Commit Hook Script

I have lots unit tests, but I don’t have a Continuous Integration server setup, and I sometimes forget my tests are there.

I know. Bad me. I was up late last night getting some failing unit tests to pass again, after forgetting I even had unit tests. Ugh. This would have been much easier if I knew I’d broken a test when I broke it; as it was, I had to go back and try to remember what I was working on when they broke!

So, to stop that happening in the future, I fiddled around with my local repository and whipped up a script that automatically runs tests in the background, on a separate temporary cloned version of the repository.

If build or tests fail, I get a nice little Notification Center message which I can click to see a report and build log. Then I can fix it and amend the commit as necessary.

It’s a script that’s invoked by a Post-Commit git hook, and it’s run in the background using nohup so it doesn’t make me wait and mess with my workflow. It just all happens transparently in the background.

Here’s how I did it.

This is a discussion of four common mistakes that audio developers make, how to do better, and how to detect whether there’s a problem. It’s written primarily for developers, but should be accessible to non-developers too. I introduce Realtime Watchdog, a diagnostic tool for developers, and provide a brief survey of popular audio libraries.

Making audio apps is enormous fun — it’s rewarding, there’s huge scope for creativity, and then when you’re done, other people use it to be creative too! There aren’t many fields that are like that, and I consider myself very fortunate to be able to work in this area.

But there’s also a serious side to working with audio. As audio developers we have a responsibility to our users to, basically, not embarrass them in public. A DJ whose equipment emits an ear-piercing crunch mid set will not thank us (well, it depends on the club. Maybe they will?). Nor will a performer whose backing drum machine clicks and crunches distractingly, throwing the performance. Same goes for in private — if the user just nailed a take, only to discover that there’s a giant click in the middle of the recording, they’re going to be cursing our name.

Now we’re living in a post-Audiobus/IAA world, where our users’ setups often span multiple apps, one bad actor can mess everything up, and it’s often impossible to tell from where the problem originates.

Imagine if Loopy HD had glitched in the middle of that?

The audio engineer on The Tonight Show told me the main reason that they chose Loopy for the looping segments with guests was because he had been a Loopy user for years, and it has always been solid and reliable.

Even if there’s just a one-in-ten-thousand chance that an app will glitch during a typical session, well, that’s one glitch a day if your app sees ten thousand sessions per day, which is not uncommon. Two glitches a day if it has twenty thousand sessions a day. And I’ll bet most music apps have a higher glitch rate than that.

It can take just one glitch during a live performance for a musician to completely lose faith in their whole setup. The one thing they cannot troubleshoot in their setup is their apps, because it’s an opaque system. And so every app they’re using is indicted. They’ll stop using all of them. It’s an angry Facebook post to all of their musician friends waiting to happen; the exact opposite of what anyone reading this would want.

So, it’s this duty of care that we audio developers have that I want to focus on in this article, because our music apps have to be solid and reliable. All of the time.

If you’re interested in the technical details around how music apps get made, this is an excellent talk by music technologist Greg Cerveny on creating music apps. He’s interviewed a bunch of developers (including the developers of Patterning, Fugue Machine, Elastic Drums, and me) about their process and their background, and these are the results. Worth a watch!