OSNews

The player should expect that the user may change the song that just came up, in order to better suit his tastes. Say Z was played last, and B was chosen by the player (be it Mood mode or Shuffle mode) to play. B starts playing, and the user reacts this is not what I want to hear, let's play X instead. He changes to X, and lets X play to completion.

The player has to be smart enough to recognize this, perhaps by waiting until at least 25% of B has played before increasing the relationship strength between Z and B. It should then actually increase the relationship between Z and X (evidently, after 25% of X has played).

25% is off the top of my head. I don't know the magic number. Either trial and error or statistical methods can be used to determine this.

While a friend can grant you a favor, you can also request your friend to ask another friend of his to make you one. The probability that a friend of a friend would grant you a favor is, naturally, smaller than of your friend granting a favor directly to you, but it is not zero.

M is related to N is related to P. It follows that P should generally be a better a listening choice after M than a random song, although N is better.

If the list of candidates is short (say, below 3), it should be inspected one level deeper. Once a candidate has been chosen, the player should make a random choice between the candidate (with probability = 0.5) or any of its related songs (with sum of their probabilities = 0.5).

This will help you find relatively more likable alternatives to listen after each song.

Applying this principle one level deeper may be marginally more useful, but would be much more computationally intensive. Or it may not be useful at all.

Over time, the list of candidates for any song may grow very big. Constraining the list of candidates to, say, the top 5, will help by penalizing weak relationships.

New songs are at a disadvantage in Mood mode. Allowing the relationship network to adapt by weakening old relationships gradually would help new songs find their way into candidate lists, and would help the system in adapting to your changing tastes.

This weakening should be controlled, so new songs can have the opportunity to appear on candidate lists, but at the same time don't make old, repeated choices be “overwhelmed".

This system would only let you hear songs you've heard before. That's not the goal - the goal is to listen to new songs as well. The user should have a slider type control for how much “Shuffleness” he wants (between “Be totally random” to “Strictly follow my past choices").

Ideally, the default setting for this control would be to choose songs from the list of candidates with a probability of 0.8, and choose a random song with a probability of 0.2. A “Strictly follow my past choices” setting would be ideal for hands-off hosting of a party: two clicks on a dance music track, and the rest of the party would be dance type or compatible songs. “Be totally random” would allow you to be more explorative and create new relationships.

Numbers are off the top off my head, again.

Exploiting network theory in music players is just one of the interesting applications of mathematics in general. I'm sure someone else can point out examples of this being used in other fields. Let's put this to use now. We'll innovate.

candidates = topFive(currentSong.getRelationships())
candidate = randomWeightedChoice(candidates)

if candidates.length() < 3
    coinToss = randomChoiceHeadsOrTails()
        if coinToss = heads
            candidates = topFive(candidate.getRelationships())
            candidate = randomWeightedChoice(candidates)
        else if coinToss = tails
            pass

playCandidate = playCandidateOrRandomSong()
if playCandidate = true
    player.queue (candidate)
else
    player.queue (trulyRandomSong())