category xmms2

“XMMS2 Collections” presentation at Metaweb

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

“Music Player” session at the GSoC Mentor Summit 2009

Thanks to Google’s everlasting generosity, mentors from all Open Source projects that participated to the Google Summer of Code 2009 have flocked en masse to Mountain View to meet up and talk about code and drink beer. More in pictures in my Bay Area Flickr set, if you’re curious.

Sessions were organised spontaneously around various topics, and one of which, proposed by Amarok2’s Lydia/nightrose, was “Problems Audio Players face today”. Which resulted in 15-20 people from various projects (incl. Amarok2, Rockbox, Maemo, XMMS2 & others) talking about solving problems encountered by all music player developers (e.g. lyrics and cover art fetching), as well as features on our beloved users’ wishlists (portable player support, tags, musicbrainz, etc).

And if you weren’t there, don’t despair, for I just (finally) posted minutes for this session on the GSoC wiki. Some interesting ideas in there, so go and have a look, and get to work!

Embrace the community (Ep. I: The Fandom Menace)

Or why and how the new XMMS2 GUI client should be extensible (and what I mean by extensible anyway).

Quizz: What do Winamp, Foobar2000, Emacs, Eclipse and Firefox have in common?

(Vim users, we love you too, but shut up for now please.)

They are very popular and they highly promote extensibility.

Now, we all know that correlation != causation. What is certain, however, is that all those projects boast many fan(boy)s, some of whom even get quite religious about it.

This enthusiasm reflects itself in the emergence of strong communities: people who share content, tips, modules, extensions, themes, configurations, scripts, etc. And those people usually aren’t even core developers of the software, sometimes not developers at all; just users or hobbyists who like the project.

Paradoxically, most of what they share is aimed at personalizing the software, i.e. making it the user’s own, fitting the user’s wishes and needs. This creates a feeling of ownership and satisfaction, because the user can bend it the way she likes and master it like a pro.

In essence, the idea here is give power to people to shape the software the way they want, and they will extend it in creative ways and get together to share these extensions. And I think that encouraging this creative freedom is one of the many factors which contribute to popularity.

Continue reading

Going beyond tracks and local data (Ep. VII: Return of the GUI)

Now that we have defined what/whose problem we’re trying to solve, and debated about the implementation details, it would be worth asking why a graphical XMMS2 client would be a good fit.

After all, we have a brand new korving CLI (nycli), isn’t that enough? In a sense it is, but it fills a different niche. GUI applications are good at things that CLI applications aren’t, and vice-versa. So the goal is to exploit the specific advantages of graphical music players.

For instance, even the most hardcore fans of the command-line will admit that the following tasks are easier with a graphical player:

  • Edit a playlist, using mouse selection and drag-and-drop.
  • Browse albums by cover.
  • Organize music manually into playlists or using dynamic collections.

But these are just simple examples that are now expected of any standard graphical music player.

Can’t we get something more exciting?

As Obama taught us, “yes, we can!”

Three main aspects usually poorly supported and under-exploited in music players are powerful tools to:

  • Browse
  • Organize
  • Explore/discover

Continue reading

Gentlemen, start your toolkits (Ep. V: The Flamewar Strikes Back)

Note: tru just blogged about this subject, so I’m adapting my original draft and replying to tru’s post.

All graphical application projects face the dreaded perspective of endless flamewars about technical choices, and XMMS2 clients haven’t been spared:

What language to write the client in? What toolkit to use? What platform to support? Where to put the opening curly brace?

In fact, this freedom of choice seems to always have been one of the major obstacles to the creation of an official GUI client.

At FOSDEM ‘09, perhaps helped by the virtues of IRL discussions (and all the great food & beer), we had a debate about the pros and cons of all possible combinations and came up with a reasonable proposition that should hopefully suit most interested developers in the XMMS2 community.

Continue reading

We need a dream (Ep. IV: A New Hope)

As I said earlier, what’s lacking to make an awesome XMMS2 GUI client is a common vision.

We need a dream!

I have a dream that one day this community will rise up and live out the true meaning of its creed: “when the music is end xmms power of the pc.”

I have a dream that one day on #xmms2, the sons of former GTK+ developers and the sons of former Qt developers will be able to work together on the code of a GUI client.

I have a dream that one day even the state of Microsoft, a state sweltering with the heat of instability, sweltering with the heat of dull interfaces, will be transformed into an oasis of freedom and music.

I have a dream that XMMS2 clients will one day live in a community where they will not be judged by their GUI toolkit but by the content of their user experience.

I have a dream today!

(Kudos to Martin Luther King for the original draft.)

In the end, all we want is an awesome music player.

But do we all share the same definition of what an awesome music player is? Probably not. In fact, I don’t think most of us even knows what an awesome music player is; if there were one, we wouldn’t have to build one, right?

So the goal here is to gather qualities that we expect of such a project, and refine them into a common vision. I won’t start dropping design mockups or fancy feature ideas until we have established what we all want, conceptually.

What I expect of this GUI client, and the vision for the project, is that it should be:

  • Exciting
  • Original
  • Expandable
  • Clearly focused

Continue reading