Some mathematics, which may (or may not) make it clearer. All Fn are normalised to between zero and 32767.

So basically, half of my collection would always show as "never played/last played ages ago".

Is this actually a problem? Do you ever find yourself thinking, "Here, my empeg is playing Napoleon's Piano again, I only heard that two weeks ago"?

If Q103 -- or Radio 1 for that matter -- went twelve days without repeating a song I'd be ecstatic

Peter

Is this correct?

Yes.

Peter

So basically, half of my collection would always show as "never played/last played ages ago".

Is this actually a problem? Do you ever find yourself thinking, "Here, my empeg is playing Napoleon's Piano again, I only heard that two weeks ago"?

Though I only have _very_ few piano pieces on my empeg, let alone "Napoleon's Piano", and as odd as this might sound to you: Yes, that is a problem for me.

cu,
sven

I think I agree with Sven here, but for different reasons.

If the oldest possible date is twelve days ago, then okay, sure, maybe I don't care if I've heard a song in the last twelve days or not.

But here's the real problem in my opinion: At any given time, MOST of my collection will still be equally randomized when I'm using the time-based randomizer. In other words, the feature doesn't really work as intended if it's only got a 12-day memory.

This thread really does confuse me i'll come back when hey start talking english again

Well, I finally got around to trying to setup these custom shuffle modes on my unit and discovered some interesting things...

The examples given here in this message thread do not work correctly with 2.0-beta3. For example, the following entry...

[custom]
shuffle0=Most often played,-PLAYS=1

causes a bizzare shuffling of songs that doesn't make sense. Even worse, if you attempt to apply this shuffle to a huge playlist your player may hang with an hourglass on the screen forever (kind of reminds me of good old Windows 3.1!)

However, the following entry works exactly as expected...

[custom]
shuffle0=Most often played,PLAYS=-1

Perhaps this odd -PLAYS / -TIME syntax only applies to older alpha/beta versions, while the newer releases simply use negative numbers? Anyone from empeg care to comment?

Hi.

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.

cu,
sven

Hi Tony.

I'm just wondering if I'd waste my time by making a FAQ entry on it.

Did you add an entry for custom shuffle modes to the FAQ? I did add it to the developer info, but the way I wrote it, it is probably still incorrect. I couldn't find your FAQ entry for it, even if it existed.

cu,
sven

I didn't add a FAQ entry for it because I tried to make it work on my player the way I understood it to work, and it didn't behave as I expected it to.

I tried creating a shuffle mode based on the number of "plays". I did it without the random factor, so in theory I should have gotten a list of songs in order of "plays". But I didn't get that, I got something that seemed random-- the "plays" field seemed to go up and down randomly as I cycled through the songs.

So until I can get something that works, I won't write a FAQ entry on it.

Also...

The Empeg guys said that they intend to create a user interface for the feature in Emplode. So if they do that, there's no need for a FAQ entry.

When will skip-counts be implemented? I'd love a shuffle mode : "least skipped".


Geert

Empeg 6Gb Red

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

Hi Toby.

Nice suggestion. I like that one alot.

cu,
sven

There is a bug in the current software with regard to the most-recently-played values, and it will be corrected in the next release.... Dunno about PLAYS but I was never able to get this to work right...

Emplode getting the feature soon?

No. Unfortunately.

The bug with "most recent" is that if you're not in the GMT time zone (for instance, I'm off by eight hours), then the calculations get all messed up, and re-shuffling considers anything you've heard within the last 8 hours to be "ages ago".

The bug with "most recent" is that if you're not in the GMT time zone

Actually I think that bug was in beta 12 only. Beta 11 et pre have a much wider variety of much worse bugs with that feature.

Peter

Here's an old one, brought back, what's the be all end all on this, does it work ?

Has anyone implemented a good (worthwild) custom shuffle mode ?
Perhaps someone might post a few config.ini string with their associated "plain english" meanings.

GeorgeLSJr did a great job with these:

shuffle0=Favorites,PLAYS=-32000
...you'll get a shuffle of your playlist in sequence of number of plays, highest # of plays to lowest # of plays. Keep the player paused and keep reshuffling the playlist and you'll keep getting the exact same sequence of songs.

shuffle0=Favorites,PLAYS=-32000,RANDOM=1
...and you'll get the same as the above, but songs which have the same # of plays will be re-shuffled amongst themselves each time.

Anyone Else ?

More on This Old Thread:

In reply to:

---

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.

---

Blert: Insufficient generality, 10 yard penalty.

How about this:

TIME should be the log(base 2) of the actual time difference, with as many bits of precision as are possible at any given time (if you're messing with unix time_t's, the largest log base 2 will take 4 bits of integer, leaving the other 11 for the fractional part).

Note that this scales kind of self-correctingly: if you've played everything recently you get an extra couple bits in the fraction to differentiate them with. Also, this completely gets rid of the 'ages ago' category, though of course songs can still 'collide' by having the same 'TIME'

--pj

TIME should be the log(base 2) of the actual time difference, with as many bits of precision as are possible at any given time (if you're messing with unix time_t's, the largest log base 2 will take 4 bits of integer, leaving the other 11 for the fractional part).

<tommyboy> You can get a good look at a T-Bone by sticking your head up a Bull's arse, but most people just take the butcher's word for it. </tommyboy>

So I'll take your word for it...
I mean, it sounds good but I imagine I speak for may users on this board when I say:
"I have no idea what to do with such information."

Perhaps you may have added a few "Custom Shuffle Modes" to your empeg that us "simpletons" might find handy, convenient and usable.

Something like these:

shuffle0=Favorites,PLAYS=-32000
...you'll get a shuffle of your playlist in sequence of number of plays, highest # of plays to lowest # of plays. Keep the player paused and keep reshuffling the playlist and you'll keep getting the exact same sequence of songs.

shuffle0=Favorites,PLAYS=-32000,RANDOM=1
...and you'll get the same as the above, but songs which have the same # of plays will be re-shuffled amongst themselves each time.

take 4 bits of integer, leaving the other 11 for the fractional part

All that kind of stuff got way too complicated. In beta 13 it's done in 32-bit quantities (and 64-bit total), not 15 (and 32).

Peter

A-Ha !!
So now me goes to install beta 13,
is there some kind of interface for adding shufflemodes ?

So now me goes to install beta 13,

Custom shuffles still have some bugs in beta 13, FITNR. It's a lot better than beta 12 though.

is there some kind of interface for adding shufflemodes ?

No, you still have to illicitly furtle with config.ini as previously.

Peter

No, you still have to illicitly furtle with config.ini as previously.

Is the syntax for illicitly furtling config.ini still the same as above?
Are strings I mention above still applicable?

Custom shuffles still have some bugs in beta 13, FITNR.

Interesting. I was wondering about that. In b13, I'm still doing least-recently-played shuffles and it's sometimes playing stuff I just heard in the prior shuffle. Not as much as in beta 11, but sometimes. Would the FITNR stuff account for that?

In reply to:

---

So I'll take your word for it...
I mean, it sounds good but I imagine I speak for may users on this board when I say:
"I have no idea what to do with such information."

---

Well, the intent was to compress the time-since-last-played, which is a 32 bit quantity, down into 14 bits, 1) without sacrificing ordering (ie. small numbers should still be small, larger numbers should still be larger) and 2) without having too large of an 'ages ago' category (which was the problem with the previous method).

I guess the point is, it doesn't matter what the numbers really *are* as long as you know that things you haven't listened to in a long time have higher numbers than things you've listened to recently. That's all you care about anyway.

Of course, all this is moot if they've now moved to carrying the whole 32 bits around.

--pj

Of course, all this is moot if they've now moved to carrying the whole 32 bits around.

...of course.

I love all the new features in 2.0 beta. I have also noticed randomization problems. I don't know if its bugs or a feature oversight though. When I use SHUFFLE mode..things seem to do more or less what they are supposed to. However, I very infrequently use shuffle mode per say. What I wish is that the playlist randomization (without shuffle) was smarter like shuffle mode is supposed to be. For example...

I have all my stuff organized by artist/album as many others have also done. The idea is that folders are randomly selected but then the album folder playlist is set to "ordered" so that the album plays in correct order. The idea is that I can randomly hear complete albums. All that works fine. However...it repeatedly brings up the same albums at the front of the list and ignores many others. its generally easier if an album comes up I don't like to just start over with a new random playlist...but it seems that there is a small subset of albums that always seem to be at the top of the list.. Can the randomization algorithms that are used for playlist order (not the shuffle mode) be improved to use some of the new algorithms that are used in shuffle mode..such as least recently played, etc.. ???