Monday, June 30, 2008

Weekly Update, Secret Plans Divulged, &c

I've been struggling with how to describe what I've been working on succinctly in conversation. I figure I can get about two sentences in before I start getting blank stares and eye rolls. I've been using something like this:

You know how when you put your ipod on shuffle, it magically knows what you want to listen to next? It's a little like that, but completely customizable, and instead of magic it uses a stochastic optimization algorithm.

Then they say something like "Hmm", or "Interesting," and then there's a long uncomfortable silence until someone changes the subject. "Can you believe this weather we're having?"

This is Week 2 or so for me, and forgoing things like "sleep" and "food", I've made some significant progress. The core of the bias code is written and more or less works. Random mode in working just dandy and if you're running the nightly or svn of Amarok 2, you can find it under the Playlists tab hiding out at the bottom.

Since the bias code is written and works, this is a good time to talk about my secret plan.

When a I first proposed biased playlists, I described biases as the chance that track has a certain property. Like "30% chance the next track is Jazz". I even made an aesthetically appalling mockup to show what I meant:

The secret is, that I've designed it to be much more general than that. A bias is any function that maps a playlist to a value in [0,1]. The solver will then try to find a playlist where all the biases are at 0.

Blank stares, eye rolls. "Can you believe this weather we're having?"

The point is: biases can do a lot more that what I described previously. Really, they can impose any kind of restriction on the random playlist being generated. For instance, Suggestion Mode, where the next track is from a similar artist as the previous, can be implemented as a bias. If Suggestion Mode is just a bias, it can be combined with other biases.

We could do Suggestion Mode + 30% Metal + 70% pre-1990, and it will do its best to find a playlist that matches fits. It there is no such playlist, it will just give you the best it can come up with.

This also really important because it lets us use fuzzy biases like: "arround 1976", "about 3 minutes", or "hasn't been played in a while".

Presumably, users could script their own biases, doing wacky things so playlists are random but tracks have increasing lengths, follow an obscure integer sequence, or their titles spell out a secret message.

The next few weeks i will mostly be concentrated on tweaking and optimizing the solver and working on an easy way to create biased playlists. There's a lot of work ahead, but I'm very excited with how it's gone so far.

3 comments:

Fantastic work. I had an idea similar to the "biases", which I coded up in a Python script last summer. It took numerical values (eg, song length, rating, bpm, etc) and a probability distribution (normal, exponential, lognormal, etc) and probabilistically generated a playlist. That sounds kind of like what you're trying to do with the "fuzzy" parameters. But my script didn't integrate really well with Amarok and I never released it, so I'm glad to see that someone else is actually getting the functionality into the program.