The Road to TapeDeck 1.0

Wednesday, May 14, 2008 • Chris Liscio

In late September 2007, Dan Sandler had started egging me on to develop a simple audio recorder. I was well within shipping mode for FuzzMeasure 3.0, and couldn’t do much more than talk about it at a high level.

In late November 2007—just before FuzzMeasure 3.0 shipped—Dan and I started talking more seriously about this simple audio recording application that just had to be written. Wrap up the Audio Queue Services API in Objective-C, add a great UI to aid in collecting the tapes, and it shouldn’t take very long at all, right? :)

By mid-December, Dan had some UI sketches which resemble what TapeDeck looks like today. There’s a ‘current’ tape in the player, some cassette recorder controls, and a list of tapes in a box. I had already built a prototype recorder by this point, complete with a tape, rotating spools, and an audio level meter. It looked nothing like the application we shipped. You could record audio straight to m4a files, and it worked fine. Effectively, at this stage, we were running Apple’s sample code with a UI on top.

Over the holidays, I spent a few days implementing the nuts and bolts of the early UI prototype. I wrote the UI a few times using Quartz, then Core Animation, then Quartz again. I probably wrote the bits that rendered the tape and its labels three times during this period.

In January, I had been busy with my job, and planning to leave (because FuzzMeasure was doing great, and I thought we had a real winner on our hands with TapeDeck). However, in every spare moment I could get, I would squeeze in fixes for FuzzMeasure, and code for TapeDeck. It was during this time that I decided I should get started on writing MP4 tags to the recorded files.

This was an extremely complicated undertaking, since Apple doesn’t provide an API to modify metadata on M4A files! So, I ended up writing an entire Objective-C library that is capable of parsing, and manipulating MP4 atoms (or boxes, depending on who you talk to), with the addition of the magic bits of metadata that work in iTunes. This was a very difficult piece of the TapeDeck puzzle, and it was fun to get working!

In early February, I left my job to work on SuperMegaUltraGroovy full-time. I spent some quality time with FuzzMeasure, cleaning up some bugs, and took a bit of a vacation from TapeDeck work.

By late February, Dan had sent me a mockup that looks very much like what we see today in the shipping version of TapeDeck. Initially, I wondered how on earth we would implement this–custom UI code, custom window drawing, etc. It seemed like a nightmare, but I put my head down and went for it.

Throughout March, Dan worked on our type logo for TapeDeck, and refined our plastic cassette rendering. I had the UI starting to look very much like the prototype at this point. Lots of work was done internally to support the box of tapes, and manage the collection with Core Animation–the UI that was written over the holidays was reworked again!

In early April, I had started playing with the speaker grilles. In order to really get the look of a cassette recorder right, there had to be speakers above the area where the tape sits. We had a few mockups with the speakers sitting somewhere between the tape and the controls, but once I drew up the grille pattern you see today, we had a winner. When the tape box was closed, TapeDeck really looked like a cassette recorder. Also, adding height meant the user could see more tapes at a glance, which was a nice end result.

By mid April, TapeDeck looked very much like TapeDeck 1.0 does. We were tweaking all sorts of the UI, and finishing off the functionality. The Design Awards deadline was announced, and I openly wondered if we could ship on time. I figured we might as well go for it, because external schedule pressure is always effective to maximize my use of time. :)

During this period, I got to the part where we wanted to implement seeking and FFWD/REW functionality. This is where my use of Audio Queue Services had to end. We wanted our tapes to play very quickly when seeking through the tape (in both directions!), which meant we had to do some trickier things within the audio stream. So, I took a week to rewrite the audio playback engine so that we could support full FFWD/REW functionality, as well as the accurate seeking of the audio stream.

I also decided that we really had to render an accurate image of the tape in the album art of each m4a file. This was an interesting thing to pull off using Core Animation, but the results were amazing when it was done.

In late April, TapeDeck began its beta. Tons of feedback came in, and we actually added the pause functionality in response to user feedback. I was coding at an amazing level of efficiency during this time.

Dan sent a mockup of a new HUD layout (recording and playback controls) to me on Friday, May 3rd, and I didn’t receive it until I woke up on Saturday, May 4. When I went to bed that same night, I had implemented the entire thing from the ground-up using Core Animation, borrowing bits of code from the old HUD. A great deal of this incredible implementation speed is due to Dan’s amazingly detailed mockups. He had effectively written a full specification with clear instructions about how each component would behave, alongside the detailed drawings.

In the last stages of the beta, tons of little bug fixes went in, and smaller aspects of the UI were cleaned up. Dan quickly put together our launch website, and threw a little easter egg into TapeDeck. We were smoking towards completion, and by May 8th I felt we’d done the impossible - we made it to 1.0!

I sent a copy to a few key folks in the media, and they all seemed to really like it! From there, the launch has just been incredible. We’re getting a lot of really positive feedback about TapeDeck, and we’re very proud of what we’ve done. You will find a tally of our media coverage in Dan’s blog post about TapeDeck 1.0.