insomnia bytes

On my way to the Google Summer of Code Mentor Summit 2009, I accepted DraX’s invitation to give a 1-hour talk about XMMS2 Collections at his work, i.e. Metaweb, in San Francisco.

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!

Over last weekend (February 6-8), I shared a fantastic time in Brussels with people from the XMMS2 team (and a few thousands over geeks and almost as many beers). We got together, mostly off our Google Summer of Code money, and spent some IRL time thinking of how to make XMMS2 better. Thanks to everyone who was involved, it’s been great fun!

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

I’m still waiting for nesciens’ conclusion notes about his very successful project, Collections 2.0, but he’s been busy with his starting university so it will take a few more days.

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

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!

This is a repost from the article published in LWN and mentioned earlier on this blog. Thanks to LWN for publishing it in the first place, and to all the people who proofread and commented on it! I hope this will serve as a more up-to-date introduction to Collections in XMMS2 (I should probably post it on the wiki). Discussion is welcome, naturally.

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.
read the rest of this entry »

I haven’t blogged about XMMS2 in a while now, but a lot has happened since last summer!

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.

No perfect music player exists yet.

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.

read the rest of this entry »