New custom shuffle variables.

I've been playing around with custom shuffle modes, and recently found that you can use many variables other than time, year, plays, random, and ctime. I haven't been able to find any mention of this here or on riocar.org. So I asume this is something new to 2.0 final?

Does anyone have a full list of all custom shuffle variables and their possible min/max values?

While we're at it, I think the constants used in the built-in shuffles changed when the variable ranges changed in one of the betas. Can one of the developers check whether the values in the Developer Info on RioCar.Org need changing? Thanks.

As long as any change is just increasing the possible max values, the default shuffles should be ok. Well, except if the range of RANDOM was changed, but that doesn't seem to be the case. It still seems to resolve to between 0 and 32000 or so. Can anyone clarify, is RANDOM 0 to 32000 or is it 0 to 32767 ?

Anyway... Here are the other variables I've been able to find. Some work fine in upper case, some don't. So lowercase used for consistency. Variables with no values, or values beginning with 0, are treated as 0 and can cause weird behavior.

Usage: (-)variable=#
Where # is a positive integer.

length
Track size in bytes.

duration
Track duration in milliseconds.

offset
Offset of first valid MP3 frame, i.e., number of bytes before first valid frame. wave=0, wma=?

samplerate
Track's samplerate in Hz. wave=0, wma=?
Possible values for MP3s: 48000, 44100, and 32000 if stereo. 24000, 22050, and 16000 if mono. The vast majority of MP3s are going to be 44100.

tracknr
Value of "Track #" field.
Track numbers beginning with 0 cause weirdness.

file_id
Value of "Track #" field.
Track numbers beginning with 0 cause weirdness.

pin
Pin number assigned to track.

play_count
Number of times played. Similar to PLAYS, but the value of play_count is the actual play count, where the value of PLAYS appears to be (play count)*(-1). So "shuffle0=Least played,-play_count=1" is the same as "shuffle0=Least played,PLAYS=1"

play_last
Number of seconds between 00:00:00 UTC 1/1/1970 and time last played. Similar to TIME, though TIME = (current time)-(played last)
Functionally "shuffle0=Least recently played,-play_last=1" and "shuffle0=Least recently played,TIME=1" are equivalent, even though the values are not the same.

fid=1
Track's FID number.

bpm=1
Track's beats per minute as calculated by player.

Are there any others? Is there one that evaluates to current time?

The only other potentially useful one I see is bitrate. Haven't checked to see if it works yet, though.

Bitrate won't work as the strings ("vs204" or whatever) will all come out zero -- the code only looks for digits at the beginning of the string.

There's no support for it in emplode, but you can write any tags you like to the *1 files and they'll be added to the database and available for use in these shuffles. (To avoid colliding with future Empeg-defined ones, start your tags with "x-", as if they were mail headers.) For instance, you could add "x-jolly" tags, rate cheerful songs as 10 and Smiths songs as 0, and shuffle by jolliness.

Peter

BPM might be neat. "Give me all my fast songs first." Especially if a little "fuzz" or randomness could be added in so it's not always the fastest song that plays first.

How about a mode that says to order tracks such that the BPM of a track must be within +/- N BPM of the preceding track?

Now we're talkin.

What would be cool... write some BPM analysing code that takes the pre-calculated BPM value and then scans the tune to find the offsets to each beat in realtime. Then cues up the next song so that the beats are in-time, then cross-fades.

Not sure if the player software can speed up and slow down the playback of tunes by just a little. If not, the tolerance (that is, the value of +/- N) will have to be very small.

This should sort of work like that. (Higher BPMs first)
shuffle0=BPM +/- N,bpm=32768,random=N

I think. I haven't tested it.

This idea has much potential for grooviness

You can add marked as a variable as well.

shuffle0=Marked,marked=32768,random=1

I use this to put all my marked songs at the beginning but shuffled. I use it as a favourites list. i.e. I hear a song I like, I mark it....


I assume marked is just a 0 or 1 depending on whether it's marked or not.

Whoops, missed that one. I was going by jEmplode and figured it was a text field rather than numerical.

It would be nice if you could set the marked value when marking a track. Have, say 1 = fave track, 99 = I hate this track, 1000 = This track has technical problems, etc.

I wonder if something like this could be added via 3rd party software. Maybe by intercepting the "Mark" button press and displaying a menu with values to choose from. Assuming the marked field is bigger than 1 bit.

Assuming the marked field is bigger than 1 bit

IIRC, it's not.

Oh well.

Anyway, while testing the new shuffle variables, I came up with a few custom shuffles that I find useful. I particularly like the last one.

Least often played (5)
shuffle0=LOP5,-play_count=32768,random=-5
Sorted by least often played, randomized in such a way that any track will be within a maximum of about +/-5 plays from previous one. It's a little more randomized than the default LOP shuffle which is about +/-1

Least recently played (24hrs)
shuffle0=LRP24h,-play_last=32768,random=-86400
Sorted by least recently played, randomized in such a way that any track will be within a maximum of +/-24hrs from previous one. This is less randomized than the default LRP shuffle which works out to about +/-12.1 days.
(edit: Changed 9.1 hours to 12.1 days. I forgot that the default shuffle uses TIME which is 32 seconds per tick.)


Least often by least recently played.
shuffle0=LOP by LRP,-play_count=4294967295,-play_last=1
Sorted by least often played. Tracks with the same play count will be ordered by least recently played.

Least often by least recently played (24hrs)
shuffle0=LOP by LRP24h,-play_count=1099533745246,-play_last=256,random=-675
Sorted least often played. Tracks with the same play count will be shuffled the same as "LRP24h,-play_last=32768,-random=86400"

Least recently played - playcount adjusted
shuffle0=LRP Play adjusted,-play_last=32768,-play_count=2831155200,random=-1
Sorted by least recently played, and each play count moves track's last play date forward 24 hours.
So, a track last played on April 10 with a play count of 6 will act like it was last played on April 16.
And a track last played on April 12 with a play count of 1 will act like it was last played on April 13, etc.
Tracks that have never been played are played first in random order.

Wow! Great hacking. I'll have to try those out.