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 bas (not verified)

I have a collection of 15000 songs, with different playlists according to my mood. The biggest one has 6500 songs. I would like to continue to use this usage pattern, including queuing.

by superstoned (not verified)

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

They're trying to allow other ways of playing your music without the need for such large playlists, not to make your life miserable.

by José (not verified)

> 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.

I currently have to store the collection.db to prevent it to be zeroed when my external USB drive is off. If the function you described exists, I couldn't find it....

ack. I can't say I like the direction I see Amarok 2.0 taking. I'm going to be a bit harsh, and I apologize for that, but I keep reading these articles and getting increasingly frustrated with what I'm seeing.

> 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.
...
> So Amarok 2.0's Playlist is being designed to better show information about
> the current and upcoming tracks while discouraging huge long playlists.

This should tell you something. People want long playlists. Rather than changing the interface to make them *even more* painful in an attempt to "discourage" users from doing that, why not fix the actual problem?

> In other Playlist news, I believe queueing tracks will be cut.

Please don't do this. I use queueing all the time. There are some things (e.g. in dynamic playlists) you just can't do without it.

> Although queueing tracks is nice, some people find it counterintuitive ...

Then those people don't have to use it. Please don't cut a feature just because it's "too hard" for Grandma to use. There are much better ways of dealing with that -- improve the feature itself to make it more understandable, or move it out of the way so non-power-users don't see it unless they're looking for it.

> Other big changes include the Context View. No longer just a browser, it's
> planned to take front-and-center stage ...

Most of the time, I don't care about the context view. I don't *want* it on center stage. I want my collection and my playlist on center stage. I want the context browser to be in a sidebar, where I can ignore it until I need it.

(Yes, I realize others will have different preferences. My point is more that there should be an option, otherwise people like me will get really annoyed. ;) )

> ... 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.

This sounds really nifty. I can't wait to see how it'll work.

by Rares Sfirlogea (not verified)

I don't know if you were reading the last comments but your questions were answered. The long playlists are optimized for better performance ... the queueing is being kept or being cut only if a better solution comes up ( I doubt that you could come with such a solution but I'm open to new ideas ). From the articles I read before I understood that the interface was being redesigned but still with keeping in mind that some users would want to change it's look to be like the old one ... so I guess there is an option to hide the context view.

Excellent. If everything you say is the case, then I think 2.0 will be just fine for me.

i don't think an application should be build around such idiotic usage patterns. it makes absolutly no sense to load thousands of tracks into the main playlist when you have fully working dynamic playlist - like amarok 2 should have.

loading stuff in a listview you won't look at anyway just wasts your resources.

Sure it makes sense to have a long list available: I often look for a song of which I don't remember the title or the artist, sometimes just knowing it was somewhere in the first part of the list. Now please tell me how I could find the track without having the option to display a full list. The only other way is to browse the entire collection browser tree, checking every track in every album from every artist, clicking each time to see all tracks of one of the albums. That's just a PITA, and it is dozens of times slower than just browsing over the list.

First off, I object to your characterization of my usage pattern as "idiotic". You have no idea why I do things the way I do, and for you to make that kind of judgement is, well, pretty rude.

It's quite possible I have a good reason you just haven't thought of.

Now then...

> loading stuff in a listview you won't look at anyway just wasts your resources.

uhm. Why would I load it into the listview if I wasn't planning on looking at it?

Sometimes, a huge list of songs is exactly what I want. Perhaps I want to see my entire collection in a list/table format so I can inspect and edit tags. Perhaps I have playlists full of specific songs I've picked for listening at work. I don't want a dynamic playlist in this case, because I already know which songs I want, and I don't want Amarok making that decision for me. Maybe I want some tracks in a genre, but not others.

I commonly build large playlists and then work through them over the course of a few days. Dynamic doesn't cut it for that, either, because I want to see what's ahead, reorder tracks, etc.

Those are just a few use cases I've thought of off the top of my head. I'm sure there are more.

You can make dynamic as powerful as you want, but it's never going to substitute for just picking the tracks I'm interested in. The playlist needs to scale to support that.

The usecases that you've described, they seem not playlist-oriented, but rather collection-oriented. The fact that now playlist is better place to do it is rather coincidence ( well, I use playlist for that now a lot, too).
If all of this would be possible from collection perspective ( label support, greatly improved tag editor), I think it would be better then it is now.

by Timothy Carr (not verified)

Personally, I am looking forward to Amarok 2, but for those who don't think they will like it perhaps you could have a "Classic View" or some other way to customize it so it resembles the current style.

I've heard somewhere about xmms-visualisation support to be cut, if this is true - please reconsider. True, i don't use the visualisation plugins on a day-per-day basis, but sure often enough to miss them if they wouldn't be there at all...

By the way, it would be great if you could include once more "iris 3D", it's still very cool and configurable, and with libvisual 0.4 it wasn't supported anymore. One of the reasons i still have to use xmms from time to time. Please please please... the vis stuff isn't the crucial part about a Player, but sometimes it's fun to have it.

by Dan Leinir Turt... (not verified)

libvisual has a nicely working xmms integration layer, and since that will be depended upon for handling visualisations (as it is already) you will be able to run your ancient xmms visualisations just fine through Amarok :)

by KoRnholio8 (not verified)

I like what I'm hearing about AmaroK 2.0!!! Can't wait!

I just had an idea pop into my head: what if in the contex menu there was an option to look for the video on Youtube? (of course amarok would then stop the track playing and searh for the vid)

by Richard Neill (not verified)

Any chance of some slightly saner sound-device support? There are two bugs here:

1)If you need to use /dev/dsp1 rather than /dev/dsp (in my case, the former is the big hi-fi; the latter is the LCD monitor's speakers), there's no easy way to do it. Amarok only allows you to choose /dev/dsp, /dev/sound/dsp, or (something else I don't recall). My solution: create a symlink: /dev/sound/dsp -> /dev/dsp1.

2)When something goes wrong in Amarok (eg the sound device breaking), it very unhelpfully reverts to the defaults. This makes twice the work: first I have to fix the problem, then I have to un-break amarok, and force it to go back to the setting I wanted.

3)When I click the Window-close button, I *really* mean "Exit the program". If Amarok wants to go to the system tray, it may do so using the *minimise* button.

by mactalla (not verified)

What you're asking for in 1) and 2) should be addressed very nicely in Amarok2 thanks to Phonon. See http://dot.kde.org/1170773239/ for some more information about Phonon.

by Ian Monroe (not verified)

Yea 1 and 2 are really xine issues or ones specific to our xine engine.

3, just turn off the systray.

by Henk (not verified)

Another solution configuring another sound device is editing the configuration manually. In the file ~/.kde/share/apps/amarok/xine-config I found two lines which I changed to (do edit only when Amarok is NOT running!):
audio.device.oss_device_number:1
audio.device.oss_mixer_number:1
and this makes OSS to use /dev/dsp1 instead of /dev/dsp.

You can also use ALSA instead of OSS as output plugin. First change and apply this in the configuration and then go down into the details and set mono and stereo to hw:1,0 (may depend on what you find in /proc/asound/cards and /proc/asound/devices).
You will now find the lines
audio.device.alsa_default_device:hw:1,0
audio.device.alsa_front_device:hw:1,0
in ~/.kde/share/apps/amarok/xine-config but manual editing is not needed.

This also shows that a lot of inside information is needed (I hope I do understand the hierarchy rightly that Amarok uses Xine (or some other) and that Xine uses OSS or ALSA (or some other). This may be a bit to much for the avarage end-user.

Now after all this configuring I still agree with you that a simple change of output device should be facilitated. After all when I want to use a different printer I don't have to reconfigure CUPS, I just choose one of a list of availlables.

I don't agree with Ian Monroe that this to be done in Xine. It is in an Amarok configuration file and Amarok calls Xine with these parameters. Kaffeine and others have their own Xine parameters. There does not seem to be a central Xine configuration file. Maybe there should be. I had to invent this configuring for four or five players (and couldn't solve all of them).

by Kevin Kofler (not verified)

> There does not seem to be a central Xine configuration file. Maybe there
> should be.

There will be with Phonon-xine. :-)

by Henk (not verified)

Nice! Even if only KDE applications will use it (and not e.g. MPlayer and Realplayer) this will be an improvement. :-)

When you read my earlier post you will not be surprised that I hope it will be possible to change the sound device to be used in an user friendly way. One moment I want to listen to music in my office from my local PC speakers. An hour later I want to listen with my wife to internet radio in the living room via my Xitel HiFi-Link (and it's long cable to my home stereo). That change should be possible in not more than say two clicks.

by Kevin Kofler (not verified)

MPlayer and RealPlayer don't even use Xine, so of course they can't share a Xine configuration.

I believe there are plans to use Phonon (rather than xine-lib directly) in future versions of Kaffeine, which should handle the need for a Phonon-using video player.

As for codecs, xine-lib (and thus Phonon-xine) should be able to load essentially everything MPlayer can, which also includes RealPlayer's proprietary codecs (though AFAIK using them this way is not exactly compliant with their EULA).

by Henk (not verified)

Thanks for all the explanations. I try to grep all of this.

What I am missing in this case is knowledge. Until now I could not find an overview of how all these parts fit together. Who uses what. What is used by whom. What is are alternatives. And what do all the parts do.

When anybody can refer me to a source of information I would be grateful.

by Arne Babenhause... (not verified)

Hi,

My reason for having many tracks in the main playlist isn't that I need all of them in there, but that management of the non-smart playlists isn't that nice and I want to be able to reorganice my playlists.

For example I'd love to see the option to show a playlist in the main window, so i can work on it. Or to have them in a format, where I can better work with them, especially with long ones.

And the option to generate a dynamic playlist for a static playlist on the fly...

And besides: I queue up tracks quite often, for example when chaning the dynamic playlist:

"I want to listen to political songs, but before that I want to hear those three songs from my filk-collection" is then simply: "Queue up the three songs and switch the dynamic playlist."

But most important: Thank you for Amarok! It is great!

by Nikolaj Hald Nielsen (not verified)

>> 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. <<

Jamendo support is coming along very well (It is the service I have been using a s a testbed for the new service framework). Claiming that we have basic support for Oboe locker might be stretching it a little at this point, but it is definately one of the things I will be looking into, right after the Magnatune store has been brought back to life in the new framework.... :-)

Also, some more interesting (and often requested) features might make its way into the Magnatune store, see http://amarok.kde.org/blog/archives/411-Meeting-up-with-Magnatune.html . All I need is some more free time!!! :-)

by Christian (not verified)

This is Unix and a headless/command line collection scanner with
the ability to feed the database is needed.

Many people use fileservers and the server itself is the natural
machine to run the collection scanner. Nowadays you have to launch X11
in order to be able to do that.

A headless collection scanner would take away a lot of pain.

Otherwise, a very nice player.

Christian

by Nikolaj Hald Nielsen (not verified)

The collection scanner is already a separate program called "amarokcollectionscanner" which can be run directly from the command line

by Mootjes (not verified)

From what I'm reading, I have the impression Amarok developers are currently trying to optimise the GUI in an innovative way. Personally, I'm not entirely keen on the disencouragement of long playlists, or the abolishment of the queue-function (ok, apparently it wasn't meant this way). But I'd like to suggest a new GUI-approach.

It is the combination of 2 main frames:
- One frame including the entire database (or a part of it) of your music (left or up)
- a 2nd frame which is the current playlist (right or down)

You can click the 'random' button on the first frame to listen to random tracks from your entire database, then in the 2nd frame an entry 'random - collection' appears

Or you can select songs from your 1st frame, and add them to the playlist(2nd frame).

What do you guys think?

by michael (not verified)

I think the big problem with palylists is that we are mixing two different things:

1. the last x, the currently playing and the next y songs
2. a potentially large list of songs that can easily be modified and stored

I think the two need a different UI. It should then be possible to use 2. as a source for 1., manual and/or automatic (random/sequence).

by dthacker (not verified)

I'm not quite sure if I understood Jeff correctly but I think one of my favorite features is going to disappear. I usually run the library on random favoring least recently played, but sometimes when one of favorites comes up, I want to hear a couple more tracks. So I queue up 2 or 3 by that artist and then let it go back to random. I'm hoping I can still do that.

dthacker (who will scrobble his 10,000th play to last.fm this month. Thanks Amarok devs!)

by Amara Emerson (not verified)

Earlier in the comments, Jeff said that it was not final, and it they did cut it, it would only be because they found a better solution.

by anonymous (not verified)

because they want to install another Filemanager if bash, MC, Thunar, Rox.. is enough in a Window Manager only system with GTK and Qt installed?

We prefer even Gnome-less programs. Why should we install another VFS (KIO, Gnome-VFS) if we have Fuse?

Please remove KDE-libs from Amarok 2.0. Hopefully, K3b goes the same way. Even better: structure the code to compile a non-KDE system and everyone will be happy! A lot of people doesn't need KDE integration.

Thanks a lot!

by Robert Bill (not verified)

I've suggested to integrate soundtouch functions (pitch-independent song stretch) into Amarok but this has been refused because of it becoming possible only with Phonon. Now in Amarok 2 there should be Phonon so I would wish to have soundtouch integration.

by viktor (not verified)

actually i never really understood the meaning of the contextbrowser. I think amarok is a music player and browser. I'm not interested in what amarok thinks are my favourite tracks or how many times i have played them. I'm not saying such features shouldn't be there, but i just cant understand why they should be prioritzed over playing and organizing my music, which again is what i think amarok is for.

I would love for the collection to take center stage more. For example using the new klistview.

by Jesvin (not verified)

Hi

Just some features I would love to see integrated:

1 A lot of my mp3 files are boosted: ie on the viz the lower freqs go over the roof but other freqs barely get up the floor. This is a problem for those who use lo-end speakers. Img as example:
http://img2.freeimagehosting.net/image.php?7676096e3a.png
I would love a default feature to identify the songs and correct the gain.

2 An equilizer that sets itself to the genre of the song WITH ability to set presets to genres ( such as setting RnB->full bass+treble and pop->party.

3 The append to playlist should position to play the song Immediately After the current item.

4 a components list whether features (musicbrainz-mp3, songalizer, ipodlib) are installed.

5 An export feature for amarok information like rating and such. Right now i always cross my fingers before pasting back .amarok during a new install

6 Ability to rate /problability-favor(in random mode) /set INITIAL score by looking up the songs in last.fm. Useful for those who have discographies of unfamiliar artists (like me :-) ).

7 Cached album art/ lyrics should be copied to their folder/ file by default.

8 A kicker applet with ability to set ratings, scroll, album-art and vizulizations. Something on the lines of kirocker:
http://www.kde-apps.org/content/show.php/Kirocker+Music+Display?content=...
Hey windows media player has one already :-)

9 Fade in/out on pause. allow this to be set fade time separately from start/stop fade. Also There is the annoyace that plays the fade out of the prevois song even though I JUST Started.

10 Themable mouseover tooltips. Yellow is a bore. And dont get it to display ALL the tags on the window. And it has a top-heavy look not acceptable for somthing that jumps out of a panel ;-)

11. "score-84% star-4 stars". Can we have graphical representation for the same in OSD and tooltip?

12 Sync info between 2 amaroks between 2 computers or even 2 OSes on the same computer from an online source and ability to check if other computers have acknowledged the the change. (AAAAAAHHHH-MUST-STOP-IMAGINING-UP-A-KDELIVE!-WEBSITE-phew!!!).

13 Since last.fm requires 15 songs from differnt artistes it would be nice for amarok to set the playlists itself. Im not sure if this is violates last.fm TOS

So this is my lucky 13 ;-) im not sure if some of them are being implemanted yet but i felt i have to post them. Thanks

by rednow (not verified)

I don't understand point about dynamic collection. About 70% of my collection (as defined in settings > collection) is on auto mounted NFS drives all over my network. If starting amarok and even one of those nodes is down, amarok takes half an hour to load, and any action (or attempt of action) after painfull startup freezes amarok or even crashes it.

BTW there are very similar simptoms if my machine, that holds the actual SQL collection data, is down. Can't there be some kind of exception, let it stop trying after a N seconds/minutes (in both cases), warn the user and simply continue to run, and run *stable*.

This is my first writing here, I just want to say thank you. I've been using this great player from the start, and with all it's quirks and gotchas it's stil by far the best music player around no matter of what OS or platform we're talking about.