Bugs Fixed/Changes

• Music Rescue no longer crashes on launch on Mac OS X 10.4.

Music Rescue 4.0.13 can be downloaded from the Music Rescue product page.

Bugs Fixed/Changes

• Fixed “ASL.dll could not be found” message.

Music Rescue 4.0.14 can be downloaded from the Music Rescue product page.

Bug Fixes/Changes

• - Mac OS X 10.5.x users can enter currency values again.

All KennettNet applications are Snow Leopard 10.6 compatible.

For best results, we recommend updating to the latest versions of Music Rescue and Clarus. No major problems were found, but a couple of tweaks were made:

- Music Rescue 4.0.7 and higher now displays file sizes in a consistent manner to the rest of the system when running on 10.6. File and disk sizes are displayed to match drive manufacturer advertised sizes in Snow Leopard, and Music Rescue follows suit.
- Clarus 1.0.4 and higher correctly displays it’s German localisation on 10.6.

The next major updates to Clarus (version 1.5) and Music Rescue (version 5.0) will contain 10.6-specific features (when running on 10.6) that we’re really looking forward to bringing to you.

For the past four years, Music Rescue has been our only income-earning product. This is great and all, but it makes us dependant on the Pod ecosystem. More importantly, we’re dependant on a single feature that iTunes doesn’t have - the ability to import songs from an iPod back into your library. Apple half-added this feature a while back and now you can copy iTunes-purchased tracks back to your library right within iTunes.

The other thing with Music Rescue is that when someone emails or calls with a problem, they’re not just pissed - they’re super pissed because they just lost all their music and now they can’t get it back. Nine times out of ten the problem is a mis-typed license key, but sometimes it’s not, and sometimes the customer doesn’t seem to understand that it’s not our support person’s fault.

Finally, Music Rescue is coming to the end of it’s income-earning life. We’re simply running out of useful features to add to it! The list of things for 5.0 is short - support for photos and a couple of other things. We’ll remain committed to Music Rescue throughout 2010 and probably beyond, but it’s time to start bringing in other products.

The Rise Of Clarus

So, what to do? Well, at WWDC 2008 I came up with an idea - a cool iPhone application which has been in development ever since. However, since the iPhone app requires a server-side component which needed to be finished before the application could really be started, progress was slow. In January 2009, I adopted Chester from a rescue home. Immediately I noticed that there wasn’t a single good application for the Mac to keep track of the piles of paperwork for him. Clarus was born!

My Favourite Things in Clarus

Developing Clarus was a blast. It has a completely different feel to Music Rescue, which is refreshing. Music Rescue is normally a one-stop app - it presents the iPod’s contents in a way instantly recognisable to the user and recovers it back to your computer with the minimum of fuss. The typical usage time for Music Rescue is minutes to hours, depending on the size of your library.

Clarus, however, is an application that I intend to be used for years on end. Hopefully the application will grow up alongside your pets, and despite the short overall time, I’ve spent a lot of time on the little things that’ll make living with Clarus an enjoyable experience.

Guides

System 7.x and 8.x had a thing called Apple Guide that’d walk you through a task step-by-step, highlighting the controls you needed to interact with as you went. This was much better than the current system, and I loved the old system so much that I spent nearly three weeks bringing it to Mac OS X. User help is often at the bottom of a developer’s list of things to do - mainly because you need to have the application nearly completed before you can write it. As a result, it tends to be rushed or not even there at all. Clarus, however, has the normal help content you’d expect from a decent Mac app as well as these guides to walk you through specific tasks.

Others in the Mac developer community seem to really like the idea, so I ended up making the framework for doing these guides available to them for free, and have committed to making a decent guide editing program. You can find more about the guide framework here.

PDFs

This isn’t really mentioned much in the program’s documentation or feature lists simply because it’s so natural. If you have a PDF containing your pet’s insurance policy paperwork, just drag it from the Finder, Mail, or wherever onto the policy in Clarus. The PDF will be attached to the insurance policy inside Clarus and kept within the document. This works with insurance policies, vet visits, medications and contacts.

System Integration

One of the best things in Mac OS X, from a developer’s perspective, is how Apple allows you to integrate with more or less everything. For example, in Clarus:

- A pet’s contacts are stored in Address Book, so you don’t need the application open to call your vet. These will be synced to your iPhone if you desire.

- If you have “Track Pets in iCal” option switched on in Clarus’ preferences, Clarus will automatically put important stuff (with a reminder) into an iCal calendar for each pet.

- When you Quick Look a Clarus document, it’ll tell you the the closest important events for that pet. This is especially cool, since it actually reads the document and figures it out rather than just relying on the application putting that stuff in there. 

- Clarus is scriptable, which instantly makes its data compatible with pretty much every other scriptable app on your computer. Want your photos in iPhoto? Easy! Your expenses in Numbers? Done! A few little scripts ship with Clarus, but expect more as I think of awesome stuff to do.

Artwork

Of course, it’s no secret that I love artwork. For Clarus’ artwork, I one again contracted Fernando Lins, and he did a superb job, and scored extra nerd points in the application icon itself (atop this entry) - see if you can spot why.

Here’s a few of the pieces of art used in Clarus, including a couple that didn’t make 1.0 but will be in 1.1 and 2.0. My personal favourite is the “Album” piece, which I think really captures the sillyness that is often present in a group of pictures of your pet!

“Owning a pet is a wonderful experience. However, keeping track of their important paperwork is not” said Daniel Kennett, founder of KennettNet. “You probably have folders full of documents, and your wall calendar is littered with little reminders to give a flea treatment or to go to the vet for a checkup and more. But no matter how organized you are, there’s always that worry that you’ve missed something.”

So they’re always available, all important contacts are stored in Address Book. At any time, pet owners can QuickLook a Clarus document and immediately be given an overview of what’s up and coming for their pet. One of Clarus’s most prolific features is its poster creation and printing support. So if Spot just happens to go missing, printing a bold missing poster that includes his photo and basic details along with contact information with reward takes just seconds.

Feature highlights include:
* Manage a pet’s life all in one convenient place
* Fully integrated with Address Book, iCal and QuickLook
* Poster printing support
* AppleScriptable

Language Support:
* American English, British English, French, German and Spanish

Minimum Requirements:
* Mac OS X Version 10.5 Leopard or later
* Universal Binary for PowerPC and Intel
* 16.0 MB Hard Drive space

Pricing and Availability:
Clarus 1.0 is available for only £15.00 (GBP) for a single machine license. Licensing allows more than five contacts, insurance policies, medications and vet visits to each document. A free trial version is available for download. Review licenses for Clarus are available for media review.

I invented PodUtil in 2002, in a physics lesson at 6th form when I should have been learning about… something. My computer’s music library had broken and I wanted the music back. The program simply scanned the iPod’s file system for MP3 files and extracted their info from the ID3 tags. It wasn’t very good.

PodUtil 2.x

This version of PodUtil scanned the database of the iPod, and was much faster. However, the database parser wasn’t very good, and I can’t post any screenshots up here because it doesn’t work with any of my current iPods. Yay!

PodUtil/Music Rescue 3.x

PodUtil became Music Rescue at version 3.1, and was the version that hit it big-time, as it were. Until yesterday afternoon, Music Rescue 3.1.6 was the newest version of Music Rescue available from our website. It works with all of the iPods available today (other than the touch/iPhone) and sold well.

What next?

When thinking about Music Rescue 4.0 back in 2007, it was fairly clear that I’d have to re-write Music Rescue from scratch. The codebase was, to be frank, disgusting. Music Rescue 3.x was a mishmash of code with no real design, and still had parts from early betas of version 2.x, just patched up to work better. Inserting features I wanted to add would mean ripping it all apart and refactoring it so extensively that scrapping the codebase altogether and starting fresh was looking like the only way forward.

I took this opportunity to change the language Music Rescue was written in. Versions up to 3.1.6 are written in REALbasic - a cross platform tool that allows you to have one set of code compile an application on Windows and Mac OS X. It’s great for our earlier situation where there was just me writing the program, but now I have manpower at my disposal so it was decided to write the Windows version in .NET and the Mac version in, of course, Objective-C/Cocoa.

Development and Design

After incrementally updating Music Rescue 3.x for years, I’d forgotten what a massive project it is - I was originally hoping to release in early May, but the final release ended up in late July.

It was important to design Music Rescue in perhaps a more compartmentalised manner than I normally would. Apple is constantly evolving the iPod line and to keep up, I need a codebase that’s easily extensible. A good example is photos. I actually wrote a parser to parse and load images from an iPod’s photo database pretty soon after Apple released the first iPod photo in 2004. However, there was absolutely no way I could wedge it into PodUtil/Music Rescue without a lot of work - too much to justify it with more pressing matters at hand.

Now, Music Rescue 4.0 still doesn’t have photos. However, it’s internally designed so it’ll be very, very easy to plug in that functionality in version 4.1 or whenever I write an up-to-date iPod photo engine.

The core application code doesn’t actually know about anything about iPod tracks, at all. The core application simply declares interfaces for:

• CopyableItem Something which can be copied to a file on the local filesystem.
• PlayableItem Something which can produce a QuickTime movie to play in the media player.
• DataProvider Something that appears in the source list and has a view for the user to interact with. For example, “Music” in Music Rescue source list is a DataProvider, along with Podcasts, Video, etc. DataProviders can optionally have subproviders which will be plaed in their own group, such as playlists or photo albums.
• CopyTask Something that can copy CopyableItems to the local filesystem. DataProviders can optionally create CopyTasks. If they do, they’ll be included in QuickRecover and the copy setup sheet.

... you get the idea. When Music Rescue loads an iPod, the iPod instance itself is responsible for the DataProviders for that iPod - when the NSWindowController for the main window is populating the source list, for instance, it looks through the [[[self document] iPod] dataProviders] array.

Let’s see how this fits together in the UI:

The items in red are individual DataProviders from the iPod represented by the window’s NSDocument. The ‘PLAYLISTS’ group are the sub providers provided by the Music Provider. 
The blue area is the NSView provided by the selected DataProvider.

When copying, you’ll see this UI:

This time, the red items represent the CopyTasks provided by the DataProviders, and the blue area is the configuration UI for the chosen task.

Hopefully by now you’re noticing a trend - the application doesn’t really make any assumptions about what’s actually on the iPod. It just provides interfaces for something else that knows how to deal with specific media, how to show it to the user and how to put it somewhere useful on the local machine.

This is a huge shift in paradigm from how previous versions worked. When you clicked a playlist in Music Rescue 3, a playlist object gets set as the current playlist, and the table view on the main window shows the tracks in that playlist. That’s fine, until you get things that aren’t playlists. Again, in Music Rescue 3, the program copies files from the iPod to a folder on disk. Which, again, is fine until you encounter photos (which are embedded in a database in some strange format) or an iPod touch (which doesn’t mount on the filesystem).

Instead, version 4 has controllers that deal with the objects that deal with specific data. The NSWindowController and NSDocument pair deal with showing the DataProviders to the user, and a thing called CopyProcessor that takes the CopyTasks that are generated by the Providers, loops through them one by one and tells them to do their thang while it sits there and waits for the copyDidComplete: delegate method to be called.

Something that wasn’t done by accident is that this model lends itself very well to plugins. It’d be trivially more work for me to implement photo support as an external plugin - in fact, the internal Music, Podcasts, etc providers are essentially plugins whose classes sit in the same binary as the rest of the program.

Drawbacks

There are some drawbacks to this method, though.

The first is that it can cause a lot of duplication. For example, the Music, Podcasts, and Audiobooks providers in Music Rescue are all showing the same kind of object in much the same way, and yet they all separately need to manage their items, whether they’re to be copied, etc etc etc. Much of this can be dealt with by having them all subclassing a general purpose “iPod audio track” provider, but there’s still some unavoidable duplication, especially in the nib files.

The second is that it can cause a lot of extra work early on. This is more of a morale issue than anything - you spend a lot of time building protocols and laying the frameworks for all this, but for a long time you don’t seem to be making any visible progress - when you run your app, there’s no new functionality there and it can become very tempting to bypass your hard work and take shortcuts. This, though, it somewhat offset by how easy it is to to add functionality to a well-designed framework.

I *heart* Cocoa

This is the first major project I’ve done in Cocoa, and is honestly the most fun I’ve ever had programming in my life. There’s so much completely awesome stuff in there that it makes coding in anything else less enjoyable than it was.

This causes problems for my colleague, though. He’s writing Music Rescue in .NET, which doesn’t have a lot of the awesome stuff I’m using - but we’re trying to keep the internals as similar as possible between the Cocoa and .NET versions for consistency’s sake. In the end, I ended up writing a few Cocoa classes in .NET to keep functionality the same. They were:

• NSNotificationCenter/NSNotification
• NSTokenField
• NSTableView and everything it needs - NSTableColumn, NSCell, NSActionCell, NSTextCell, NSButtonCell, etc etc.

That last one was hard. NSTableView is a beast, and custom-writing a table is a pain in the ass. However, .NET’s built-in table is so completely useless that it was necessary.

Personal Issues

Quite an odd one, this, and something I won’t have to experience again. Up until version 4.0, every single line of code in Music Rescue was written by me. Those lines of code have gone on to pay for my cars, mortgage, and general living enough to do it full time. Music Rescue is, in essence, my baby.

Switching it over to multiple developers was a tough thing for me to do - and I’ve been constantly uneasy about not being in complete control of my program any more. However, it’s paid off - it’s allowed Music Rescue to become a much better product that it could be with just me developing it.

Conclusion

Now version 4.0 is released, I can say the decisions I made about the development methods have paid off. I’m really excited about version 4.0, and it’s the best program I’ve ever written.

What would I do differently if I was to have to do it again?

Well, nothing really. That’s not because I did it perfectly, but because I don’t know enough about software design to think of a better way to do it. I’m sure than in a few years I’ll look back at my code and cringe, just like I do now at version 3.x’s!