The current 2.0 beta has added several new shuffle modes including:

- Least recently played
- Least often played

I would like to see added:

- Most recently played
- Most often played

These would offer a way of hearing your current favorite tracks without having to constantly build new playlists reflecting what's hot in your world of music.

In an earlier alpha, it was possible to add your own custom shuffle modes to config.ini. The ones you listed would have been pretty easily possible, as I recall.

I assume this functionality is still there, I just don't remember how to do it. Darn, I wish I would have saved that message.

Perhaps someone from the development team can give us a clue here? I'll document it in the FAQ if you do.

Perhaps someone from the development team can give us a clue here? I'll document it in the FAQ if you do.

Boy, am I good, or what?!

(from an e-mail exchange dated april 6, 2001)


From: "Peter Hartley"

Douglas Burnside wrote:
> And on a peripherally related topic... how about adding one more
> shuffle mode, "Most Often Played". This would be an easy way to
> dynamically generate a "favorites" playlist on the fly.

The 1.1 player software allows for user-defined shuffles. The UI for
creating them probably won't get added to Emplode in time for 1.1final, but
if you don't mind grubbing about on the player, you can add a section to the
config.ini file as follows:

[custom]
shuffle0=Favourites,-PLAYS=32000,RANDOM=1

Make sure you spell "Favourites" in UK English ;-)

This sets up a shuffle where the number of plays largely defines the order
(the minus sign means large numbers come first), but there's also a random
element so that if there are five tracks you've all heard, say, 20 times
each, those five get shuffled each time.

You can use any number of tags (Emplode column headings) in the shuffle --
as long as each one has numeric values, of course. You can also use the tags
"PLAYS", and (on Mk2) "TIME", which is a measure from 0-32000 of how long
it's been since you last heard it. The built-in shuffles are defined as:

Random,RANDOM=1
Least often played,PLAYS=1,RANDOM=2
Least recently played,TIME=32000,RANDOM=2000
By year,-YEAR=32768,RANDOM=1



Is this what you were looking for, Tony?

tanstaafl.

Yes, that's it, Doug.

Can you do me a favor and e-mail that to me as well? I'm away from home at a Con and don't have time to dump that into the FAQ right now. If it's in my email box when I get home, I'll remember to do it.

Also... Has anyone had a chance to actually TRY this in 2.0? Does it work? Note that these notes were from one of the 1.1 alphas...

Has anyone had a chance to actually TRY this in 2.0? Does it work?

It should work, as it's still (more or less) how the built-in parametric shuffles work.

Peter

It certainly appears on the menu, but I am listening in random shuffle mode too much (i.e. more or less all tunes have been played 2-3 times since 2.0b3) to say with certainty whether it really works.

Peter, what is the meaning of numeric parameter to RANDOM and PLAYS? I didn't quite understand from that mail Doug quoted. Are the mode label (shuffle0) and menu name (Favourites) arbitrary? How does one specify other tags, if at all (like in searches?) (for example, 'play randomly, but prefer tunes Wendy-tagged as not being suitable for mother-in-law's ears)? I guess one cannot combine parameters (e.g. maximize(plays-2*skips))...

Peter, what is the meaning of numeric parameter to RANDOM and PLAYS? I didn't quite understand from that mail Doug quoted.

They are the weightings given to each factor in determining the track's "soonness factor".

Suppose the shuffle we're doing is "PLAYS=32000,RANDOM=1". Then, for each track, the number of plays is multiplied by 32000 and added to a random number (1-32000) is multiplied by 1. The resulting number is the "soonness factor" for that track. Tracks with lower soonnesses play sooner.

Are the mode label (shuffle0) and menu name (Favourites) arbitrary?

The labels (shuffle0, shuffle1) are not arbitrary and must be consecutive and starting at 0. The menu name ("Favourites") is arbitrary.

How does one specify other tags, if at all (like in searches?) (for example, 'play randomly, but prefer tunes Wendy-tagged as not being suitable for mother-in-law's ears)?

You can use TIME, PLAYS and RANDOM as described in the Big Yellow Email, plus any numeric database tag -- of which there aren't many; YEAR is about the only useful one. (A future release might add MTIME, so you could shuffle favouring tracks recently added to your player.)

(A far-future release might include the original intention of being able to add custom numeric tags in emplode/emptool. So you could assign a numeric "cheese factor" to Britney Spears, Steps etc. and then shuffle favouring cheesiness -- or suitability for fast driving, or for dancing on the back seats, or whatever.)

I guess one cannot combine parameters (e.g. maximize(plays-2*skips))...

No, that's exactly what one can do. One is only prevented from specifying that particular shuffle, by the fact that keeping count of skips isn't yet implemented.

Peter

The current release already has "mtime" and "ctime", so as long as you put the tracks on with emplode v2.0, you can already do this -- they're numeric tags (Unix time_t).

Okay, I'm dense. I admit it. I still don't understand how it works.

I don't understand why some of the examples shown her have a minus sign in front of the field name.

I also don't understand why RANDOM looks like a field name.

And why one of the examples have RANDOM only and others have other fields. Why do some require more parameters than others?

Can you really do math expressions on the line as was suggested?

Why 32000 and 2000? Isn't that the same as 32 and 2?

And this statement...

Then, for each track, the number of plays is multiplied by 32000 and added to a random number (1-32000) is multiplied by 1.

... confuses me becuase the word "is" gets used twice in the same breath. Is the number multiplied or added?

I would really like to understand it before I try to write a FAQ on it.

I'm not sure which is more amusing -- the fact that a guy on the alpha team just found out about a new feature and can't figure it out, or the fact that one Empeg guy just informed another Empeg guy that a feature is already in the current release.

The only thing that could be more amusing would be having this kind of access to, say, Microsoft's engineers.

Hiya. Here's my understanding. Please tell us if this is wrong, empeg guys.

Each track gets a number (the soonness factor). This number is the sum of all the fields specified in the config file. The value of the field in the database is multiplied by the factor specified in the config file for that field. If there is a minus sign preceding the field name in the config file, then the value for this field is multiplied by -1. RANDOM is not actually a database field, but it acts like one, with a random value between 1 and 32000 that will change every time.

Tracks with smaller soonness factors are played first.

I think you're right that if the list of numbers on any one line has any common factors, then that adds no extra information.
i.e. TIME=32000,RANDOM=2000 is the same as TIME=16,RANDOM=1

Lets assume we have three tracks, A:plays=5,time=30 B:plays=10,time=40 C:plays=20,time=20

So:

-PLAYS=1 gives soonness factors of A:-5, B:-10, C:-20 so the order of the tracks will always be C,B,A

TIME=1 gives soonness factors of A:30,B:40,C:20 so the order of the tracks will always be C,A,B

PLAYS=4,-TIME=2 gives soonness factors of A:20-60=-40, B:40-80=-40, C:80-40=40 so the order of the tracks will be either B,A,C or A,B,C.

-PLAYS=32000,RANDOM=20 gives soonness factors of A:-160000+R1, B:-320000+R2, C:-640000+R3 where Rx are random numbers between 20 and 640000. So, if you want roughly even weighting between number of plays and randomness, you should give each a multiplier related to the expected value of the other number. But, as said above, this is the same as -PLAYS=1600,RANDOM=1

Have I got it right? Or have I just confused the issue more?

Richard.

Excellent! Thanks.

No chance of treating Wendy flags as numeric values (0/1)?

I don't understand why some of the examples shown her have a minus sign in front of the field name.

Because in a shuffle-by-year you want LOW numbers (years) first; in a shuffle-by-most-often-played you want HIGH numbers (play counts) first.

I also don't understand why RANDOM looks like a field name.

Because it acts just like a field name -- one with a different random value each time it's evaluated.

And why one of the examples have RANDOM only and others have other fields. Why do some require more parameters than others?

The one with RANDOM only, will shuffle the songs in completely random order. The ones with other parameters, take those factors into account too when shuffling the songs.

Can you really do math expressions on the line as was suggested?

No. But Bonzi's suggested math expression, maximize(plays-2*skips)), is the same as a shuffle "PLAYS=1,-SKIPS=2".

Why 32000 and 2000? Isn't that the same as 32 and 2?

Yes, it is.

And this statement...

Then, for each track, the number of plays is multiplied by 32000 and added to a random number (1-32000) is multiplied by 1.

... confuses me becuase the word "is" gets used twice in the same breath.

Sorry, the second "is" shouldn't be there.

Is the number multiplied or added?

Looking at it now, it would have been clearer to use "*" instead of "=", and "+" instead of comma. So instead of

-YEAR=32768,RANDOM=1

please read it as

-YEAR*32768 + RANDOM*1

Hope this clears things up a bit...

Peter

Have I got it right?

Yes, bang on.

Peter

I have a little problem with this mail:

"TIME", which is a measure from 0-32000 of how long
it's been since you last heard it.
And the definition of the least recently played random mode:
Least recently played,TIME=32000,RANDOM=2000
Which I will simplify to:

Least recently played,TIME=16,RANDOM=1

If the statement about the content is understood correctly by me, TIME is higher the longer a song is unplayed. But if this is correct, the "Least recently played" random mode would actually be a "most recently played" one.
So, am I correct with my assumption that the TIME measurement is actually more like a Unix time of the last playing date of a song, scaled down to the 0-32000 range, and therefore higher for more recently played songs, and lower for songs that were not played for a longer time?
If so, yould you give an estimation for the actual rang of TIME one should expect? If a song was not played for a week, what will TIME be approximately?

cu,
sven

I don't understand why some of the examples shown her have a minus sign in front of the field name.

Because in a shuffle-by-year you want LOW numbers (years) first; in a shuffle-by-most-often-played you want HIGH numbers (play counts) first.

Why don't you simply allow negative factors? This would result in:

shuffle0=Most recently played,TIME=-16,RANDOM=1

or similar lines instead of the (at least for me) less readable

shuffle0=Most recently played,-TIME=16,RANDOM=1

cu,
sven

If the statement about the content is understood correctly by me, TIME is higher the longer a song is unplayed. But if this is correct, the "Least recently played" random mode would actually be a "most recently played" one.

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".)

As TIME is higher for a long-unplayed song, that song's "soonness factor" is higher, so it gets played sooner. It is the right way round.

The "soonness factor" sort is a descending sort. That's why you have to use -YEAR to get a shuffle in ascending order of year.

Peter

No chance of treating Wendy flags as numeric values (0/1)?

I wouldn't say "no" chance, but it doesn't work like that at the moment. All wendy flags are combined into a single 32-bit flagword, so, unless you only have one flag, there's no point trying to do a custom shuffle on it.

Peter

Why don't you simply allow negative factors?

Bear in mind that this stuff in config.ini was never expected to be user-visible. We were intending to put a nice, simple, sensible UI in emplode.

Peter

Thanks, everyone, for the replies.

I've printed out this entire thread and I'm going to read through it carefully a few times and see if I can figure out how it works.

I think it's been adequately explained, now I just need to make it sink into my crack-addled skull. The only other thing I could possibly wish for is a set of examples showing how to do some interesting shuffle mode...

Just so you know, we do still intend to implement the nice front end in emplode..

Rob

Just so you know, we do still intend to implement the nice front end in emplode.

Oh.

How soon? Will it be in Peter's Copious Spare Time, or sometime before 2.0 final?

I'm just wondering if I'd waste my time by making a FAQ entry on it. One of the things I try to avoid is making FAQ entries that will become obsolete with the next software release.

I'd hold off for the moment Tony. I think there would be far too much confusion even for a FAQ. I had to stop several times while reading this thread and make another cup of brownian stimulants to cope. In the end my brain filled up.

Heh. Actually, I figured it out, and even figured out a way to explain it clearly in the FAQ.

The only problem is that when I actually TRY it on my player it doesn't produce the desired results.

For instance, I know that there are a handful of tracks on my player that have a "plays" count of 20 or so. Everything else is in the 0-5 plays neighborhood. But when I create a "favorites" shuffle as the example, those tracks are not at the top of the shuffle when I hit it. They're not at the bottom of the shuffle when I wrap around backwards, either.

This counts even if I remove the "random" item from the list. In that case, I would assume I'd get a straight count-up or count-down by Plays. I don't. In fact, the resulting song list doesn't seem to be related to the plays count at all.

Hmm.

I think for some, a simple "1" if any Wendy tag is set, "0" otherwise flag would be of a lot of help. Sure, that might filter too many songs out (resp. to the end/start of the playlist), but still, that would be better than nothing.

cu,
sven

Why don't you simply allow negative factors?

Bear in mind that this stuff in config.ini was never expected to be user-visible. We were intending to put a nice, simple, sensible UI in emplode.

Sure, but wouldn't it be easier to write from emplode, too? I mean a

printf(",%s=%d",tag,value);

is easier than the way you would be writing it now, right?
Also, it would be easier to read for you, too, when debugging.

cu,
sven

That's not what Wendy filters are designed for. What you want is custom tags (e.g. "cheesiness").

Hi Tony.

I'm still trying to figure this stuff out because I also want to document it on riocar.org (speak of redundancy).
Ok, let's leave the definition of the various counts aside, I still have problems with the basics. Is the following definition for the line format correct (Peter)?

shuffle#=< menutag >,{-}< tag >=< factor >{,{-}< tag >=< factor >{,...}}

Where the different shuffle modes are number in an ascending order, starting at 0 ("#"). The menutag is a simple string, the possible tags are defined seperately, the minus sign before the tag denotes that the associated tag's value
(multiplied by its associated factor) is substracted from the sum instead of being added.
The list of tags is seen as the definition of a sum, first multiplying each tag's value by its associated factor, then by "-1", if a minus sign was seen before the tags name, finally all those products are summed up. The sum (soonness factor) is then used as the key in the following sort (inappropriately named "shuffle" ). The sort is descending, so the larger the soonness factor, the earlier a song is played.
Is this correct?

cu,
sven

Hi Peter.

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".)

Well, not trying to criticize your decision on choosing 1/32rd of the seconds elapsed since the last play, but IMO, this divisor is choosen tooooooo low. Even if I let my empeg play 24h/day, it would need 2-3 weeks to play my complete collection (due to the large number of low-bitrate audiobooks). So basically, half of my collection would always show as "never played/last played ages ago". Couldn't you either
a) make the divisor user selectable, or
b) increase it to at least 128 (which is about half of a song)
PLEASE.

cu,
sven