Archive for the 'Software Development' Category

I’m pretty stoked about releasing TapeDeck 1.0.1 today. It contains some huge audio code overhaulin’ that I started about a week before we shipped 1.0…

Just before we shipped TapeDeck, I noticed there was some utterly horrible skipping during audio playback. I attributed the skipping to a small jump in our CPU usage, right after adding the new Core Animation-powered HUD. It was so bad that TapeDeck was nearly unusable. This caused me to spend a 12h day rewriting our audio playback code (in a branch!).

The new code followed Apple’s recommendation for high-performance glitch-free audio playback. So I created a separate high-priority feeder thread reading chunks of a file’s audio data into a ring buffer that was consumed on the high-priority AU render thread.

I was about 80% done this rewrite when I realized that it was a different bug that caused this unbearable skipping to occur. I don’t recall the specifics, but I think I was re-seeking the file accidentally when some unintentional extra KVO updates got triggered. It was caused by the new HUD changes I checked in—are you surprised? :P

Content with the performance of the audio engine on my test systems (an 8-core Mac Pro, and a PowerBook G4 1.5), we shipped TapeDeck. Unfortunately, it still wasn’t perfect. I got reports that recent MacBook Pro machines were also experiencing the skipping, and some more heavy-duty testing on my PowerBook G4 was causing the skips to show up more often.

Well it was a good thing I kept the rewritten audio engine in a branch! I merged that branch with what we released in 1.0, and completed the last 20% of the rewrite. TapeDeck 1.0.1 contains this new, more efficient playback engine which should take up slightly less CPU time, and skip a lot less frequently (never say never!).

Unfortunately, I can’t say that the skips in playback are completely gone on my PowerBook G4 when you heavily load the system (I was able to get a few skips while doing compiles in Xcode), but they’re greatly reduced. On the other hand, I am unable to get TapeDeck 1.0.1 to skip on my wife’s MacBook Pro, even when pushing it pretty hard by browsing our very large collection of RAW photos in iPhoto—an operation that brought TapeDeck 1.0 to tears.

Anyway, this was the fix that required the largest effort in TapeDeck 1.0.1. I hope it solves the skipping problem completely for our users!

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.

Introduction

Improving FuzzMeasure to take advantage of Leopard under the hood was an exercise in patience and self-discipline. When I first learned about Objective-C 2.0, I wanted to just leap in and change every single accessor to use properties and turn for into for-each loops.

However, I didn’t have the time to do this, and I was smarter than that — mucking around in code that already works isn’t necessary. That said, there are benefits to ripping out code when you have the opportunity — less code means less bugs!. Also, converting to Objective-C 2.0 buys you other benefits behind the scenes, such as enhanced thread safety, proper memory management, faster enumeration, etc.

How does the one-man shop deal with balancing this lack of time with a mounting pile of important, but not time-sensitive, work? You page it in!

Read the rest of this entry »

I went to WWDC this year, and really enjoyed my time there. I got a lot of code written, a handful of questions answered, some new contacts at Apple, and a whole lot of motivation to keep innovating with FuzzMeasure. Sure, there were the keynotes, sessions, announcements, etc., but I found the real benefit was in the interactivity.

I met a lot of folks that I’ve been speaking to for years online, and some that I’ve never otherwise interacted with before, which added a whole other dimension of awesome to my trip. You can gain a whole lot just from attending the various parties and chatting with people in a laid-back setting over a beer (or a whole lot of fantastic tequila…).

On the more official front, you really do gain a lot from speaking directly with Apple’s engineers. Banging your head against a wall trying to figure out why an API isn’t quite doing what it’s supposed to can be very frustrating. Thus, having an engineer crack his laptop, check the source code, and tell you what’s going on under the hood is simply priceless. The labs are totally where it’s at.

If I could have done anything differently, I would have been far more prepared with questions and issues in advance. I found myself trying to create as many problems as I could while at the show so I had some more tricky issues to get sorted out as I hit them. That said, I think I got along just fine with the list of questions I encountered over the years, and I got a lot of names and email addresses to fire questions to in the future.

So, to those of you using FuzzMeasure, you have a lot to look forward to.

I was on the fence about attending the Leopard Tech Talk that came into Toronto on Friday. I signed up immediately to guarantee that I had a spot. As the event drew closer (and weather worsened), I couldn’t help but think that there would be not much added value over watching WWDC videos about similar leopard development topics.

The weather cleared up considerably during the week leading up to the event, and I heard that some key Apple personalities would be on-site, ripe for the brain-picking. My motivation had peaked, and I was all set.

Now that I’ve gone, I can’t say enough good things about the event. The food was excellent (and free!!), the people I spoke with were all very helpful, and I heard a lot of nice things about FuzzMeasure!

The only down side was that I couldn’t attend more of the talks! If I could have somehow split myself into two and attended simultaneous talks, I definitely would. Furthermore, it was nearly impossible to go to all the talks and speak with the tech support folks. I would also highly recommend that you go prepared with solid questions and examples beforehand, so you can get more done in less time.

I have a lot of work to do in FuzzMeasure to gain some of the extra functionality that Leopard will bring to the table. I also have to spend a lot of time learning some of the new developer tools and familiarizing myself with the new APIs available to me.