This is part 2 of a series following the development of Loopy, my iPhone app.
In part 1, I wrote about Loopy’s interface. Part 2 will be more technical, and will cover some challenges encountered during the evolution of Loopy from concept and mockup to working software. Or, more specifically, the stupid things I did along the way.
Read MoreLinks for January 31st through February 9th:
Loopy is my first iPhone app, a loop-based performance/musical scratchpad app based on looping audio equipment and inspired by, equally, the fantastic and free “Freewheeling” application, and an a capella performance by Imogen Heap.
It’s development was a whirlwind of obsessive coding, near-vertical learning curves, impatience, excitement and occasional burnout and writers block.
I thought I’d share some facts and lessons learned from the process, in a several-part article. For part 1, read on.
Read MoreLinks for November 13th through November 17th:
I’ve had nasty old time trying to get some audio stuff going on the iPhone, no thanks to Apple’s lack of documentation. If you’re an iPhone developer interested in getting RemoteIO/IO Remote/whatever it’s called working on the iPhone… Do I have good news for you. Read on.
Read MoreThis will only be of interest to a very small minority, but for those of us who have used Core Audio and come across error -66632 in all its glorious undocumented-ness, this is a helpful note.
The error occurs when using AudioQueueEnqueueBuffer. It happens when one tries to enqueue a buffer when the queue in question is no longer running.
Wrap the AudioQueueEnqueueBuffer in a statement that checks to see if the queue is actually running, as in the SpeakHere/SpeakHear (depending on where you look) example. Something like:
if ( [track recording] ) {
// Re-enqueue this buffer
status = AudioQueueEnqueueBuffer (inAudioQueue,
inBuffer,
0,
NULL);
checkStatus(status);
}
..Should do the trick.
Read More