Re: [Musicpd-dev-team] mpd features - 'play library' and 'play queue'
I'm totally with Max on this one - the general form of the feature sounds excellent. The one thing I only just thought of is that a subsequent request we may get is the ability to mess with the upcoming random queue (not playlist). This can sort of be done by shuffling the playlist instead of using random mode, but besides the obvious differences between shuffled and random, that means that if you add songs to the playlist, they'll always go to the end, instead of being a possible random selection sooner - and reshuffling will destroy whatever you've set up in the queue. I'm largely thinking of this because of a feature I remember from iTunes. I expect that there are a decent number of people out there who like me haven't used Linux their whole life (or are using mpd on OSX) and have used iTunes before. iTunes had a party shuffle feature that would show you the next n songs it's planning to play (and m previous - a sort of delayed consume). You could then add to, remove from, or rearrange that list. Basically you had access to the random queue. I'm not trying to make a feature request here, just pointing out something to keep in mind whenever this feature is implemented. I know there would be a lot of difficulties in giving clients access to the queue of a playlist. Jeffrey On Tue, May 26, 2009 at 6:33 AM, Max Kellermann m...@duempel.org wrote: On 2009/05/26 13:21, Matt Wheeler m...@funkyhat.org wrote: I'm not sure I understand, a queue has a lot of similarities to a playlist, so surely re-using playlist code would result in less duplication of code than a separate solution (although that may mean the current playlist code would need generalising a little). A while ago, a queue patch was merged into subversion, but was removed when the former MPD lead developer found the code too ugly. It sure was awful, and I'm grateful it was already gone when I took over. Now if we generalize the playlist code, we can expose that generic solution to the clients, instead of providing one single very special feature like the queue. The idea of queueing/nesting playlists is interesting, I hadn't thought of that, but restricting a queue to this format means the use case of playing library on shuffle, but now I want to add a song to a queue to be played next is not satisfied (unless I'm missing something), without remove all other songs from current sub-playlist, add song I want to next sub-playlist, add library again to sub-playlist after next which just feels awkward. Create sub-playlist with queued songs (consume mode enabled), insert it before the shuffled playlist, move current song before queued songs. Agree, this is a complex operation, but it's only as complex as the user's wish. That is what I meant, if the queue is implemented just as a special playlist, then old unmaintained clients will continue to work, and support the queue, the client doesn't need to know it is special (nested playlists may break old clients as well, but users aren't forced to nest playlists anyway). With nested/chained playlists, you could serve only the current/first sub-playlist to clients calling old-style playlist manipulation commands. Only clients which speak new-style commands would see the big picture. Max -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] mpd features - 'play library' and 'play queue'
On 2009/05/26 13:21, Matt Wheeler m...@funkyhat.org wrote: I'm not sure I understand, a queue has a lot of similarities to a playlist, so surely re-using playlist code would result in less duplication of code than a separate solution (although that may mean the current playlist code would need generalising a little). A while ago, a queue patch was merged into subversion, but was removed when the former MPD lead developer found the code too ugly. It sure was awful, and I'm grateful it was already gone when I took over. Now if we generalize the playlist code, we can expose that generic solution to the clients, instead of providing one single very special feature like the queue. The idea of queueing/nesting playlists is interesting, I hadn't thought of that, but restricting a queue to this format means the use case of playing library on shuffle, but now I want to add a song to a queue to be played next is not satisfied (unless I'm missing something), without remove all other songs from current sub-playlist, add song I want to next sub-playlist, add library again to sub-playlist after next which just feels awkward. Create sub-playlist with queued songs (consume mode enabled), insert it before the shuffled playlist, move current song before queued songs. Agree, this is a complex operation, but it's only as complex as the user's wish. That is what I meant, if the queue is implemented just as a special playlist, then old unmaintained clients will continue to work, and support the queue, the client doesn't need to know it is special (nested playlists may break old clients as well, but users aren't forced to nest playlists anyway). With nested/chained playlists, you could serve only the current/first sub-playlist to clients calling old-style playlist manipulation commands. Only clients which speak new-style commands would see the big picture. Max -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] mpd features - 'play library' and 'play queue'
Hi guys, I've just started playing around with MPD and there are a couple of things I'm missing from using Banshee and Rhythmbox (although on the whole I'm finding the experience vastly superior :-)) Firstly is the ability to easily put my whole library on shuffle (although admittedly this is rather trivial to do). Secondly the ability to add tracks to a special queue playlist. This is how I see this playlist working: - User adds tracks to the playlist - MPD carries on playing the current track - At the end of the track, it starts playing the songs on the queue - After each song is played it is removed from the queue list - When the end of the queue is reached MPD resumes the playlist it was playing before (at the next track, if it was playing in order) Both of these features could work in such a way that current clients could use them without modification (although I don't know if that is of concern to you), but also clients could be extended to make them easier to use (I'm thinking of the queue list in particular). Are either of these ideas already being worked on? If they aren't being worked on at the moment I would like to have a go at implementing them myself, and would like some pointers as to the best way to go about it (such as a separate module, or as a feature of MPD itself). Let me know what you think, I look forward to hearing back from you. Thanks -- Matt Wheeler m...@funkyhat.org signature.asc Description: OpenPGP digital signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
