Jambox Update

In my free time, I’m working on yet another music player, called Jambox. Once I make one or two more changes to it, I’ll post a development release of it.

Jambox was born largely out of frustration with the utter lack of playlist management in XMMS (a Winamp clone). The XMMS playlist model is fine when you’re only working with a few dozen songs, but it doesn’t scale at all to having thousands of songs split among hundreds of different artists and albums.

The design of Jambox is somewhat similar to Rhythmbox (a sort of iTunes clone for GNOME), but not quite. In addition to the usability problems I’ve experienced with Rhythmbox, I don’t like some aspects of its underlying design philosophy (such as its increasingly tight GNOME integration, whereas I don’t actually *use* GNOME).

The basic philosophy of Jambox is that you have a bunch of songs that make up your library. You build a playlist not by choosing what songs go into it, but by specifying a set of rules that are applied to the library; all songs that match the rules go into the playlist. Right now, rules are limited to selecting from the available genres, albums, and artists, but in the future I hope to add more advanced rule capabilities if I see the need for them. This has the advantage that if you have a playlist with songs from artist X, and you get more songs from that artist, they’ll automatically appear in the playlist.

Right now, Jambox is near the point of having all the basic functionality you need to use it, along with some bells and whistles that I really like, particularly, XOSD support and the ability to run in Blackbox (or other window manager’s) slit.

The only thing I think that I need to do before releasing a development version of Jambox is to improve the track scanning code. It was one of the earlier things I wrote, and although it works, it doesn’t work particularly well. It ties up the UI thread and uses a pretty inefficient, brain-dead algorithm. It was fine when I just wanted something to let me work on more interesting parts of the code, but I don’t think it’s in a releasable state.

Yes, yes, I know, premature optimization is the root of all evil, but by making it more efficient, I mostly mean using a more efficient and appropriate data structure (the C++ hash_set instead of std::set) and reducing the amount of unnecessary work that’s done during the update.

Of course, since I haven’t had much free time at all lately, there’s no telling when I’ll actually get the chance to make these changes, tar them up, possibly make an unofficial deb of them, and post them.

Comments are closed.