A Tasty Pixel » Geekspeak

Objective-C + Cocoa on the Command Line

Sometimes there’s just one tiny snippet of Cocoa code that you want to test — maybe to find out the output of NSDateFormatter for various cases, testing out some text replacement routine, or testing out some image drawing code.

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](https://github.com/michaeltyson/Commandline-Cocoa)

What I’ve been up to: Loopy 2 (track importing)

Here’s the result of the last few days’ work: [Loopy 2](http://loopyapp.com) now has track importing. Drag audio files into Loopy’s documents folder in iTunes, then import into tracks. Loops are automatically time-fitted for perfect synchronisation, using the frankly awesome Dirac audio processing library.

Oh, Cocoa: Why I love my job

There are some with a passion for paint and canvas; others, for playing musical instruments, or writing stories. For me, as I’ve discovered, it’s striving to create beautiful and functional user interfaces, or constructing in code the perfect representation of a workflow. It’s creating a piece of software that works like an extension of yourself, with the charm and elegance that makes you want to pick it up, and not put it down again.

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.

Resuming ADC downloads (‘cos Safari sucks)

So, Safari’s resume facility is just awful — it’ll randomly restart downloads from the beginning, clobbering anything that’s already been downloaded, and the resume button will frequently disappear entirely and mysteriously from the downloads window. And if the session has expired, it’ll cause all kinds of havoc.

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 Script (on Github)

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.

This made my day: An App Store review

App Store reviews often seem to be an odd mix of bile and vitriol, misplaced support requests, and glowing praise, making my routine App Store review-sweep somewhat of a rollercoaster!

This time around, though, this review of The Cartographer made my day (this is the kind of person I write apps for!), and I had to post it here:

A quick-and-dirty audio sample mixing technique to avoid clipping

In the real world, when you hear two sounds at once, what you’re hearing is the combination (in the “+” sense) of the two noises. If you put five hundred drummers in the same room and, avoiding the obvious drummer jokes for now, told them all to play, you’d get drummer 1 + drummer 2 + … + drummer 500 (also bleeding ears).

With digital audio though, the volume doesn’t go up to oh-god-please-make-them-stop – it’s limited to a small dynamic range.

So, digital mixing actually requires a little thought in order to avoid overflowing these bounds and clipping. I recently came across this when writing some mixing routines for my upcoming app Loopy 2, and found a very useful [discussion on mixing digital audio](http://www.vttoth.com/digimix.htm) by software developer and author Viktor Toth.

The basic concept is to mix in such a way that we stay within the dynamic range of the target audio format, while representing the dynamics of the mixed signals as faithfully as possible.

Pushing MultiChannelMixer to the limit

A friend made an interesting suggestion to an issue I’m facing in the upcoming Loopy 2, and I thought I’d do some investigation: How many tracks can the [MultiChannelMixer (kAudioUnitSubType_MultiChannelMixer)](http://developer.apple.com/library/ios/documentation/MusicAudio/Conceptual/AudioUnitHostingGuide_iOS/UsingSpecificAudioUnits/UsingSpecificAudioUnits.html#//apple_ref/doc/uid/TP40009492-CH17-SW8) manage at once?

He was quite optimistic, and as it turns out, he was right: It’s rather capable.

I modified the [iPhoneMultichannelMixerTest](http://developer.apple.com/library/ios/#samplecode/iPhoneMultichannelMixerTest/Introduction/Intro.html) sample project to add a bunch of channels, and measured how my iPhone 4 performed. It looks pretty linear: there’s pretty much a 1:1 relationship between number of channels, and the CPU usage, actually.

Of course, this is on the newest-most powerful iPhone, but there was no stuttering, and the interface (admittedly simple as it is) was fully responsive, including setting output volume, even with 100 channels. You’d probably want to stick with a maximum number of channels around the 75-100 mark, less for targeting lesser devices, but that’s a pretty generous limit.

Not bad.

Update: Not such great news for the iPhone 3G I just tested this on, though — it freaks at anything more than 20 channels, and isn’t too responsive with 20. The 3Gs seems to behave almost as well as the iPhone 4, but the CPU:channels relationship is more like 2:1.

Breaking the limits: Storing data bigger than 1 Mb in Google App Engine’s Datastore

Google App Engine is a fantastic platform for hosting webapps, and a great resource for iOS developers who need an online component to their products. It’s hard to believe that the service is essentially free! I’m using it with [The Cartographer](http://cartographer-app.com), but I found myself coming up against a hard limit with the datastore.

You see, the [datastore](http://code.google.com/appengine/docs/python/datastore/overview.html) limits entities to 1 Mb. I’m trying to store XML data in there, and sometimes that can exceed the 1 Mb limit.

XML being the verbose creature that it is compresses very nicely, so it occurred to me that if I selectively compress the larger blocks, I should be able to quite easily squeeze in underneath the limit. Sure enough, a 1.6 Mb XML block compressed into about 200 Kb.

App Engine makes it very easy to define custom properties on data models, so I’ve written a CompressibleTextProperty class that automatically compresses/decompresses properties above a certain size. This means that there’s no performance loss for entities that are small enough to fit easily, but still enables the storage of bigger blocks of content.

The alternative was to break entities up into several different database entities, but this sounded like much more work, and sounded much less elegant.

So here’s what I came up with — it’s used the same way the other [Property types](http://code.google.com/appengine/docs/python/datastore/datamodeling.html#Property_Classes_and_Types) are used.