hi,

Is there any place where I can find detailed documentation about the new Dynamic Playlists in Amarok 2? I understand the basic idea of the proportional and fuzzy biases, but they're implemented a bit stiffly. That aside, this isn't a suggestions post, I just want to know more about the way they work.

A specific question I had was; If I add numerous Proportional Biases (40+ is what I'm going for here) that inevitably add up to more than 100%, how exactly (in terms of technical details) does Amarok attempt to resolve this? Does it take some of the biases in sets and takes turns spending some time on each set? How much time? How does it choose these sets? My goal in this specific endeavor is to predictably be able to mix together a dynamic playlist of artists and genres that is somewhat consistent in its behavior.

Since I first began using the Amarok 2 series, I've had numerous such questions about the playlist, thus my question about a page or wiki that documents the very technical aspects of how these playlists really work.

It would be much more intuitive to center the playlist around the manipulation of track attributes rather than dividing them up into two types of biases...but if this is what we're going to get, I'd love to know how to work with it better.

many thanks,

~mm

maniacmusician wrote:Is there any place where I can find detailed documentation about the new Dynamic Playlists in Amarok 2? I understand the basic idea of the proportional and fuzzy biases, but they're implemented a bit stiffly. That aside, this isn't a suggestions post, I just want to know more about the way they work.

A specific question I had was; If I add numerous Proportional Biases (40+ is what I'm going for here) that inevitably add up to more than 100%, how exactly (in terms of technical details) does Amarok attempt to resolve this? Does it take some of the biases in sets and takes turns spending some time on each set? How much time? How does it choose these sets? My goal in this specific endeavor is to predictably be able to mix together a dynamic playlist of artists and genres that is somewhat consistent in its behavior.

There has been some discussion on this in the past, no developers chimed in, but it seems pretty self evident from the observed behavior that thinking in terms of a pie where the biases are slices that have to total 100% is the wrong way to think about it and will just lead to confusion and frustration.

Instead think of a bias like a suggestion. Tracks that match X criteria will be XXX% more likely to be played, but that doesn't necessarily mean tracks that don't match the criteria will never be played. I would expect as the number of biases increases the predictability of what will or won't play goes down a bit. Not certain by any stretch of the imagination, but I think even if you have one or more biases set at 100%, as the number of biases grows so does the probability that stuff will be played that doesn't match the criteria of the bias that is set at 100%, in particular if not playing stuff that fell out side of the criteria for the bias set at 100% would mean not playing something that matched the criteria of a different bias for the dynamic playlist in question.

As far as I know, unless you are a programmer and can dig through the code and figure out what is going on, the best information you will find will probably be the blog posts of Daniel Jones:

http://amarok.kde.org/blog/authors/31-Daniel-Jones

Later, Seeker

Don't worry, even fellow Amarok developers who have never taken a look at the code don't know how it works. However, I have taken a look at the code (and wrote the Custom Bias stuff in 2.2) so here's how things work.

* There are 2 types of biases. Collection-filtering (custom biases such as last.fm, and *all* Proportional biases) and modifying (fuzzy biases).

Steps when you add some biases and press Repopulate:

1) Each collection-filtering (cf) bias has a weight, the value of the slider.
2) The list of cf biases are shuffled.
3) For each cf bias:
* Choose a random number < 100, if number < weight (weights are 0-100) that bias is selected
* If not, try the next bias
4) If a cf bias was chosen, take a track from that bias and add it to the playlist. If not, add a random track from the collection

This will generate an initial playlist of tracks.

5) If there are no modifying biases, this is it. playlist generated.
6) Else, minimize the "energy" of the playlist:
-> Run a simulated annealing algorithm (http://en.wikipedia.org/wiki/Simulated_annealing) to minimize the energy.
* One track at a time, mutate the playlist
* Each bias returns an energy for a given playlist, and so a playlist that "fits" the bias is given a lower energy than one that is way off.
* When a local minima is reached, that's the "optimized" playlist

and there you go.

it doesn't really work as the UI makes it seem like it should. we talked about this at length at GCDS (akademy) and we have come up with a much better framework. it's just beginning to be implemented (we're busy) but it's more flexible, more powerful, and much more awesome.

the plans are here: http://amarok.kde.org/wiki/Development/ ... _Playlists

lfranchi wrote:the plans are here: http://amarok.kde.org/wiki/Development/ ... _Playlists

Cool, thanks for that.

I know this has been a complaint....

What really needs to be overhauled, however, is the backend. Currently, as I have explained a few times to different people, each bias is completely independent---so it acts in ways that are completely unintuitive. If you have a 50% Jazz and 50% rock, you get some jazz, some rock, and some random tracks.

... and I would say rightfully so, but for those of us who actually like that behavior I hope there is either:

A: A toggle to limit the playlist to tracks that match a bias.

or probably better:

B: Have a bias option to select the amount of random tracks that should be included.

Later, Seeker

lfranchi wrote:Don't worry, even fellow Amarok developers who have never taken a look at the code don't know how it works. However, I have taken a look at the code (and wrote the Custom Bias stuff in 2.2) so here's how things work.

[....]

and there you go.

it doesn't really work as the UI makes it seem like it should. we talked about this at length at GCDS (akademy) and we have come up with a much better framework. it's just beginning to be implemented (we're busy) but it's more flexible, more powerful, and much more awesome.

the plans are here: <a class="linkification-ext" href="http://amarok.kde.org/wiki/Development/GCDS_Discussions/Dynamic_Playlists" title="Linkification: http://amarok.kde.org/wiki/Development/ ... _Playlists">http://amarok.kde.org/wiki/Development/GCDS_Discussions/Dynamic_Playlists</a>

thanks for this explanation, that helps clear up some things. Although I don't know how much time I want to spend fiddling with the current system now if a new one is in the works.

The way you guys are redoing the backend seems like it will be much more intuitive...the only thing I'm unsure about is keeping the old UI. I've been mulling over alternative UIs for a while in my head, trying to figure out one that has the user deal more directly with musical attributes of tracks...but I haven't really been able to come up with anything good that would fit in the size constraints imposed by having it in the side-panel.

The current method of overlaying a bunch of biases and watching the playlist change and respond is something that's really satisfying...where it tends to get cumbersome is the repetitive action of "Add bias > select field type > enter value to match field to > select weight value." This is fun and interesting for adding 2 or 3 biases, but after that it's almost torturous to have to go through those same series of clicks a dozen times. Although this is all irrelevant until I get to try the new system.

How high up on your priority list (as a team) is this new system? Since it affects user interaction so deeply, it seems like it would be fairly high up there. But then again, I don't know what other stuff you have on your plates.

Is there one or two people specifically working on this or does everyone just work on it a little when they have time? And is this something that's intended to be finished before 2.3? I'm not looking for a guarantee or anything, just plain curious.