Collections in the XMMS2 music player [LWN.net]

Collections in the XMMS2 music player

Posted Jun 19, 2007 7:34 UTC (Tue) by scevey (guest, #45734)
In reply to: Collections in the XMMS2 music player by thoffman
Parent article: Collections in the XMMS2 music player

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.

(Log in to post comments)

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 an
app 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
ancient of Lisps isn't one I'd recommend writing an interpreter for today,
but it does show how easy it can be.)

(btw, I'm not really sure `play these as a unit' really counts as
`special'. It's something *everyone* listening to classical music will
want, for example, and we're not as rare as all that. Not just classical
stuff, either: Steve Reich's not exactly classical, but shuffling the
movements of _The Desert Music_ would leave you with a meaningless
jumble.)

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 know
that 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
auto-change-directory feature).

And collections are deeply cool: combined with the client-server part of
XMMS2 (so I don't have to put up with the IMHO odious skins) it looks like
it might be a worthwhile replacement for/addition to MPD on my local
net :)

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)!