I had this great idea tonight...

I was listening to Pink Floyd's "Terminal Frost", and after that (in my 80s collection) popped up Huey Lewis and the News' "The Power of Love". Now this struck me as a bit of a jolt in mood; but of course it's not easy to stick a simple label on a song. And the problem wasn't the songs in themselves, it was the transition between them.

So if there was some way to tell the empeg how I rated the transition from one song to another, it could use that as a factor in its randomisation process. Sometimes you might switch it off and enjoy the changes and bounces in moods, and sometimes you would want things to flow thematically so you'd switch it on again.

Sound interesting?

Save the whales. Feed the hungry. Free the mallocs.

Hmmm.. Some quick math says that this would be impossible and rather useless. Even if you have 100 songs, that's umm... a lot :) of transitions. I have 1500 right now and my Empeg is only half full. I can't imagine you'd have enough time to rate each transition. The best thing to do is put your Floyd in a Classic Rock collection where it belongs, they did release Momentary Lapse in 1987, but they're definitely not an "80's" band. :)

---
MkII 080000554

Well, from an artificial intelligence standpoint, it needn't take very much space at all. If empeg implemented this as a force feedback neural network for selecting transitions between songs on a list, where the feedback mechanism is the user ranking on a scale of 0 to 9 on the remote control -- and the variables are different database description items... then perhaps over time the empeg will learn the characteristics of song transitions for a particular user. That would be quite interesting really... And there are off the shelf freeware neural net libraries for doing this... probably..

Calvin

And there are off the shelf freeware neural net libraries for doing this... probably..

Dare you to find one that (a) will only run in a few megs of RAM, and (b) won't hog the CPU.

___________
Tony Fabris

Good luck with the neural net thing. What you really want is a system to allow you to object to a certain transition. If the empeg didn't hear anything from you, assume that the transition was fine. If you objected to it, never allow that transition again. If you have N songs, you have N*(N-1) possible transitions. You could also assume that if A->B is not allowed then B->A is also not allowed. Now you have N*(N-1)/2 transition pairs to remember. Each transition pair is only one bit of information (allow it / don't allow it). It would take an 8193 song collection for the transition info to exceed the size of a typical song, 4MB. To put it another way, you would need a collection greater than 671090 songs for the database to occupy more than 1% of your disk. Sounds like a winner to me. Who will do the source mods? I'll give it a go once I get some other things working first (just got the unit a couple of weeks ago).

Sounds to me like some people want custom playmodes.

I've thought about this a lot. Currently we have two playmodes:
- Sequential
- Shuffle with dedupe

To that, we could add
- Random (different from shuffle in that you could (in theory) get the same track ten times in a row)
- Shuffle with no dedupe
- Random with allowed transitions only
- Next track is somehow based on tags (e.g. must have year, source, or artist in common with the current track)
- Cycling through users (e.g one track I like, then one track that you like)

Of course, if you allowed custom playmodes, there'd always be the possibility that a poorly (?) written playmode would never choose to play some tracks. That's just tough. :)

Cool, yes. Important, nah.

To do this completely you'd want APIs that let you access the database in all sorts of nice ways, plus the ability to possibly write arbitrary data somewhere (if there was an API for this, then you don't have to worry about a custom playmode wanting to spin up the hard disk without the player knowing about it).

I'd really like this, but I don't expect it to happen real soon.

Richard.

How about transitions from one Genre to another. As long as you've got the genre tags correctly set, this should significantly reduce the number of combinations.

(I've currently got only 8 different genres in my unit).

Comments?

Paul.

Paul Haigh, Reg. 4120
(mk1) 6GB, Blue, 00254
(mk2) 12GB, Red, 00357

Why bother? Just store the data, and then when you do a sync, have a way to do the processing in emplode. A switchable feature, of course.

Fly me to the moon...

Just because a->b isn't allowed doesn't mean b->a wouldn't be allowed. If the songs were completely different styles, then yes, but that wouldn't always be the case.

Fly me to the moon...

Sounds to me like some people want custom playmodes.

I've thought about this a lot. Currently we have two playmodes:
- Sequential
- Shuffle with dedupe

To that, we could add
- Random (different from shuffle in that you could (in theory) get the same track ten times in a row)
- Shuffle with no dedupe
- Random with allowed transitions only
- Next track is somehow based on tags (e.g. must have year, source, or artist in common with the current track)
- Cycling through users (e.g one track I like, then one track that you like)

Actually, one simple one that I would like is to be able to shuffle albums. In other words, choose a 'depth' in your playlist tree, and the player will randomly choose nodes that deep and play all the songs in that playlist (sequentially).


Michael Grant
12GB Green
080000266

All you really have to do is store the exceptions - you're not going to rate transitions that you're satisfied with.

Let's imagine that you can rate a transition as either very good, good, bad or very bad. Since all FIDs have their lower bit cleared (i.e. they're even), all you have to store for each transition is two sixteen-bit numbers - four bytes for every transition stored. The low order bit of each number encodes the transition rating, and is XORed out to give the FID. When you read the table in you store it as a hash of hashes keyed on the 'outgoing' song.

Simple, really...

Save the whales. Feed the hungry. Free the mallocs.

http://www.geocities.com/CapeCanaveral/1624/bam.html

How about this? This code learns the relationships between "item a" and "item b" ... and then later on, when presented with a item c that is similar to item a, it can associate it to item b. Can it be the case such that as the user indicates preferences on transitions, the neural net will learn... but when the playlist mechanism picks the next song, it will query the neural net, and the neural net will return some percentage "ok'ness" and if it is less than 50% ok, the playlist will skip and try another song until a match occurs.

OR as some user suggested, have the neural net learn "not-ok-ness" and the playlist mechanism will learn inappropriate transitions, and perhaps after learning that it's not good to put a new age song between two heavy metal songs, it will acknowledge that relationship and suggest not putting any new agey stuff between metal stuff.

(neural nets don't take up a lot of space ;)

Calvin

Calvin

Actually, one simple one that I would like is to be able to shuffle albums. In other words, choose a 'depth' in your playlist tree, and the player will randomly choose nodes that deep and play all the songs in that playlist (sequentially).

I think you might be able to do this right now.

Once upon a time, I was experimenting with shuffle modes. This was in the days before they gave us an immediate shuffle, before they reworked the shuffle code. But it might still work now. I complained about it at the time, but it does make sense as a feature.

Suppose you have a playlist called "Albums". And each album is a playlist beneath that list.

If you go into emplode and tag the "Albums" playlist with the "Always Randomize Contents" flag, but leave the albums themselves as sequential, then you deactivate shuffleplay and start the "Albums" playlist, it will shuffle the albums while leaving the songs within those albums sequential.

(Note, it doesn't have to be an "Albums" playlist. It could be the root top-level playlist if you wanted it to be.)

___________
Tony Fabris

In response to:
----
- Let's imagine that you can rate a transition as either
- very good, good, bad or very bad. Since all FIDs have
- their lower bit cleared (i.e. they're even), all you
- have to store for each transition is two sixteen-bit
- numbers - four bytes for every transition stored. The
- low order bit of each number encodes the transition
- rating, and is XORed out to give the FID. When you read
- the table in you store it as a hash of hashes keyed on
- the 'outgoing' song.
----

Are you confusing bits and bytes here? It takes 2 bits, not 4 bytes to represent 4 possible ratings (I still say you only need two ratings: good or bad). All fids for 'emplode elements', for lack of a better term, have not only there lower bit, but there entire lower byte cleared. Fids for 'properties of an emplode element' (ID3-ish info) do not have their lower byte cleared. At least that has been my experience from playing around in the fids directory. It looks like the empeg people have reserved 15 possible 'property' filenames for each 'element' filename. Does this mean a tune can only be referenced in a maximum of 15 playlists?

No, a tune does now "know" if it's included in a playlist - the fact it's in a playlist is not a property of the tune, but a property of the owning playlist.

There's no restriction on how many playlists a tune (or another playlist) appears in.

Hugo

OK, so I couldn't remember the rules of FID creation... :-) The point remains the same - you don't need much space to encode the information you want to store. I don't think, in retrospect, that you'd need more than those 5 (four explicit, one implicit) levels of preference stored. But perhaps other things could be stored in the remaining unused bits - how much you liked the song, for instance.

As empeg seem to have the concept of marking a song for later attention somewhere in their wish list, I won't say it again...

Save the whales. Feed the hungry. Free the mallocs.

I carry a mini tape recorder in my car to make note of MP3 anomolies (pops, low quality, incorrect tag info, whatever) for later attention, but I would love to be able to mark the song through the empeg.