[dot] Amarok 2.0 Interview: Jeff Mitchell

[Dot Stories]

URL: http://dot.kde.org/1181812157/

From: Amara Emerson <amara01emerson at gmail.com>
Dept: manchester-united-teaparty
Date: Thursday14/Jun/2007, @02:09

Amarok 2.0 Interview: Jeff Mitchell
===================================

   In the lead-up to KDE 4, Amarok [http://amarok.kde.org/] 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.