Capo 1.1.1 Available

• Chris Liscio

I just pushed the latest release of Capo online. Go grab it at the Capo site.

As usual, release notes for Capo are available. Instead of simply leaving it at that, I'm going to give a little bit of commentary on what I fixed, since I don't want the release notes to get overly verbose.

Album art is now available immediately after it is retrieved from the iTunes store, and not after QuickLook has gotten around to caching it.

I found this issue while testing Snow Leopard, though the issue likely occurs on Leopard as well. I moved a bunch of music over to my test machine, and couldn't see any album art for tracks dragged into Capo. What gives?

I discovered that there is a window of time between acquiring album art from the iTMS, and Capo being able to see that album art. Further investigation revealed that this also resulted in the Finder, and QuickLook previews being unable to view album art during this time. In one case it took a few days to clear up, and in another case it was only few minutes (likely shortened by my poking around using qlmanage, which always showed album art immediately after getting it in iTunes). I filed a bug ( rdar://7123568 ) thinking that the Finder, and QuickLook, got screwed up in Snow Leopard.

Some further investigation into the matter (with the help of Apple's engineers assigned to the bug report) revealed a workaround that let Capo access that album art before QuickLook got around to caching a thumbnail for the audio file. Because Capo acquires the album art on a separate thread, I'm able to take the slower route of forcing QuickLook to dig beyond its cache and generate the album art thumbnail for me on demand.

Fixed crashes reported by a small group of users.

Oddly, I never encountered this one during pre-release testing. However, if the effects window was disclosed, and Capo was left to play audio for a little while (anywhere from 10 seconds to 10 minutes, in my testing), it'd crash. It turns out I had a bad getter which didn't call 'retain] autorelease]' on its returned value.

In many cases, that's not a big deal, because most code runs in a single thread, and you can be certain that the value won't go away in between you retrieving it and retaining it shortly thereafter. In this particular case, the value was being released (and freed!) in a separate thread—before the value had a chance to be retained. Oops!

Normally I rely on Objective-C 2.0 properties for my getters and setters, but in this case it's an indexed accessor (valueForIndex:) which I had to implement manually. Objective-C @properties are written in such a way that all member variables are retained and autoreleased (or copied and autoreleased) in the getters depending on how you set up your property (for retain and copy, obviously).

Cleaned up a handful of small memory leaks.

I decided to run Instruments again on Capo and clean up every little loose end I found. It was fun to find my way around the new version that ships with Snow Leopard.

Removed assertion failures that may have showed up in the console when mono files are played. and When mono files are played, spectrum data is shown properly in the effect views.

Both of these were found by me while testing the fixes for the above issues. It was just a fluke that I even encountered a mono file in my testing (I recorded it using TapeDeck), and I couldn't let myself ship the other fixes until I cleaned this one up.

So, there you have it—a glimpse into all the work that goes into a tiny maintenance release. It was fun to do this little postmortem, and I hope to do them more often in the future.