LWN: Comments on "Collections in the XMMS2 music player"

Collections in the XMMS2 music player

KaiRo — 2007-07-06T17:26:49+00:00

Would be cool if that would be possible, it's a feature I really miss a lot in all other such apps.

Yammi has/had used XML as the storage backend, probably loading the whole "database" into memory, which obviously might sound a bit heavy on memory but is very fast (and I never saw memory problems with it).

The fuzzy search code it used is at http://yammi.cvs.sourceforge.net/yammi/kyammi/src/fuzzsrc... and is under the GPLv2 (but I guess Oliver might be open to relicensing if you need a different license).

Collections in the XMMS2 music player

scevey — 2007-06-28T15:04:22+00:00

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

Collections in the XMMS2 music player

tru — 2007-06-28T14:58:09+00:00

Didn't apple go with sqlite too? or are we talking about leopard?

Collections in the XMMS2 music player

scevey — 2007-06-24T10:42:22+00:00

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

nix — 2007-06-21T20:09:12+00:00

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

TRauMa — 2007-06-21T18:47:59+00:00

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".

http://www.sacredchao.net/quodlibet

Collections in the XMMS2 music player

leandro — 2007-06-21T16:51:28+00:00

I am not sure the current DBMS we're using (SQLite) would be appropriate

That is the problem with DBMS-agnostic applications: the lowest common denominator. I think what Apple did, in using full-featured but yet light enough PostgreSQL everywhere, just makes more sense.

Collections in the XMMS2 music player

scevey — 2007-06-21T07:03:02+00:00

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

nix — 2007-06-20T21:07:05+00:00

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

scevey — 2007-06-19T07:38:12+00:00

Mh, fuzzy search could be implemented as a new collection operator, but I am not sure the current DBMS we're using (SQLite) would be appropriate and effective for such operations. Our favourite smartest bearded lead developer is investigating a new storage backend, so maybe performance will allow that in the future.

Collections in the XMMS2 music player

scevey — 2007-06-19T07:34:07+00:00

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

KaiRo — 2007-06-18T11:27:13+00:00

It's really cool to hear of new concepts being developed in that area, and I think collections should give us a really good new perspective to achieve things we couldn't so far.

What I really miss most from multimedia apps that include "media libraries" of some sort is a fuzzy search like in the abandoned Yammi project, which was really cool when you wanted to find only roughly known song titles, etc.

Collections in the XMMS2 music player

wolfgang.oertl — 2007-06-15T23:19:12+00:00

> What we are still waiting for, though, is a smarter mode that would also
> take into account beat, artist similarity, or other semantic information.

You're probably aware of gjay for xmms (http://gjay.sf.net/) which implements at least part of this, i.e. beat and frequency analysis. This project hasn't had any releases in the last 3 years or so, though...

Collections in the XMMS2 music player

nix — 2007-06-15T19:29:31+00:00

Yeah, but even *that* isn't quite enough. Some of the stuff on my player
I'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
collections of files can be grouped into a `subcollection' which has its
own operators which apply to its members by default. So the shuffling
would apply to a bunch of individual things, and a bunch of subcollections
(`albums'), and *those* then have, by default, play-in-sequence operators
applied to them.

(But maybe I'm babbling and should shut up.)

Collections in the XMMS2 music player

thoffman — 2007-06-14T17:43:16+00:00

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

scevey — 2007-06-14T16:54:12+00:00

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

nix — 2007-06-14T15:57:05+00:00

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

Collections in the XMMS2 music player

vblum — 2007-06-14T09:19:57+00:00

Thanks for the interesting article. Could the Kraftwerk part be shipped by default ;-)