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.

Dot Categories: 

Comments

by Anonymous Coward (not verified)

I'm very excited to see oboe-support coming. Keep up, good work!

by Anonymous Coward II (not verified)

Surely woodwinds were supported before? I can't believe the developers would have limited instrument support to brass and strings when playing music; that's like trying to censor sax and violins on TV. It's just not going to work.

by ne... (not verified)

Hey, don't leave out the percussion section. Without the beat there won't be any music...

by Anonymous Coward II (not verified)

Oh, the developers are already very accustomed to hammering on things, so that's no problem.

by Teddy (not verified)

Gooood wooooork!!!!, hope next Amarok release have nice GUI and look n feel, so not only have good functionality, but also the nice GUI design.

by larsivi (not verified)

I tend to plug Amarok whenever I can, but some complains about not having the ability to enhance the sound, or at least not easily. Especially mentioned as an example, is WinAmp's Enhancer plugin.

Supporting this would probably pull over the last few that still haven't seen the light ;)

by shamaz (not verified)

I'm not sure this would be simple with phonon :s
Maybe I'm wrong.

by Paul Eggleton (not verified)

If not Phonon itself, then at least one of the backends connected to it should provide this (gstreamer, xine etc.)

by Arne Babenhause... (not verified)

Then it "just" needs to be integrated seemlessly in amarok. As user I don#t really want to have to know, that I'm using Phonon.

by vaulter (not verified)

So. What to do, if i want to have some dsp effects in Amarok? :)

by Rudd-O (not verified)

Guys, please DO NOT CUT queueing. I use it all the time! Besides, all my friends I've introduced to Amarok have loved it and one of the reasons that they love it is that they can queue lots of tracks without having to alter their playlist!

by Hagai (not verified)

I'm with you! One of the things I sorely miss on other players is the ability to queue tracks when I'm in shuffle.
On the other hand, they said that maybe queuing won't be needed in 2.0? Hm..

by Alec Munro (not verified)

I've got to second this. Maybe they will have some neat alternative, but I tend to have a fairly large playlist, playing randomly, and it's nice to be able to pull a single song out to be played next without having to change either the list itself, or the playing method.

by WPosche (not verified)

I'll third it!! I always play one large playlist in shuffle and then sometimes queue the songs I like to listen to next.

"So Amarok 2.0's Playlist is being designed to better show information about the current and upcoming tracks while discouraging huge long playlists."

Please don't discourage long playlists (I don't care if it slows down my PC) and don't cut queueing.

by Fede (not verified)

Fourth here. Ditto for long playlists and queues, I don't think I'll be using Amarok 2 without them.

by Mootjes (not verified)

5th
Long playlists make it perfect to choose your songs. Please don't disencourage it :(

by Robert Bill (not verified)

6th

I think I've got to use another media player if you remove this absolutely necessary function :-(

Or please let the "old" playlist remain in Amarok so the user can choose what he wants to use ...

by richlv (not verified)

for you and other posters who said they are using long playlists :)
there are several reasons why using a short playlist in amarok is better than a huge one where you just lump all your tracks.

i know that it is kinda hard to break that habit when coming from other, less functional ;) players. i did that myself.

so, please, don't dismiss my suggestion without trying it for a while.
http://amarok.kde.org/wiki/Dynamic_Playlist_Walkthrough
try to follow this. don't use a playlist larger than 30 tracks for some time. play around with smart and dynamic playlists. i hope that in a week you will feel no need to use queuing anymore.
make sure you use all the neat features of the collection browser to find and dragndrop tracks you want explicitly, outside a dynamic or smart playlist.

and if you feel that the article lacks in some way, please, tell about that (or just add the missing information right away :) )

by NabLa (not verified)

What he said is that queuing will be cut, and mainly because it won't be necessary anymore. Let's see what's their solution for it...

by Seb Ruiz (not verified)

Sorry if you understood that queuing is going to be cut from the playlist functionality - this is simply not the case. I believe Jeff meant "adding to the playlist" not "queuing to the playlist"

by Jan Braunisch (not verified)

What do you mean by adding to playlist? Seems wierd not to be able to add to the playlist...

by Jeff Mitchell (not verified)

There was an extra bit of information that Amara Emerson asked me that unfortunately didn't make it into the interview (since it wasn't one of his questions). He mentioned that he hoped queueing wouldn't be cut since he liked it quite a bit, and I said that it was being looked at but was by no means a certainty. I'm not the one working on the new Playlist design so I was passing along early musings that I'd heard.

I wouldn't worry too much about it. We're aware that this is a much-loved feature in Amarok, and if it was cut I think it'd only be because we'd found a better way to handle it.

by Diederik van de... (not verified)

Cool!! thanks a lot for such well thought out concept! :-)

by Rares Sfirlogea (not verified)

phew ... I almost had a heart attack :). Thanks for the elucidation.

by mirshafie (not verified)

You people have created a great application, so I guess us users owe you some trust. But I do find it a little worrying when you say that Amarok was never meant to work with large playlists, but rather with a suggestion based system.

Some users may find queuing counter-intuitive, and that's fine. They can currently set Amarok to not shuffle and move the playlist entries up and down as they wish. But many users, me included, want our albums in order. Just because I want to hear song #6 after song #2 on a certain album, does not mean that I want it to appear that way in the playlist. So I use the Queue, which is perfect.

I've tried smart playlists and dynamic playlists, and while I sometimes use them a lot, they are not always better than having a large playlist. Simple reason. Creating a smart playlist is like creating a email filter or whatever. It takes some work. To create a playlist you just need to search the collection and drag&drop whatever you want to listen to for the moment. To create a smart playlist for ALL the music on my hdd would be really painful since it is so much, and since lots of it are not consistently and properly tagged.

In fact, I think that if possible, you should try to design Amarok so that it COULD support large playlists. Perhaps an option to tone down the suggestion-making.

Maybe someone could do an interview with the people that work on designing the playlist, so we could get some more info there?

Again, thanks for a good article and a great application. Thanks.

by Darkelve (not verified)

"Guys, please DO NOT CUT queueing. I use it all the time!"

Yeah, what do they mean I won't be able to queue my songs anymore? The queue manager is (was?) one of the best things about Amarok...

by harold (not verified)

I also love the queueing in Amarok.

by MJT (not verified)

I too say please don't cut queueing... I have my cd collection turned into mp3s and when I load up a few albums... I tend to queue up about 6 or so of songs i want to hear right away... then listen to the rest of the album in its intended order from the musicians and producers.

I always seem to queue up certain songs on a Friday afternoon for example to get psyched for the weekend...

Anyway my $0.02 i know but important enough for me to reply and support queuing support in Amarok 2.x

by Jo-Anne (not verified)

Yes indeed, do NOT cut queuing. It's THE most used option I use in Amarok, it's what separates Amarok from all others in my book.
I sometimes -have- to use Windows and I've searched for a music player which allows queuing like I've grown accustomed to but haven't found one much to my chagrin. I love it when I can wander through my rather large playlist which holds my most valued music for a longer period of time.
But depending on the mood I'm in, I want to pick a number of songs -only from this playlist mind you, NOT from the even larger number of songs I've collected in total- and queue them for the 'spur of the moment'. And I'd hate it if this option wasn't available anymore.
What I would like even more, is when you would re-enable the shuffle possibility in said queue manager. Earlier Amarok versions would allow this queue to be shuffled once again, _after_ queueing a number of songs. I loved that! I mourn the loss of that possibility every time a new release is issued and find it's not re-instated. Even contemplated going back a number of releases to regain that.
I know it sounds silly, but I loved it. Please, please, if you could get that option back, I'd be forever in your debt.

by Diederik van de... (not verified)

> ..only to discover that they've queued up 6,000 tracks. (..) So Amarok 2.0's Playlist is being designed to better show
> information about the current and upcoming tracks while discouraging huge long playlists.

I'm not sure about this idea. It sounds good to try other usability concepts, but I hope it won't become an excuse to ignore a particular use-case. That's playing the whole list. I have to admit, nowadays I generally let Amarok build a nice short play list because long lists have lot's of crap. For example a random one, or a specific genre (that browser just rocks, also to cut the number of genre-misspellings).

But one thing strikes me: before the user discovers these abilities, they'll try to dump their whole list in Amarok, and let it play it. If they can't do that, will they like Amarok as music player..? Will they still try to look further in the program to learn about short-lists?

Either these usability enhancements potentially make such short-lists usage more obvious, or there will be complaints about "not having a full overview (=full list)" :-/. I love to hear more about the dev teams thoughts here!

by George (not verified)

I really hope they don't make it harder for those of us who want to have their whole list available and to remodel it fast.
I for one pretty much keep All my music in the playlist,and shuffle trough it , and when I remember a song, quicly search for it and play it.
Also,sometimes i just want 2 artists , and use OR in the search field, and sometimes I'd like to remove one of them,or to change with another, thing I can do very easy with the large playlist and search feature.

I'd really not want to spend a lot of time just hitting next, or playing with my playlists just for 1-2 songs or artists. Time is of great value for all of us, so please keep that in mind when doing the changes you are going to do.

Thank you for the great player that Amarok is so far !

by Ian Monroe (not verified)

From a UI prospective, we are certainly optimizing the playlist for use as a dynamic playlist or playing a few albums at a time. Essentially, the playlist is not a collection browser. And as Jeff mentioned, dynamic playlist's functionality should be extended so you could play your whole collection.

But if you must pretend your using XMMS and add your whole collection to your playlist, Amarok 2.0 will actually preform a lot better doing so. I'm the developer of the new playlist, and one thing I wanted to do from the beginning was ensure that large playlists does not cause the lags and large memory use that it does now. (Well, or at least, unreasonably large memory, obviously its going to use more memory.) The Qt 4 Interview system makes it possible.

by Göran Jartin (not verified)

> I'm the developer of the new playlist

Then please confirm that cueing will not be removed!
I start a playlist of 50 or 100 random songs almost every night, and every so often one song will remind me of a few others. Sometimes, I end up with a cue that's longer than the playlist ;-)
But, of course, if there is an even better system than cue, I wouldn't complain.

by Diederik van de... (not verified)

Thanks! :-) You guys seam to have a good grip on thinking it out :-)

Then what I'd like to know is this: how will the new playlist idea in Amarok work with full albums? Some of us (well, a lot of us) still listen to whole albums, and a subset of them (including myself) listen only to full albums most of the time (if not all the time), so I was wondering what's being done to promote the listening of full albums in this dynamic playlist fashion?

by Ian Monroe (not verified)

Currently dynamic playlists work on just single tracks at a time really. It is a plan to have the ability to add random albums at a time.

by superstoned (not verified)

'discourage' sure doesn't sound like 'make it impossible' so I guess it'll work fine ;-)

by Antonio Aguillon (not verified)

Please, don't let the long playlist get out of Amarok!!! Amarok rocks! I have a LOOOONG playlist and don't believe is a good idea to look for a song in my Harddrive each time...

by Antonio Aguillon (not verified)

But warning. I would like to use a long playlist but need to be optimized the response timing. I have a collection of 7.000 songs, or so...

by peter (not verified)

I use Amarok all the time an really love it.

I'm very grateful for Dynamic Collection support, but It is true: "Amarok's never been designed for extremely large playlists". Whenever I connect an external usb disk with a collection of > 20.000 mp3 files, I would like to be able to easily play random songs (and once in a while skip one). The most intuitive way is to load 'all collection' as a playlist, which as you say isn't really smooth on a modest laptop :). Is there a better way to play random songs from a collection this size? I'd rather not make a selection myself based on artist/album/... but would like to let the collection surprise me.

by palli (not verified)

How about creating a Dynamic Playlist with the All Collection Smart Playlist as a source?

by Jeff Mitchell (not verified)

Or use the default "Random Mix" Dynamic Playlist...pretty intuitive. :-)

by Sepp (not verified)

Are there any plans for native ReplayGain support? Or a way to use a ReplayGain script AND volume control?
http://bugs.kde.org/show_bug.cgi?id=81661

by Martin (not verified)

Maybe in Phonon?

by Jan Braunisch (not verified)

Amarok not being designed for large playlists is pure nonsense! For example we have the filter function which is great for huge playlists but not necessary for small ones. The queue function is another example, if you have a small playlist you can easily drag the track in the order you want, but that gets very inconvenient if you have a large one.

Without a large playlist, I don't understand how I could listen to all the music I like (which is about 2000 tracks) without actively changing the playlist all the time. That would become a PITA after a while. I'ts much easier to drag the music you like to the playlist once and for all and then just turning on random... And if I once in a while want to listen to an album I can just enqueue it and rely on amarok starting to choose tracks randomly after the album is finished.

You should work on improving every reasonably normal way of using amarok, not on discouraging those ways you don't like.

by Jeff Mitchell (not verified)

2000 tracks may be fine. But we see complaints from people who tried to load up 4000, 6000, 8000 tracks and watch Amarok grind to a halt.

The reason is that we store playlist undo/redo information...which right now is stored as XML files, which take a while to write out and read. On top of this we have the XML file for the actual playlist itself, so that when you close Amarok it can pop back up with the same playlist that you had. We have some patches that speed this up quite a bit in the as-yet-unreleased 1.4.6, but it's still a bottleneck.

In 2.0 much of this is planned to be stored in the database which will make it much faster. But you also have to remember that the Context View is planned to be center stage in Amarok 2.0. Which means that you have a much smaller area in which to display the Playlist, so you need to use that area better than having a ton of horizontal columns all of which are cut off at one character. Amarok's always been about "Rediscovering Your Music" and having the Context View be front and center fits that theme.

As for the PITA you mentioned...why not pop all of those tracks onto an actual playlist so you only have to queue those up once? Hopefully in 2.0 Dynamic playlists will be able to read tracks off normal playlists as well as Smart playlists, which I think would solve your issue.

by Fede (not verified)

"In 2.0 much of this is planned to be stored in the database which will make it much faster. But you also have to remember that the Context View is planned to be center stage in Amarok 2.0. Which means that you have a much smaller area in which to display the Playlist, so you need to use that area better than having a ton of horizontal columns all of which are cut off at one character."

That really depends on screen size. With the current trend of bigger, higher def screens (22", 24", 30", at 1600x1050, 1920x1200, 2560x1600, with panoramic aspect ratio, etc), you should really consider that in 2.0's lifecycle many people will end up having enough space to have a playlist as wide as now or even wider. I for one own a 30" 2560x1600 widescreen monitor, and I'd like the playlist to allow me to continue using it the way I'm used to in current Amarok releases.

by Ian Monroe (not verified)

It really isn't designed for large playlists. This is just a fact. It gobbles memory and starts lagging.

by Adrian Baugh (not verified)

True. But shouldn't it be possible to do a bit of redesign so that a bare minimum of information is held in memory for everything except the current (and maybe next and previous) tracks so that even monster playlists don't actually cause memory hogging? I hear what you're saying about holding undo/redo information in XML files, but if that's causing such problems with sloth then maybe there's a better way of doing things. (Surely, improving performance with huge playlists would also make the programme slightly more efficient for normal sized ones, so everyone would be a winner.)

I do love amarok, and this is my only gripe: the developers seem to have a bit of a blind spot with regards to use cases that don't match their own preferences.

In any case I'm glad to hear that 2.0 will be faster even for those of us who like our huge playlists! Keep up the good work - gripes aside Amarok is still by far the best player out there.

by hmmm (not verified)

I love the hierarchical playlists KPlayer has. I wish Amarok2 will have something like that.

KPlayer lets me see the entire hierarchy or any part of it on the right side of the library, and will only show the informational fields that the expanded folders have.

Another thing I love about it is you can queue files or entire directories at once, and it will keep directories as folders on the playlist. I think every player should work that way.