| |||||||||||||
Collections in the XMMS2 music playerCollections in the XMMS2 music playerPosted Jun 14, 2007 17:43 UTC (Thu) by thoffman (subscriber, #3063)In reply to: Collections in the XMMS2 music player by nix Parent article: Collections in the XMMS2 music player
Yes, I'd like to be able to teach my music player that Tracks 1-4 on a particular CD are "Symphony #41" and should always be played together, in sequence, and tracks 5-9 are "Symphony #42" with the same restriction, but track 10 is a single work and can be played without restriction.
Note also it isn't just classical music that has this restriction. I have a bunch of "non-stop dance mixes" of various techno and electronica which meant to be played all the way through the whole CD with no breaks between songs. Or, at least between most songs.
Although, long stretches from a single CD can kind of defeat the purpose of shuffle play... maybe an option like: When shuffle play is enabled, only shuffle in the middle of this sequence with a given probability. For instance, p=0.25 would on average break the sequences into four-track lengths.
Hmmm.... you know, that would be useful for non-sequenced music too. I sometimes find it disconcerting when shuffle play jumps between radically different styles of music. If I could adjust a probability (or some other tunable) so that once shuffle chose a track from a CD, there would be a strong probability that it would then play at least one or two more tracks from that CD before going on to a different CD, I'd probably use that.
The collections thing with binary operators sounds also really useful. It would even be better if there were relational operators which could work on ID3 tags. Then could tag all my tracks as "Live" or "Studio", and with a relational '<' ID3.YEAR operator, easily have a collection of "Pre-1990 Live U2" for instance.
Of course, with all these features there has to be a really, really convenient user interface, otherwise it's just too much trouble to bother with. On my IPod I usually end up shuffle-playing within a single genre just because it's easier than putting together a playlist.
I mainly want to listen to music, not futz around in a clunky UI for hours.
(Log in to post comments)
Collections in the XMMS2 music player Posted Jun 19, 2007 7:34 UTC (Tue) by scevey (guest, #45734) [Link] I can see different ways to solve your complex shuffling use case. It's quite similar to nix's requirements in the post above. Because we're trying to avoid adding too much complexity to the server, different new projects were discussed to make PShuffle more customizable. The first one was a Lisp interpretor that would allow all collection operators to be written in Lisp, and clients could write and save their own on the server. Obviously, it's far from being trivial, and we didn't get enough GSoC2007 slots to have it sponsored this year. An alternative could be to move the PShuffle inside a service client, which is a new GSoC2007 project by Ning Shi, which I'm mentoring. Clients could then rely on a more customizable client to do the shuffling, or even write their own shuffling service with special rules like the ones you and nix proposed. As long as you either tag (using media properties) the media or put them in a dedicated collection, i.e. as long as they can be identified using collections, there isn't any reason why crazy shuffling methods wouldn't be possible :-) The collections thing with binary operators sounds also really useful. It would even be better if there were relational operators which could work on ID3 tags. Then could tag all my tracks as "Live" or "Studio", and with a relational '<' ID3.YEAR operator, easily have a collection of "Pre-1990 Live U2" for instance. The filtering operator work on media properties, which are automatically extracted from tags (ID3, Ogg comments, etc). So your use case is already supported by the current state of Collections! Of course, with all these features there has to be a really, really convenient user interface, otherwise it's just too much trouble to bother with. Of course, it's an important point. Work is still needed in that area, but it's certainly possible. So far, the text pattern syntax is one powerful way to build collections. For instance: (artist:"Pink Floyd" l:Meddle) OR (genre:Rock AND +compilation) OR (title:The* in:Playlists/Foo (NOT year>2000))
Builds a collection containing Meddle by Pink Floyd, all media that have "Rock" as genre and which are flagged (using a media property) as compilations, and all media in the Foo playlist whose title starts by "The" and which were release prior to 2000. Note: the AND is implicit when several conditions are put in a sequence.
Collections in the XMMS2 music player Posted Jun 20, 2007 21:07 UTC (Wed) by nix (subscriber, #2304) [Link] Lisp interpreters *are* trivial at their core, especially if (as for anapp like this) efficiency is completely unimportant. Something like SIOD is really not hard to integrate, and SIOD is way more complex than a minimal Lisp interpreter needs to be.
(Read McCarthy's original paper sometime, it's brilliant. That most
(btw, I'm not really sure `play these as a unit' really counts as
Collections in the XMMS2 music player Posted Jun 21, 2007 7:03 UTC (Thu) by scevey (guest, #45734) [Link] Writing a Lisp interpreter is indeed trivial. Integrating a Lisp interpreter in a music server daemon, so that it has access to all the internal resources (and possibly event hooks), including libraries to access the Net, read various XML, JSON or whatever feeds, while still allowing Lisp collection operators to expose self-describing customizable attributes, and monitoring their behaviour to make sure they're running correctly, is not trivial. If you want to do it, you are of course welcome :-)
I qualified your use-case (play these as a unit, and these not) as special because I don't know any player (physical or computer-based) that would support it. However using collections it would be quite trivial to implement it in the client, as you have all the facilities to do it. A 30-line Python script would probably do.
Collections in the XMMS2 music player Posted Jun 21, 2007 20:09 UTC (Thu) by nix (subscriber, #2304) [Link] Yeah, agreed, doing all *that* is distinctly nontrivial, but I didn't knowthat collection operators had to access the net! It seemed like a simple data-massaging to me, not a massive integration from multiple sources. (But maybe I was misreading.)
And Rockbox can support this use case, sort of (the random
And collections are deeply cool: combined with the client-server part of
Collections in the XMMS2 music player Posted Jun 24, 2007 10:42 UTC (Sun) by scevey (guest, #45734) [Link] It does not to offer all these features per se, but if you want to allow advanced operators that, for instance, use Artist similarity from Last.Fm, or other data feeds, you would need them. Anyway, right now I think we'll be focusing on Collections API + Service clients for this kind of thing. Please feel free to let us know if you have suggestions or comments on XMMS2, either through the Mailing-List or the IRC channel (#xmms2 on freenode)!
Collections in the XMMS2 music player Posted Jun 21, 2007 18:47 UTC (Thu) by TRauMa (guest, #16483) [Link] As long as you tell Quod Libet each classical work is a seperate "Album", it supports your use case.
It also has dynamic playlist based on search and filter terms, although no SoC-Projects and new terms like "Collection".
Collections in the XMMS2 music player Posted Jun 28, 2007 15:04 UTC (Thu) by scevey (guest, #45734) [Link] Quod Libet is really quite a cool player. I thought I had mentioned it in the manifesto but apparently not. I like the choice of browsing "views", the search syntax. It's not super fancy, but it's definitely interesting.
In the case of collections, the challenge was to abstract the concept and the API so that it could be used by all clients ("interfaces", if you want) and all the internal parts of XMMS2 transparently. In fact, it's only a building block for more advanced features (Party Shuffle, tagging, mlib organization, etc).
|
|||||||||||||