Reviving an old thread here, because an idea popped into my head at the weekend.

In reply to:

---

Bringing up an old thread here again, but anyway:

Regarding "custom" shuffle modes in 2.0b3, we were discussing the factor by which the time since the last play of a song is devided by, just before feeding the value to the shuffle calculation.

Peter wrote:
TIME is higher the longer a song is unplayed. It's 1/32 of the elapsed seconds since last play: 0 immediately a song is played; 18900 after a week; and 32767 after about twelve days, at which point it's clipped. (So anything you haven't heard for twelve days counts as "ages ago".)

Tony Fabris and myself agreed that the factor of 1/32 is a bit too low, because typically the biggest part of any empeg owner's collection will be at 32767 after the conversion above, which obsoletes the "least recently played" mode somehow.

Was this changed since beta3? Nothing regarding this problem is mentioned in the beta7 release notes.

---

A suggestion: implement a non-linear curve by scaling values from a certain point.

Replace the "divide by 32 seconds to get a number" by the following procedure, then continue with the calculation as before:

• Keep the initial divison by 32 seconds.
• Values up to 16383 remain the same as they are now.
• Values from 16384 to 4210687 are divided by 256 and added to 16320.
• Values over 4210687 are forced to 32767 (so the values are limited, as before).
  

This means that we squash 4210687 seconds (1559 days or so - more than 4 years) into our 15-bit value, as opposed to the current 12 days, by using less precision (two hours instead of half a minute) for things played more than 6 days ago.

By fiddling with the constants above, you can get different ranges; it's also possible to break up the domain into more than two ranges (to get less discontinuity between recent and less-recent).