On Tue, 2005-04-26 at 18:32 +1000, Nicholas Gill (mythagel) wrote: > What i am considering is in particular the devices that are not like an > ipod. That is, flash based mp3 players without a db. This class of > players dump files in a folder which the device reads on startup. I had > originally thought of assigning an existing playlist to the device (the > user would select it when the device is attached) however i think it > would be clearer to have that association between the device plugged > into the computer and the playlist with its name. > > Actually, now i realise something else i wanted to discuss, how should i > handle files that are new on the device? I had considered creating a > folder like ~/Music and dumping the files there and then adding to the > playlist. I've just had an idea, one that would go a fair way to solving these design problems: multiple RhythmDBs. First off let me start by saying that I'm not sure whether RB's design has had there being only one DB as an assumption or not, so this might be A Lot of Work(tm). You would have the library/standard playlists working as normal, dealing with music that is on your computer (using the normal tree/gda DB). When you plug an mp3 player in it would show the expected new source, but instead of possibly adding the songs to the normal library (or not) it would use its own RhythmDB (a mp3player backend). If it was a player that supported playlists (e.g. an iPod) it could show the playlists backed by the player's RhythmDB. If you dragged songs between sources that use the same RhythmDB (e.g. the iPod playlists above) it would work like normal. If you dragged songs to a source that was using a different RhythmDB it would copy the song. For most things this would make sense (i.e. copy to the mp3 player), if you dragged one to the "on my computer" library it would have to ask you where to save it (or something). This design would be nice, in that it would then be easier to deal with things like audio CDs, music shares (e.g. DAAP) and the like as they could have their own db backend (presumably read-only). I'm not sure whether this would be a good idea, or if it is feasible, but to me it seems like an "elegant" solution to the problem. Cheers, James "Doc" Livingston -- I love ASR, you have total freedom of speech as long as it's punctuated correctly. -- Chris Hacking in a.s.r
Attachment:
signature.asc
Description: This is a digitally signed message part