The topic was somewhat relevant for them as it’s reminiscent of MQL, the query language they developed for Freebase. It’s worth noting that although both share a pool of buzzwords such as “graph”, “loosely-structured”, “querying”, etc, they are not quite the same:

• Freebase is essentially a giant graph-database, which you query with MQL to retrieve graph fragments.
• The XMMS2 database is a flat denormalized store, which you query with graph-structured Collections to retrieve a list of entries.

Note: Collections 2.0 should however allow fancier querying to retrieve tree-shaped structures.

About 10-20 people showed up and listened to me blurbing about the concept of Collections, the rationale behind them, the API, Collections 2.0, possible UI uses, what it represents for the user, pointers to S4, etc.

It’s all in those over-engineered slides that I have no choice but to put online, under Creative Commons Attribution-Share Alike 2.5 License, for them to live on forever on the internets. And yes, it’s still either in evil Keynote format (source), or in PDF.

Oh and Metaweb, thanks for the food!

Although tilman and DraX hacked fervently on GenIPC, most of what we worked on wasn’t code, but rather discussions on the organisation of the project, the status of projects waiting to be merged into the main tree (GenIPC, service clients, collections 2.0), as well as future projects we want to explore, such as mergestatus (a pimped up iteration of the merge page) and an official GUI (yes!).

The main issue we identified with organisation is the lack of clear vision of where we are heading. Projects like GenIPC or mergestatus are being worked on without a general and agreed upon (let alone written down) specification of all they entail. The decision we took was to try to get tru back into a role of project manager and require proper wiki pages to be written about all the major features that are being developed. I personally want to start blogging more about thoughts and projects I’m working on (I know I’ve said it before, but this time it is true).

Saturday Night Hacking, by theefer

I had several discussions with nesciens, who has been hacking on collections 2.0 last summer, and we identified different topics that should be explained on the wiki and possibly discussed with the rest of the team:

• Advanced (insane) queries (to retrieve all sorts of information and structures from the mlib using collections)
• Source goodness (server magic to make collections select the right value according to a global ranking of sources)
• Token operator (to match tokens, which is what you usually search for, using an external token table)
• Other new collection operators (in particular, related to treating medialists, i.e. keep collections ordered throughout the DAG)

Note: most of the links above are work in progress, meaning they’re not total rubbish, but don’t rely on them to launch your personal space capsule.

Other fancy stuff that has been debated:

• Proper serialisation of the collection DAG over IPC
• Usage of xmmsv_t dict to store collection attributes, possibly richer than strings (already started by anders)
• Idlist as a simple attribute in Idlist collections
• String table (optimisation of strings in the DB to avoid duplication of data)

nesciens has already started updating the todolist/roadmap.

And of course, the super exciting new project that nobody even expected: a common effort to work on an official GUI client!

I have a lots of thoughts about this, and I need to summarise all the discussions related to it at FOSDEM. And that will be the topic of my next post!

(Who said you couldn’t have cliffhangers in blog posts?)

Farewell group photo, by theefer

In the meantime, I wanted to write a wrap-up post about this year’s mildly successful Google Summer of Code with XMMS2. Out of 6 projects, we’ve had 3 successful projects and 3 failed ones. That’s a pretty high and disappointing failure rate to be honest. You always have to be prepared to face unplanned obstacles, but it got a bit out of hand this time.

It is especially frustrating as the projects were all pretty sexy or important, or both.

The long-awaited Generic IPC project seems to be one of those cursed projects that nobody manages to get done. We ran that project last year but it was not finished in time, so Leonid Evdokimov (darkk) took over this year, but he wasn’t able to complete it either.

We had been lucky to get an extra slot to run the S4 project, an experimental new backend for the medialib optimized (in structure, space and performance) for the specific semantics of our data (basically, short property strings attached to objects). Unfortunately, Tobias Bengtsson (ydo) got more busy than expected with his master thesis and a major hardware failure put an end to his hopes of completing S4.

The last failing project was probably the most original/experimental: cloudstream, or a smart blend of xmms2 local music playing and last.fm’s social & semantic information, allowing to play “local radios” of your tracks using a sexy graphical cloud interface. We were especially excited as it had come as a spontaneous suggestion by the student, Arpith Siromoney. Sadly, only little code was produced; we hope that the idea will live on and end up being implemented in one way or the other!

On the brighter side of things, the three other projects were a great success and we hope to include them in the -devel tree and the main release ASAP.

Daniel Chokola (puzzles) worked on getting Ning Shi (zeegeek)’s Service clients (which I mentored for GSoC ‘07) ready for merge. He reworked the concept a bit (operations involved, atomicity of registration, etc), gave the API a refresh and rebased the tree onto the latest -devel releases. From early on, it had also become clear that it would all be nicer with the result/value-split refactoring that had been discussed for some time. Nobody had time to hack it up so I did, and I worked closely with puzzles to update service clients to use the new code and giving him a hand cleaning up the server-side and IPC layer. It’s now a good showcase of the cool new xmmsv_t API!

The first project I mentored was nycli, also referred to as “the new korving CLI”, a new CLI client for XMMS2 in C that I had started to take over from my previous C++ client, nyello. I had run out of time to work on nycli but Igor Ribeiro de Assis (greafine) did a great job taking over the code, improving it and completing all the missing features and adding some of his own: commands to interact with the playlist, collections and server actions, support for subcommands, file path globbing, interactive status command, and the super cool aliases!

The second student I mentored, Erik Massop (nesciens), hacked heaps of new features into Collections (my GSoC ‘06 project): new operators (incl. Order, Limit, generic comparison, Token, etc.), server-side source preferences, support for medialists (ordered collections), new query mechanisms allowing aggregates, functions on values and more complex results, conversion of all values to strings, optimized prefix matching, etc. Here come Collections 2.0!

As an organization, we acknowledge our failure at choosing students able to complete their projects in full and in time. We had a much better success ratio in the previous editions, so I guess this year is a combination of bad luck and small defects on the part of mentors and students.

Next year, I’d like us to improve communication between mentor and student, and also between the GSoC participants and the XMMS2 community. Status updates on the planet, clearer project descriptions, better linking throughout the wiki, etc. I’d also like to focus on working on a stricter list of objectives, roadmap and deadlines with the student, to help us keep track of progress more formally. I think we already had a pretty good selection process, but that might be improved too.

Nevertheless, I’m very happy with the students I mentored (nesciens, greafine, and puzzles unofficially): they all showed dedication and genuine interest in their projects, they were very open to criticism but also ready to provide arguments and new ideas to make solutions more elegant.

I look forward to seeing the GSoC code merged in official releases; it has sometimes taken longer than we would have liked in the past, but nycli and service clients should make it to your Git tree in the near future. Collections 2.0 still need review and tests, but the possibilities are already quite exciting!

Congratulations to all the successful students, thanks to Google for sponsoring this program, and let’s make it even more successful next year!

The number of music players on Linux has been steadily increasing lately, but while these projects have been getting more and more polished, we have yet to see revolutionary improvements in terms of user experience. Indeed, the trend has privileged borrowing as many features as possible from other projects, rather than questioning the reasons behind their design.

This article describes XMMS2’s attempt to address long-standing limitations of music players, through its new support for Collections. First, I will summarize the rationale behind this feature, then present its concept and implementation. A conclusion about the current state and future directions of Collections will close the article.

Design rationale

I have been concerned with the state of music players for a long time. Two years ago, I wrote a Manifesto for a Better Music Player. Although my ideas have evolved since then, the general conclusions of that article still hold.

One important argument I made is that the design of a music player should focus on the users’ needs, rather than on a list of well-known features. All the traditional features (playlist, media library, cover browsing, etc) and hacks (play queue, random mode, etc) stem from the needs users have for:

• playing music non-linearly
• searching for specific media
• browsing their media library
• organizing their music

Non-linear playback was first introduced in a crude form as the “random mode”, directly inspired from legacy CD players. iTunes later popularized its “Party Shuffle” mode, which solved the unpredictability of playback by maintaining a queue of randomly selected songs. What we are still waiting for, though, is a smarter mode that would also take into account beat, artist similarity, or other semantic information.

All music players based on a media library provide a search feature. Unfortunately, its power is often hindered by annoyingly complex forms used to choose the fields to query. Few developers seem to have noticed the success of Google’s search interface: minimalistic, but enriched by rating heuristics and a rich syntax for advanced users.

The other axis required by our ever-growing music libraries is browsing. Media library browsing is always present in some form, although mostly simplistic and uninspired. When they are not cloning iTunes genre/artist/album filters or cover art browsing, most music players simply present the users with the list of all their media in a plain multi-column layout. Easy to implement, but hard on the eyes for the users. Interestingly, Foobar2000 (freeware) is the only popular player to allow a rich customization of the layout, which greatly improves readability.

The lack of features that help users organize their media library contributes to the difficulty of addressing the two previous issues. In the physical world, users can arrange their CDs spatially in their own personal way (by artist, date of release, mood, etc), set a couple of albums aside for playing at a party, or highlight their latest acquisitions on a shelf. This lets them build a cognitive map of the location of items. On computer-based music players, however, they are barely provided with the possibility to create playlists, possibly dynamic, but seldom integrated well enough to be used powerfully. Even bare files have richer organizational possibilities, using directories!

The reason behind these limitations is not that they are inherently unsolvable. The truth is that a lot of effort is required to implement new approaches in any of these fields. Experimentation, either conceptual or in terms of interface, is expensive.

The Collections concept

The goal of Collections is to address this problem by creating a common abstraction layer. Search, browsing and organization all share one property: they act on subsets of the media library. Computers are especially good at handling sets, but music players haven’t really exploited that fact yet.

A collection is defined as a subset of the media library.

This set of media (songs) can be dynamic, for instance “All media by Kraftwerk released prior to 1980″ or “All media added to the media library last week, except those by Justin Timberlake”. A static set, for instance hand-picked media selected for parties, is just a special case of dynamic sets.

Note that a collection is not merely what some players call a “Smart Playlist” (or “Dynamic Playlist”). A “Smart Playlist” is only used to play an arbitrary list of media, while a collection is a generic representation of a set of media. For instance, this includes the results of a search, a filtered view of the media library, the list of tracks from a given album, etc.

Because a collection is an abstract representation, it can be used ubiquitously throughout all the features of the music player: browsing, searching in the media library or the playlist, enqueuing, jumping, etc. A collection can also be saved on the server, thus allowing the users to organize their music and reuse their selection in homogeneous and flexible ways.

Collections for the XMMS2 player

The XMMS2 project turned out to be the perfect ground to implement collections. Unlike its popular predecessor XMMS, XMMS2 hasn’t gathered much attention yet. However, it features all that you would expect from a recent music player: a media library, support for many audio formats and multiple platforms (Linux, *BSD, OS X, Windows, etc), bindings for many languages (C, C++, Ruby, Python, Perl, Java), and a friendly community open to innovation.

In addition, the player was designed according to a client-server architecture, so that the server is responsible for all the boring work (audio decoding, media library management, tag extraction, etc), while any flavor of user interface can be implemented as a client connected to the server, possibly across the network.

Collections have been implemented in XMMS2 as a student project during the Google Summer of Code 2006, and finally merged into the stable tree on May 20, as part of the DrJekyll release.

Support for collections was implemented on the server, as a layer above the media library and playlists (more about that in the implementation details), and exposed to the clients through a collections API. This API allows clients to save collections on the server, query the media library, enqueue the content of a collection, etc. Thus, although the user interface depends on the client, the server and the clients all share the same abstract representation.

Clients are also freed from the need to generate complex SQL queries themselves; instead, they can easily build a (DBMS-agnostic) collection and the tedious query is performed by the server. In addition, a parser is provided to generate a collection from a string with an enriched search syntax.

Collections make it essentially trivial to browse and search the media library. Moreover, advanced features are either natively available or very easy to implement: iTunes-like Party Shuffle, recursive filtering (e.g. search inside the playlist), display Top 10 or never played songs, changing the equalizer settings if the playing song is in a particular collection (e.g. “Jazz Vinyl rips”), etc.

Implementation

Strictly speaking, collections are implemented as a directed acyclic graph (DAG), each node of which is a collection operator. In fact, because the structure is recursive, each node of the graph corresponds to a collection. This model was chosen to emphasize the aggregated nature of users’ music collections.

Collection operators come in four different flavors:

• set operators
• filter operators
• list operators
• reference operator

The set operators take an arbitrary number of operands and returns the collection obtained by applying the corresponding set operation to them. For instance, “any music by The Beatles or any music by The Rolling Stones”. Available set operators: union, intersection, complement.

The filter operators enforce conditions on properties of the media; the resulting collection only contains the media that match the filtering attributes. For instance, “all the songs with ’stairway’ in their title“. Available filter operators: equals, match (partial matching of strings using wildcards), larger/smaller (for numbers), has (checks whether a property is present).

The list operators are a bit special. The basic list operator (called “idlist”) does not accept any operands; instead, it simply generates the collection corresponding to the custom list of media it contains. Because list operators store static, ordered lists of media, they are used as playlists in XMMS2! Available list operators: list, queue (pop songs once they have been played), Party Shuffle (takes an operand, used to randomly feed the list with new entries).

The reference operator is simply used to refer to the content of a saved collection or playlist. For instance, “all the songs released in 2007 in the Foo playlist“. A reference operator is also used to refer to the whole media library (all media).

Now, let’s illustrate all this with a sample collection structure:

The nodes represent collection operators, while edges simply connect operands to operators.

Here, “All Media” is a reference to the whole media library, and we use a Match operator to only keep media for which the artist has a name starting by “A” (1). We then take the union (3) of this and the content of the “Rock 90’s” saved collection (2). The result is passed as an operand to a Party Shuffle operator (4), which we save under the name “Interesting” (5).

When the user plays the “Interesting” playlist, songs are popped from the list as soon as they are finished, and new songs matching the operand collection (3) are automatically enqueued, so that the list always contains at least 20 items. This is specified by the “size” attribute of the Party Shuffle. Of course, the user can also edit the playlist and add tracks to it manually.

This is only one example of collections among many. As you can see, the modular structure of collections allows virtually unlimited possibilities. As such, they have been tightly integrated both on the server and in the client API.

On the server, a dedicated module is responsible for handling collection features. When a collection is queried, it serializes the structure into an SQL query, runs it in the media library and returns the matching media, either as a list of media ids or hashes containing the requested media properties. When a collection is saved on the server, it is added to the collection DAG and kept in memory while the server is running. On shutdown, the whole DAG is serialized into the database. Note that playlists are nothing but collections, albeit restricted to list operators and saved into a dedicated namespace.

In the client API, collections introduced many important changes. First, executing raw SQL queries has been deprecated; all queries are now to be performed using collections. Collection data structures can be built either using a set of dedicated functions, or by calling the collection parser on a string given by the user. Finally, many XMMS2 methods have been extended to support collections (e.g. to enqueue media) and new methods allow clients to query, save and retrieve collections from the server.

If you want to learn more about the concept of collections, please have a look at the collections concept page on the XMMS2 wiki. For more details about the implementation, check the collections design page and the API documentation.

Adoption and future directions

Several XMMS2 clients have started offering features based on collections, including Abraca (GTK2 client) and gntxmms2 (console client). Other clients have ported search and browsing to the collections API: Esperanza (Qt4 client), gxmms2 (GTK2 client) and the official command-line interface.

Hopefully, client developers will start exploring new directions now that collections are in the main release. The xmms2 CLI client has already been scheduled for a full rewrite.

Several improvements are also expected to address current limitations of the collections implementation. One limitation is that all collections are treated equally as media sets; if a filter is applied on a playlist, the order and duplicated items will be lost. A smarter internal distinction between lists and sets inside the DAG is in the works. An ordering collection operator could then be introduced to transform a set into an ordered list, as well as an operator to select subsequences of such lists, similarly to SQL LIMIT operation. They could be used to create a collection containing the “list of the 20 most recently added media”. The SQL query generator could also be further optimized, unless we decide to replace the database backend completely.

Collections have just made it into the official XMMS2 distribution, but people already use them through features like search, Party Shuffle or groups of songs saved in the media library. They are a powerful toy for developing new features in the clients and hopefully helping users organize and use their music library.

It’s an exciting time to come up with fresh ideas in the XMMS2 world, and I hope the rest of the developers in the music player community will take the time to reflect on and discuss all these questions earnestly!

First, the new DrJekyll release finally includes the code I developed as part of my Google Summer of Code 2006. That thing where you spend your summer nights coding Free Software on an Open Source project and Google sponsors you for it, yes that one. My project was to implement Collections, a new (awesome, life-changing) abstraction layer to help developers give more power to the users for organizing their digital music library, and listening to songs in all sorts of crazy way.

I just published an article in the LWN to explain the how’s and why’s of it all. For two weeks, it’s only available to subscribers, but after that it will be publicly available and I’ll repost it here, so stay tuned…

In addition, I’m now mentoring a student for XMMS2 as part of the Google Summer of Code 2007. ZeeGeek is working on Service Clients, a new sexy feature to allow XMMS2 clients to offer services to other clients. He’s doing a great job so far, and I’m looking forward to more power and modularity in XMMS2!

Finally, I started hacking on the new korving CLI (codenamed nycli, because I said so). It’s in my Git tree on exodus, but it doesn’t really do anything useful yet (let alone wrestle crocodiles). More on that when it becomes actually usable!

Conclusion: when the music is end xmms power of the pc.

Apart from your grandma and deaf people, few people do not use computers to play music. It has become part of the digital experience to listen to music while surfing/chatting/coding/gaming. And yet, if you ask people, most of those who care the least bit about the usability of the programs they use will agree that no music player is perfect.

Windows users will curse in frustration about the unwanted bloat of Winamp 5 or the pathetic hegemony of the lesser “default” player, Windows Media Player. MacOS X users will point at iTunes with great pride, only to confess that its monolithic perfection is actually spoiled by loads of frustrating details. Unix users will gladly demonstrate their contempt over the most popular player, XMMS, a convenient but over-simplistic clone of the Winamp 2.* series. There exist alternative players, but for the sake of argumentative generalisation, let’s wrap it up this way: they all suck, in some way.

Maybe your 12-year-old sister does not languish for a better, more powerful music player. Maybe you don’t care about it either (in which case, it is time to close this tab and go back reading the best page in the universe). But if you think music players could use some improvement, read on.

In this article, we will go through the history of music players, which will be split in three categories: the old playlist-based players (e.g. XMMS, early Winamp versions), the present media-library-based players (e.g. iTunes, Rhythmbox, Winamp 5) and the alternative client/server-based players (e.g. Music Player Daemon, XMMS2). Studying this evolution and analysing the features of each generation should help us identify the flaws of current music players and design concepts that will bring music playing to a new level.

Vocabulary

Before we start discussing the history and future of music players, let’s make sure we share the same definition of the most important concepts found in music players:

Library

The set of all the music the user has on his computer, or at least all the music he asks the music player to handle.

Collection

A subset of the library, that can be arbitrarily built by the user or correspond to a theme (“early Pink Floyd live sets”, “jazz songs longer than 20 minutes”) or any other criteria (“best rated songs”, “never played songs”).

Playlist

A sequential list of songs to be played. There can be one or several, but usually we refer to the playlist as the list of songs currently queued for playing.

In some players, the boundaries between these different concepts are blurred. For instance, iTunes‘ Smart Playlists are obviously playlists (list of files to be played sequentially), but also a sort of collection (since they represent a dynamic subset of the library). We will see that this mix of concepts is at the root of the flaws of today’s most advanced players.

Playlist players

Simple needs, simple players

In the nineties, with the advent of Napster, CDs and fast personal computers, more and more people started to listen to music on their machine. But due to the slowness of the 56k connections and the expensiveness of hard drives, they only had few files, usually a couple of hundreds. Playlist-based players such as Winamp (and its Unix equivalent, XMMS) were suitable: loading files directly from the filesystem to a sequential list was manageable and the size of the library was small enough to be browsed linearly.

Playlist saving/loading features made it possible to keep collections of songs, e.g. an album, a party playlist or songs of a given genre. However, the process of saving/loading a physical file on the disk manually was cumbersome and not practical. Moreover, the lists were static: you would have to update the “rock playlist” manually everytime you add a new rock song to your library… These are the reasons why playlist files were not so popular among most users.

Hack features to break the sequential flow

The jump feature (the J key in Winamp or XMMS) is nothing but a hackish substitute for a decent search mechanism. Basically, it involves looking for all song titles matching a string in the playlist; it is very fast and simple to use. However, it quickly shows it limits when you want to look for all songs by a band called “M” or even “Air”. The other obvious limitation is that it only searches in the playlist, not the entire library, and it has no knowledge of the song metadata.

The random play feature helps break the linearity of the playlist by randomly selecting the next song to play. Although this feature is very popular, it also has its limitations. First, it is not possible to preview the random queue, meaning that you only discover what song you jump to when you start playing it. Not very convenient if you want to avoid jumping to that shameful Britney song you had forgotten to erase. The second shortcoming is that you cannot introduce a factor (rating, genre, etc) in the randomness: songs are randomly chosen from the whole playlist.

The most interesting feature introduced in the playlist-based players is the queue feature. A late hack, which lets you specify a queue of songs to jump to in the playlist instead of just playing the list from top to bottom. This allows you to avoid moving songs around in the playlist and therefore you can load all your library in the playlist, keep it ordered (e.g. by artist/album) and still impose a playing sequence. But once again, the feature is a hack and has its flaws: it is impossible to view the queue (except by browsing the playlist and looking for the queued songs) and hard to manage it (reorder/edit).

Conclusion

Playlist-based players were efficient with small amounts of music files, but they don’t scale with today’s huge libraries. Various features have been hacked to try to improve the user experience, but none is really satisfying.

Users need a better way to manage their music library, with powerful browsing and searching possibilities. The queue feature also taught us that users want both quick browsing possibilities and control over the playing sequence; we will see that “real” collections can help solve this issue in a more natural manner.

These issues have led to the next generation of players, based on a media-library.

Media-Library players

Players of the new generation (e.g. Winamp 5, iTunes, Rhythmbox, Windows Media Player) now focus on a structured database of song metadata rather than just files in a sequence. In addition to artist, album, year or genre fields, additional information can be stored for each song, such as the number of times the song has been played, a user-rating, when the files was added to the library, etc.

Efficient search and browsing

The introduction of a database of metadata allows powerful search possibilities. It is possible to search by artist, album, title, or with complex queries combining them and use other properties in the mix (rating, number of times played, etc). The searches are now performed on the whole library, but remain fast thanks to the caching of the information in a database. The only possible complaint is that sometimes, interfaces tend to make the search “too user-friendly”, thus preventing the experienced users from using complex queries.

Another area that has been greatly improved by the media-library is the browsing experience. Whereas playlist-based players only relied on a sequential playlist and the filesystem tree, players based on a media-library allow powerful visualisation of the library. Clever browsing through genre/artist/album filters has been introduced by iTunes (followed by Rhythmbox and Winamp 5), while some others have favoured a much poorer tree interface (Windows Media Player, gmpc).

We now agree that the search and browsing possibilities allowed by the media-library are promising. Let’s have a look at various players implementing them in different ways.

Dumb and smart playlists

Thankfully, the players based on a media-library seem to have heard the complaint about the clumsiness of the saving/loading of playlist files: they all provide a way to directly access playlists from a side-menu. Good, this makes the concept of playlists usable at last and we will need them, as we will see later on.

More than that, they provide us with a much more powerful concept, Smart Playlists (in iTunes’ vocabulary), which are dynamic subsets of the library matching a given set of constraints. For example, a smart playlist can contain all songs by Led Zeppelin released in 1969, or all rock songs containing “paranoid” in their title. The power of the filters varies between a user-friendly interface and complex, raw queries to the media-library database. In any case, smart playlists are a very convenient way to create collections to provide selective views on the whole library, thus enhancing the browsing experience.

iTunes (and Rhythmbox)

Apart from featuring Apple’s clean and well thought-out interface, iTunes presents a unique concept: the Party Shuffle. Although the name clearly explains what it is all about, let’s repeat the idea: you choose a playlist to shuffle from and you get a random list of songs. The interest lies in the fact that you see the random sequence as a playlist, i.e. you see what songs are playing next (and what songs have just been played)! Of course, it is possible to edit the random list by adding/moving/removing entries, as well as shuffle it again.

What merely sounds like a new feature actually pinpoints the major problem that all existing players suffer from: the clumsy separation of collections and playlists. The key of the Party Shuffle is that it lets you use a collection you have prepared, without messing with the collection itself, which is better kept ordered. When a user wants to play his “70’s Rock” collection (a Smart Playlist, in iTunes’ vocabulary), he doesn’t want to ruin the clean artist/album/track sorted list. What he really wants to do is instantiate his collection as a playlist, and modify the latter rather than the former. If implemented in a clever interface, this idea will be much more natural than it sounds.

Madman

Madman is an interesting music manager running on GNU/Linux. It is mostly a media-library, as it uses XMMS as a back-end player. What is interesting about this project is that it does not try to copy any famous player, and is surprisingly successful in its own clever way.

At first, the Qt interface looks a bit poor, with a disappointing tree widget to browse by artist or album. We notice that the interface is split in two: browse the library with filters and queries in the top pane, view the collections in the bottom pane. The query features are very powerful (regular expressions, last time played, etc) and it is possible to bookmark a query from the browse pane into a new collection with a single button. Neat.

Among the features, right-clicking on a song allows to play (now, next or eventually) all the songs by the same artist or from the same album. This shows the importance of the ability to act on groups of songs. Last but not least, it is also possible to edit the content of a dynamic playlist by adding or removing songs, thus bypassing the filter. Although it might seem contradictory with the very concept of query-generated playlists, it ends up being a pleasant feature for the user.

One minor feature could be added to the tree-structured dynamic playlists: it would be useful to allow inheritance of the filters down the tree, so as to refine the collections as we go deeper in the branches.

Overall, Madman forms a very clever media-library tool, with loads of nice ideas and interaction choices. The interface could be improved and should include the actual playlist (rather than relying on XMMS’ playlist), but there is still a lot to learn from this project.

Winamp 5

The most obvious improvement from the Winamp 2.* versions is the media-library. Just as other players, it supports filtered browsing, access to playlists from the interface, etc. However, the rest of the player (the main window/equalizer/playlist trio) remains unchanged. This unfortunately introduces some confusion as playlists appear in two locations: in the media-library and in the old-style playlist pane.

Surprisingly, Winamp 5 is one of the few players to offer “real” collections (i.e. impossible to play and to reorder). They really are just subsets of the library, specified by some constraints. But for some reason, when you browse a view, you cannot use the iTunes-like filters anymore; these are only visible when you browse the whole library. For the sake of ease of use and consistency, it would have been nicer to keep the same interface for both. Another flaw of the views is that they have to be dynamic, you cannot have collections to which you manually add and remove songs.

There is no concept of smart playlist at all, but if you double-click on a song in a view, it will replace the current playlist by the songs in the view and play the clicked song… Believe me, it is as awkward to use as it is to describe. In short, they have implemented interesting concepts but their usage and the user-interaction is confusing, at best.

Conclusion

A media-library is a must to improve the browse and search experience. However, it is only a tool that can be used and presented in different ways. The actual interface used by the user must be carefully thought-out and include powerful features to maximize the possibilities allowed by that tool.

Almost all players based on a media-library provide acceptable to excellent library browsing, an accessible list of saved playlists, as well as more or less powerful smart playlists. They still differ from each other in many ways, but they all share the same limitation: developers fixed the problems from the previous generation of players without daring to add a whole new concept: collections. It might not be obvious at first, but they are the missing piece to improve the browsing of the library.

In today’s players, the only way to group songs is by putting them in a playlist. But when someone creates a smart playlist, he is interested in its content, in the resulting set of songs; he doesn’t want to edit it directly to play it linearly. This is why Apple has included the Party Shuffle feature: because it allows the user to build a playlist from a subset of her library.

A better music player would introduce collections as a new concept, which would allow to browse and maintain dynamic or static subsets of the entire library. Playlists could then be created from these collections, either as linear lists or “Party Shuffle”-like random lists. Of course, it would still be possible to completely ignore the existence of collections and use playlists directly; but the availability of this new conceptual layer could prove itself a must for advanced users.

In the next section, we will have a look at the existing client/server players and see whether they seem flexible enough to accommodate all the features and interface we can imagine for a better music player.

Client/Server players

Client/Server players are not really to be considered the “next generation” players. The underlying architecture does not need to appear to the end-user; it is merely a new way to build music players, possibly allowing features otherwise impossible (multiple clients connected to one server, different client softwares, etc). The main advantage is that the complexity of the audio decoding and the media-library is isolated in the server, which lets developers focus on the usability of the clients.

There are few working client/server player projects and all are primarily developed for GNU/Linux and Unix. The oldest is mserv, which works perfectly fine although it is not maintained anymore. It actually boasts the most advanced multi-user architecture of all, but its implementation makes it hard to interface with: telnet protocol, file-based database, few song properties.

Music Player Daemon (mpd) is a popular alternative, with already plenty of clients, command-line or graphical interface. It is quite stable, but lacks a real media-library database and advanced song properties. It is therefore functional but too simple and not very extensible. MPD2 will probably be better in every way, but its development doesn’t even seem to have started yet.

XMMS2 is a convenient alternative, implementing many of MPD2’s goals. It is still under heavy development but can already be used, although it doesn’t really have a good client yet. But as it looks like the most appropriate server to develop for, this might soon change!

A Better Player

We can now describe what a “better player” would need. However, the goal here is not to describe a concrete implementation of the ideas as a usable program; we will instead focus on the features and concepts that would make a better music player. They should remain abstract and general enough to be used in very various clients, whatever the platform or the interface (command-line based or graphical).

A powerful media-library

As the basis for our player, we need a powerful media-library. It must indeed be fast and support powerful queries (DB back-end) so as to allow advanced and responsive browsing in the player. It should also handle many song properties, such as the number of times the song has been played, when it was added to the library, etc.

In a client/server architecture, the media-library is handled by the server, and the XMMS2 server has all the features requested above.

Clever browsing

Now we have a powerful media-library, we need an equally good interface to browse it. This depends heavily on the type of interface of the client, but there are enough existing players to learn from the best: favour iTunes-like filters over Windows Media Player’s tree-based interface; provide the customizability of Foobar2000; or use completion in a command-line interface. Defining a good interface is too vast a subject to be discussed here, but it should remain a main objective when developing a better music player.

The search feature must also be both user-friendly and powerful, and all the fields (including extra song properties) should be queriable. Madman’s query system is a good example of a powerful solution.

Easy playlist management

Once the library has been browsed, the user has chosen songs to play and wants to include them in some playlist. It should be done naturally and allow multiple actions: play now (possibly stopping the current playback), add as the next song, or play eventually at the end of the current list. A brilliant example of a bad interface in that regard is Winamp 5’s: no “play next” option (you can only play or enqueue the song), and double-clicking a song in the media-library plays it at once, but it also replaces the content of the playlist by the current view of the media-library!

Collections and playlists: two main orthogonal concepts

Collections and playlists ought to be clearly separated and receive equal importance, for they represent two main orthogonal concept in music players. Collections are unordered subsets of the library, meant to facilitate the browsing of a big library and build arbitrary groups of songs; they are not playable. Playlists are ordered lists of songs, meant to be played linearly; they can be edited and reordered at any time. Both collections and playlists are always editable (i.e. add/remove songs). We will see later on that there are several ways to create playlists.

When it comes to viewing, both concepts offer a different interface. Collections are browsed in the same way as the library, through search and filters. Actually, even the library is a collection, as it is just an alias for a top collection matching all the songs. Playlists are browsed as a list, much the same way as you view the playlist in XMMS or Winamp 2.*.

Collections are organized as a tree structure, playlists as a flat list. As an analogy, collections can be seen as directories, thus forming a hierarchy, whereas playlists can be seen as radio stations. There is always one and only one “playing” playlist at any given time, and usually only one collection browsed at a time as well.

There is only one type of collection, which resembles Madman’s playlists: it can be filled by a subset of the library, specified by a set of constraints, and it can also be edited (add/remove songs) by hand. Both ways are not exclusive: the collection is first filled with the query (if there is one) before songs are added and removed according to the user’s modifications. A simple yet powerful interface should be used to specify the query and view the user’s modifications.

On the other hand, there are several types of playlists, and more could be added later on. The three main types are: the list, the queue and the shuffle. The list corresponds to the usual definition of a playlist, i.e. a static list of songs with a pointer moving down to play the songs sequentially. The queue is quite similar, except that songs which have been played disappear from the list. It should be possible to view a short history of the n last played songs. The shuffle is a dynamic version of the queue fed from the content of a collection: the next k songs to play are randomly chosen from a given collection. This is the equivalent of iTunes‘ Party Shuffle.

Conclusion

I don’t pretend that the ideas developed in this manifesto will lead to a perfect player. However, I am convinced that they can help develop a better player based on what we can learn from the existing ones. Proposal for more advanced or revolutionary features will be presented in a future article.

Now in order to avoid sounding like one of these lazy wailers who dump ideas without ever developing them, I already started working on two music player projects which implement the ideas developed in the present article. Both XMMS2 clients, the first will be a command-line client and the second a graphical client.

Stay tuned…