| |||||||||||||
Collections in the XMMS2 music playerCollections in the XMMS2 music playerPosted Jun 14, 2007 15:57 UTC (Thu) by nix (subscriber, #2304)Parent article: Collections in the XMMS2 music player
I'm not certain that this solves one problem common among those of us who listen to classical music and audiobooks.
The case we'd generally like is `shuffle entire works'. You might be able to do this in the structure described by defining `media' to be `a list of MP3 files in a specific directory' or something, but this seems crocky. Essentially you'd want a way to chain media together (into little lists which may themselves have sublists and so on, so you get a tree of media?) such that operators such as sorting only apply to the first element in the list (or to a selected one? XPath for music collections! ;) ).
Rockbox acquired something that sort of works in this area by providing random directory autochanging. This is a kludge but it sort of works if you turn shuffle off and keep one work in each directory: but it's a lot less elegant than having a shuffling/selection mechanism that actually *understands* that certain media should only be played in sequence with others (unless explicitly requested: maybe you *want* to listen to only the third movement of some work, but generally speaking you'd want to start with the first movement and play to the last: shuffled movements are basically never desirable).
(Log in to post comments)
Collections in the XMMS2 music player Posted Jun 14, 2007 16:54 UTC (Thu) by scevey (guest, #45734) [Link] Good point. This has been discussed in the XMMS2 community, and so far the idea was to introduce a "selector property" attribute to the Party Shuffle. This attribute would define what property is used to randomly enqueue media from the operand collection. For instance, if you set it to "album", whenever the Party Shuffle needs to be refilled, it will select a set of song sharing the same "album" property, thus enqueing a full work rather than a single song. The current behaviour would still be activated by default by setting the "selector property" to "id". It's not implemented yet, but it's definitely planned (Issue #1352)! Thanks for your input!
Collections in the XMMS2 music player Posted Jun 15, 2007 19:29 UTC (Fri) by nix (subscriber, #2304) [Link] Yeah, but even *that* isn't quite enough. Some of the stuff on my playerI'd like to be played albumwise; some is song-by-song stuff and can be shuffled more finely.
I wonder if what we have isn't a concept of a `subcollection', where
(But maybe I'm babbling and should shut up.)
Collections in the XMMS2 music player Posted Jun 14, 2007 17:43 UTC (Thu) by thoffman (subscriber, #3063) [Link] 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.
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).
|
|||||||||||||