Rockbox

Or you could just delete music by artists that you don’t like as much….

Wow, what a helpful suggestion…I never once thought about that.

I’m talking about situations where you might be in the car for hours on end. When you stop for a break you might get back in the vehicle and be in the mood for something a little different. “It sure would make finding a song you want to listen to in the car easier since you wouldn’t have to look at the screen.” With several gigs of storage on mp3 players these days it is unlikely you would be in the mood for every single song on your mp3 player. This way there is still some variety and the player would be more likely to play what you are in the mood for. Think of it as an on the fly playlist that adapts itself.

Sorry Bob–I wasn’t trying to be antagonistic; I just didn’t see the use of what you were proposing. Would you envision this playback probability info to be permanent (vs being cleared on system restart or something)? In any case.. though _I’M NOT A DEVELOPER_, I really don’t think it’s practically possible for Rockbox to implement this type of feature.

A genuinely smart song chooser is very difficult to create. If you skip a song, how can the device know the difference between the following reasons?

1. not in the mood for this song right now, but I usually like it
2. don’t like this song, ever, but I keep it because the rest of the album is good
3. this artist is only good on tuesdays
4. don’t play rap immediately after classical

A single button press just isn’t enough to tell the device that sort of detail.

I’m not saying it’s impossible, but you might have to provide a detailed explanation of how the idea can be implemented before it will be considered as a feature.

:P Sorry Ryan… I just like being a smartass on occasion. It would really only be useful if it cleared when you shut down the player. Otherwise it would mostly just play a couple artists.

To answer your question Scott “For instance if you were playing a song and skipped it before it had played for :30 seconds Rockbox would be less likely to play a song by that artist.” I think it would be easier to filter the songs by artist. I envision it as a temporary playlist that would clear on shutdown. I don’t expect such a playlist to read my mind… I only expect it to pick the artists I want to listen to at that point. Lets say you are listening to music with the random adaptive playlist on. If it is currently playing something by the Artic Monkeys and you finish more than a specified amount of the song it will be more likely to pick an Artic Monkeys song. Lets say it goes to Golfrapp next and I’m not in the mood for Goldfrapp so I skip it. It would then lower the chance of Goldfrapp being picked again. Basically it gives preference to certain artists according to how long you have listened to one of their songs.

It would probably be complicated to add… but I’m not a programmer so I don’t really know. I wonder if it would be possible to have user changeable options to select songs by artist or genre.

I just looked at  FS#5837 . I like the idea of automatic ratings for songs, it’s a twist I haven’t thought of but generally the same idea. I don’t know how I missed that one, maybe because it is older.  FS#5837  is also interesting. Maybe someone could make a hybrid of the three different versions of this same idea.

Since rockbox has no “intelligent” song selection features yet, I’ve been using a different approach. I use my desktop’s song rating data to generate playlists, and copy those playlists to the portable music player. I’ve got one list for every song with 51/100 or higher rating, another for 70/100 or higher, another for 80/100 or higher, … And when I rsync files to the portable, it uses a large auto-generated exclude list, to keep everything rated 35/100 or lower from getting copied at all.

This isn’t ideal, but it does at least keep rockbox from playing the worst songs, and encourage it to play the better ones more often. I suppose I could also generate a semi-weighted playlist by repeating the higher-ranked songs, but I haven’t bothered.

I don’t really care any more about using my portable to rate songs. I never use any UI functions beyond next/prev, volume, pause, and power – because it’s just too dangerous to navigate rockbox menus while driving. Any feature which requires a menu, or more than a quick glance at the screen, may as well not exist. (it’d be nice if I could map the record button to toggle repeat-one mode, but that seems to require source changes)

Sorry for the ranting. Maybe there’s a useful suggestion in there somewhere.

I think you are still missing the idea here. I don’t want to manually “rate” songs on my player. I want it to automatically rate them according to how long I play them. I don’t see this as being a permanent rating, just a temporary one. “I never use any UI functions beyond next/prev, volume, pause, and power – because it’s just too dangerous to navigate rockbox menus while driving.” Trust me I know. Which is why I want a function I can turn on before I get into the car. Past that point it would only require using the prev/next buttons. “Any feature which requires a menu, or more than a quick glance at the screen, may as well not exist.” The mp3 players rockbox supports are great pieces of equipment… why use them like an ipod shuffle when they can do so much more? Although rating every single song in my 40 gig database before making a playlist sounds like a pleasure, I really want something a bit less time consuming.

Heh, I get the idea.. I was ranting mostly off-topic.

As a means of implementing the temporary auto-rating, it might be nice to have scripts attached to event hooks. I know this would be a huge change, so it’s unlikely to happen, but what if you could do something like…

# handle manual "next" events
auto-rate on next-song-button   # (or perhaps auto-rate before next-song, to call it before the song change)

# handle automatic "song completed" events
bump-up on song-end

# handle power-on by restoring the playlist
restore-playlist on os-boot-complete

# save the playlist when manually changed
save-playlist on playlist-changed-manually

script auto-rate
  if [[ $current-playtime < 30 ]]; then
    # remove the current artist from the playlist
    album=`dirname $current-song`
    artist=`dirname $album`
    grep -v "$artist" /.rockbox/playlist > /.rockbox/playlist.tmp
    mv /.rockbox/playlist.tmp /.rockbox/playlist
  fi
endscript

script bump-up
  # do some magic to enhance the temp rating of songs by the current artist
  ...
endscript

script restore-playlist
  cp /.rockbox/playlist.bak /.rockbox/playlist
endscript

script save-playlist
  cp /.rockbox/playlist /.rockbox/playlist.bak
endscript

Hopefully flyspray won’t mess up formatting and such… I see no ‘preview’ function.

This may be overly simplistic, and not at all easy to implement, but it would provide a way for users to greatly customize behavior. Any modifications that become popular could be added to the rockbox core, and other misc changes could be shared as extras. For more ideas on possible syntax and implementation of this sort of event system, look at “upstart”, the replacement for “init”.

Haha I’ll take your word for it Scott. You obviously know a lot more about the technical side than I do. When I say a lot… I mean A LOT. It really would be awesome if something along these lines got implemented. Why didn’t anyone every take you up on the offer of helping to implement something like this?

I think it’s a simple matter of benefit per amount of effort. What I described above would be, on an embedded system like rockbox, a huge effort – and the benefit over the current system is relatively small. It’s a flexible and powerful concept, but would only solve corner cases. The main rockbox code already handles most of the common cases.

It would be far less effort to hardcode the specific feature(s) as regular options, but it still probably won’t happen. It’s unlikely that many people would use it. And, perhaps more importantly, this bug has (and similar bugs have) gotten almost no attention from rockbox developers. I think it’s a category of problem the core team just doesn’t care about.