XMMS InfoPipe Historical Preservation Site

Welcome! This page, which was recently integrated from my old site, will soon have a historical retrospective of XMMS InfoPipe  and all of the awesome now thankfully obsolete garbage that came from it.

What was XMMS InfoPipe?

Unix and Linux software is all about modularity and programs talking to each other, right? Unfortunately, that doesn't extend to GUI-based application programs: the graphical applications just run in their own isolated spheres.

In other words, if you run a music player, other programs can't find out what it's playing right now.

That doesn't mean that this is entirely so. Currently, many Gnome and KDE apps use D-Bus to exchange information between each other. In other words, all applications, even command-line programs or applications run by web servers, can talk to the graphical applications just fine and find out their internal state.

In other words, if other programs want to sniff out what music you're playing, all they need to do is to ask your music player nicely.

And this wasn't always the case.

InfoPipe was a plug-in to an early Linux media player, XMMS, that basically exposed the internal state of the player to the other applications running on the system. Basically, it was intended to make it much easier to write programs that read the XMMS state and do interesting things with that information. I wrote it because I thought that sort of functionality would be neat as hell. And because this particular implementation kind of sucked (the plugin had to be written in C and was kind of befuddling and I'm more of a Perl/Python/Ruby/Java person), I'm so happy that modern Linux media players report this information right out of the box. Heck, these days, they do bidirectional stuff too. The XMMS API was also extremely limited in terms of what information the plugins had access to; for example, plugins could only read the filename and title of the currently playing song. If you wanted the tag information (title/artist/album etc), you had to extract it out of the file yourself.

I think this is the only major piece of software that I've so far written that ended up being kind of a word-of-mouth run-away success. It even ended up as an official package in Debian (until XMMS stopped being maintained at upstream and, as a whole, was eventually put out of its misery by Debian too).

Applications

So you can read the music player state from an external program. What can you do with this information?

For some reason, it was obviously incredibly popular to put the information about currently playing songs to webpages. There were a few PHP scripts to do this. I also saw more than a few IRC client scripts that were no doubt used to relentlessly spam the channels back in the day.

My personal favourite was, unfortunately, my own script. I was listening to music late at night, using an infrared controller that controlled various pieces of software through the LIRC system. Because I had no idea what some of these songs were and didn't want to go back to the computer all the time to check, I thought it would be cool if XMMS could identify those songs via speech. So, a few moments of late-night tinkering later, I had a script that read XMMS state via InfoPipe and fed it to Festival. This script was then run via LIRC when I pushed the "Info" button in the remote. This is a simple example of neat things you can do with properly componentised system design.

Downloads

NOTE: It goes without saying that this software is totally unmaintained, and by far, none of this stuff is guaranteed to build on modern Linux systems. AT ALL. XMMS itself has probably been massively broken for a long time, so don't try to actually build these things if you value your sanity.

  • XMMS InfoPipe 1.3, a tarball of the last official version.
  • XMMS InfoPipe Garbage. Contains some additional text tidbits in HTML format, and random patches and additions that never got added to InfoPipe properly.

If I get sufficiently motivated, I might even convert the original CVS repository to Git format and stick it somewhere. Of course, converting CVS repositories to proper repository formats will be an exercise in pain!