Amarok 2.0 Interview: Jeff Mitchell

In the lead-up to KDE 4, Amarok will be undergoing a number of large changes both under the hood, and cosmetically with the user interface. I managed to interview a developer, Jeff Mitchell, to talk about the things changing in Amarok from the 1.4 stable branch to version 2.0, including the playlist redesign, the context view and the new web services framework. Read on for the interview.

Amara Emerson: Amarok is the flagship audio player for KDE and Linux. What in your opinion sets it apart from other similar players?

Jeff Mitchell: I think there are a few things that set us apart. One was the concept of functional "browsers" which provided one of the early unique characteristics of the program, and still sets it apart in many ways today. Rather than try to define an all-in-one interface that could handle more and more and more features, they were separated into logical browsers that excelled at providing specific functionality: playlist access, music context, collection browsing, etc. Because you could easily replace an entire part of the UI with a totally new portion that provided new functionality, it kept things neat and organized. Plus, your music was always viewable, since the playlist was always shown.

Another thing that sets us apart is innovation. We've looked at what's bugged us about other players, and have pioneered some concepts that in some cases have been imitated and in other cases are still unique. To name a few, Last.fm radio was a first on Amarok. We'd supported MP3 streams for a long time, and we'd supported Scrobbling songs for a long time, so when Last.fm was born it was a natural fit. Dynamic Collection is (so far as I know) still Amarok exclusive, and it's a godsend for mobile users that have music on a laptop that is sometimes connected to other storage pools and sometimes not. Before Dynamic Collection, you'd have to rescan these other storage pools every time you reconnected; now, Amarok simply knows that that filesystem isn't mounted, and keeps the information for when it is. File tracking was also a first on Amarok (although it's been imitated in other players), and it's integrated heavily into many parts of Amarok, and it works well.

Finally, we have a real focus on our users and our community, and we're very responsive to them. Every idea brought forth by our users to enhance the program is considered, and most of them are implemented if we agree that they're good ideas and they wouldn't involve massive, destructive code changes. We try to balance this responsiveness with feature creap/option bloat so that our application stays accessible to newcomers but becomes more and more powerful for longtime fans and music lovers.

Amara Emerson: There are lots of changes in moving from Qt3 to Qt4, what do you think requires the most effort and time; implementing new features/new UI or porting existing Qt3 code?

Jeff Mitchell: I'd say overall implementing new features is more of a time sink. Qt has some backwards-compatibility classes that work as a stopgap until code is ported, so getting Amarok running on Qt4 didn't take too long initially. Many of the remaining unported parts have not been touched because those subsystems are being replaced by new ones. So new features and components is really where our time is going, and that's good, because we have big ideas and big plans.

Amara Emerson: How much do scripting languages like Ruby play a role in Amarok stable? Will they take a smaller or larger role in 2.0?

Jeff Mitchell: In Amarok stable, scripting languages were used for a few functions. The first was for plugins. We don't allow third-party binary plugins, but we expose a huge number of functions via DCOP, which is what plugin scripts use in Amarok stable to perform functions; the Amarok Script Manager would start these running and interact with them when necessary.

The other main function was for proxy behavior. For various services there does not exist a good way to get data we need; Last.fm for instance had a Ruby script acting as a proxy to handle the web interfacing, which would then pass data to the engine to play. I know that due to changes in Last.fm's API this is no longer necessary in Amarok 2.0. DAAP is also another service that Amarok supports that uses some Ruby scripting to handle interfacing with other clients, as scripting languages make speaking HTTP quite a bit easier than coding it all up in C++.

For Amarok 2.0, plugin scripts will still use scripting languages, although they'll now be using DBus instead of DCOP. I'm not entirely sure in what ways scripting languages will end up being used for other purposes.

Amara Emerson: Briefly, what major changes/features are going to be made in 2.0?

Jeff Mitchell: 2.0 is going to see a major change in the Playlist. Amarok's never been designed for extremely large playlists; the idea was always to browse and explore your music through suggestions or through dynamic playlists, but at the same time the playlist was a big listview that showed many tracks at once and lent itself quite well to long playlists. As a result, we see complaints from some users that it slows to a crawl, only to discover that they've queued up 6,000 tracks. At the same time, you had a limited amount of horizontal space to put all the relevant information in. So Amarok 2.0's Playlist is being designed to better show information about the current and upcoming tracks while discouraging huge long playlists.

Smart playlists work quite well right now, but Dynamic playlists, which use Smart playlists as sources, only allow randomization of tracks; these will probably be revamped to better fit the model of the new Playlist. In other Playlist news, I believe queueing tracks will be cut. Although queueing tracks is nice, some people find it counterintuitive to have tracks on the Playlist play in order, except for those that are queued, which will first play in order...we think the new Playlist design won't require the use of a separate queue anyways.

Other big changes include the Context View. No longer just a browser, it's planned to take front-and-center stage and contain widgets instead of rendered HTML, which ended up being severely limiting in terms of what we could show and maintainability. Our web services are getting a major kick -- we're desinging an entire framework to make it easy to add arbitrary web services later, be they music stores, lyrics, guitar tabs, concert information, etc. There is major work being done on the collection system. The meta information that is passed around to various parts of Amarok is being streamlined and abstracted; as a result, we're going to support many Collections of arbitrary types -- Internet storage services like MP3Tunes, portable music players, SQL collections (of local files) -- you'll be able to queue up and play music from all or any of these seamlessesly.

Finally, portable device handling is being handled by Solid. We've been doing work behind the scenes with library developers and HAL developers to ensure that when a device is plugged in (perhaps with the necessary device library installed), Amarok can detect it and just work with it. I can't think of a device that this won't end up just working for -- on Linux, at least.

Oh, did I mention native Mac and Windows ports?

Amara Emerson: Amarok 1.x is dependent on kdelibs. Will this dependency still be there for 2?

Jeff Mitchell: Yes, we still depend on kdelibs. We thought about going Qt-only, mainly for a possible Windows and Mac port, but now that kdelibs is actively being ported to those platforms we didn't see much benefit in losing the features and consistency that the KDE libraries often provide for us. And kdelibs, while large in terms of disk space, is pretty well self-contained; it's not *that* much to ask for those that generally prefer Gnome or another environment.

Amara Emerson: Well you touched on the framework for web services earlier. I guess the framework allows you to add new stores like Magnatune, can you expand on that?

Jeff Mitchell: Since we added Magnatune support, we've had a number of various independent online music retailers approach us wanting to provide similar support. One of our developers and a SoC (Summer of Code) student are actually looking at trying to formalize a standard API for online music stores, to ensure that all can be supported equally. These stores are good for us, as if tracks are purchased through Amarok we get a small cut of the money, all of which goes back into our project to pay for various costs (and not into any developer's pocket). Even if such a common API does not happen, the web services framework is becoming quite full-featured, and if I'm correct it, along with the new meta-information/collection infrastructure, are already supporting more than just stores - Jamendo (free music posted by authors) and MP3Tunes' Oboe (online music storage locker) already both have basic support. And adding new and arbitrary information or music sources should continue to get easier as it matures. Other information we're currently looking at providing, (besides of course lyrics and Wikipedia), are guitar tablature and concert information.