As things ramp up here at Playgrub it seems like a good time to talk about the Playdar ecosystem, how we work with it and what all this crazy stuff is about. Playdar has been getting some great buzz lately (RWW, Wired, New Scientist) but even for those involved with the project it can be hard to describe what exactly Playdar does and how it benefits the average music fan. This post is focused more for developers and early adopters but hopefully it will shed some light on the great possibilities Playdar holds for the future of music.
Like Linux, Playdar started out as the vision of a lone mad scientist. In this case Richard Jones, the founder of Audioscrobber and Last.fm CTO. You can read about RJ's tribulations with the initial development of Playdar on his blog but the end result is that we have a great platform with lots of momentum moving forward.
Playdar is built in Erlang and offers a modular plugin system for adding functionality and providing access to music in a variety of ways. To give you an idea of what this means you have to know a bit about general Playdar workflow.
Playdar itself isn't much to look at. Actually it's a headless app that you run from the command line. The real magic comes from the Playdar modules, aka content resolvers. By default Playdar enables a local library module and local network module. You setup these modules to look for music in their respective domains (your machine, your network). Once a module finds a collection of mp3s, it indexes them based on the song metadata (artist and track name) and exposes a query interface to the Playdar core. At this point Playdar has a distributed database of songs that it can then proxy access to via the built in web server (Erlang MochiWeb).
With the metadata index and the mp3 serving localhost web server in place, a whole world of possibilities open up. Using the Playdar security model you can grant web pages (or any web friendly applications) access to your local music collection. It doesn't stop there though, they don't actually have to pull down the whole song index. The general mode of operation in the Playdar world is that web sites have lists of songs and each song's metadata is passed to the local Playdar instance to see if that song is available. Some nifty Javascript (Playdar.js) includes easy querying mechanisms and even web based playback using the SoundManger 2 library.
Once up and running, Playdar gives 3rd party web sites the ability to organize, search and listen to your music collection (even if that collection is stored across multiple machines).
Now with the foundation out of the way, let's get back to Playdar being the Linux of music :) If you're at all familiar with the Linux command line architectural philosophy you'll know that it's all about tiny pieces doing one thing well and talking to each other via a standard interface. This provides the ability to do very powerful things (like say, make a crazy Mapreduce clone in Bash) without having to "program" all the pieces yourself. The current Playdar ecosystem has very much embraced this idea. To quote James Wheare: "small pieces loosely joined innit".
If you take a look at the Playdar.org Demos page, you'll see a small but growing list of applications that support Playdar and fit very well into the small piece doing one thing well philosophy. At the base you have Playdar itself. On top of that you have a few different players to choose from. Playlick, Player.Playlick and Spiffdar.
These apps all work with Playdar as mentioned above via the Javascript interface. Pretty cool, but that's not all. They also expose their own interface (via the URL) for loading XSPF playlists. XSPF is a standard XML based playlist format that allows you to create lists based on song metadata without needing actual file paths. It's a perfect fit for Playdar. It also opens the door to another layer of application for creating the XSPFs.
Enter Playgrub. Playgrub is a bookmarklet that scrapes supported sites for music metadata, stores that data in a central repository and exposes the resulting playlists as XSPFs accessible through a REST interface. Playgrub then creates nice Playlick/Spiffdar URLs for loading the playlists. In the end you end up with a chain of operation like this:
Music site > Playgrub > Playlick/Spiffdar > Playdar (thanks Ralph for the ascii diagram ;)
Playgrub currently supports a handful of sites, but is architected in a way that makes it easy to add more.
Finally, to come full circle on the Linux analogy, one of the most exciting parts about Playdar is that everything is open source! Every project mentioned in this post is hosted on the outstanding GitHub and is ready for contribution. Check them out for yourself:
Playdar GitHub
Playdar.js GitHub
Playlick GitHub
Spiffdar GitHub
Playgrub GitHub
Comments [1]