This week we'll take a brief look at some of the many features that are making their way into Amarok 2, which is the development branch for Amarok in KDE 4. The features discussed are all in-progress features which have reached varying stages of completion. Read on for information about Amarok's engines (including Phonon), UI changes, changes to the Magnatune music store, OS X support, and more.
A few weeks ago, The Road to KDE 4 featured an article on Phonon. When that article was published, work on Amarok 2 had not yet started, but the Phonon developers were keeping Amarok very much in mind as they designed the Phonon libraries.
You see, in Amarok 1.x, the developers had to maintain separate playback engines for xine, gstreamer, aKode, etc. This was somewhat of a hassle to keep all of these engines up to date, and in some cases, they were very much a moving target, forcing them to focus on only a single engine, xine. And other programs, like Noatun had to re-implement these backends so there was much duplication of efforts. For KDE 4, the Phonon interface is designed so that programs like Amarok don't have to worry so much about the backends anymore and can concentrate on the other parts of the application. According to the Amarok developers, implementing a Phonon backend took all of 90 minutes before it was usable, and a few extra hours before it was fully implemented. When using Phonon, applications can playfiles over network protocols thanks to KIO, so we'll see what happens as the Amarok team explores this feature in more detail.
So Phonon is now working in Amarok 2. The old engines were also ported over, and in particular, the old xine engine is still being actively developed and they haven't decided to drop their old engines. Since Amarok 2 has only been in development for a few weeks, it is too early to decide to drop their existing engines such as xine, which has served Amarok very well in the past.
One of the side effects of using Phonon is that Amarok can access the video playback functions of the underlying engines where they exist, such as in the phonon-xine engine. They have added rudimentary support for video playback in Amarok, but it's designed to complement audio playback, rather than supplant more involved video players like Kaffeine. The idea is that if you have a music video in your collection, and want to use Amarok to play music from that video, then the video stream would be considered as a Visualization for that music. Having video support will in no way hinder your Amarok audio experience in version 2. According to Dan Meltzer, adding initial video support was a whole seven lines of code using Phonon.
Of course, thanks to KDE 4's newfound portability, Amarok is able to run on other platforms, not just Unix/X11. The development version has already made its first appearance on OS X thanks to the work of Benjamin Reed. Porting to Windows as well is underway, although I don't have a screenshot of that progress.
I personally think that having Amarok on these platforms will single-handedly do more for awareness of KDE as a multi-OS development platform than any other application that currently exists for KDE, since the program is head and shoulders above so many other media players out there.
But they wouldn't have a good reason to call it 2.0 unless there were some really big changes happening, and there are.
Amarok is in many ways inspired by XMMS, which in turn bears a lot of resemblance to Winamp. Basically, it's a music player with a multi-column playlist that displays information from tags contained within the media files. Now, these multi-column playlists have not really changed much over the last decade, except that different applications have added interesting ways to sort, filter, and edit tags. Amarok is particularly good at sorting and filtering, and half decent at tag editing (see JuK as an example of a player with an amazing tag editor). But none of these functions really require Amarok to present its playlist in a rigid column format, except for traditional reasons. So as part of the UI reworking for Amarok 2, the playlist is seeing a rebirth of sorts. While it still lists Tracks, Titles, and other tags, it will no longer be constrained by the old fashioned playlist column format.
This requires a picture to properly describe, so here is a mockup showing the concept in action.
You may first wonder "Where is the playlist?" as I and a few of my peers on IRC initially wondered, but if you look closely, the list on the right is actually the playlist, only it's broken free from its old format. So now, when your file is missing some tags, the playlist will simply adjust around those missing tags, smartly displaying what information it does have.
Also featured prominently in this screenshot is the middle pane. This pane is the focus of Amarok 2, as they try to give you more information about your current track, and allowing you to "Rediscover Your Music" as their motto goes. The leftmost column will function much as it used to, except with the "Context" information moved to the centre. Of course, as is KDE tradition, much of this will be configurable.
Here is a shot of Amarok 1.4.5 showing its current layout for comparison as well as a shot of the development branch of Amarok showing off some of the progress they've made in moving user interface elements around. The mockup above is the targeted UI they wish to achieve, but there will be bumps and changes along the way as they find what does and does not work well.
And now another screen the Amarok 2.0 development version, this time on Linux. Keep in mind that Amarok 2 has only been in development for a single month, and work is still ongoing.
One of the most promising of Amarok's features is Magnatune store integration. According to Wikipedia: Magnatune is an independent record label which aims at treating both its musicians and its customers fairly. Users can stream and download music in MP3 format without charge before making a decision whether tobuy or not. Music files sold by Magnatune do not use any form of Digital Rights Management to prevent customers from making copies of music files they have purchased; and actually encourage buyers to share up to three copies with friends.
Amarok debuted with Magnatune support (for both audio streaming and purchase) in version 1.4.4. Since then, the team has received many emails from other stores interested in being added to Amarok as well. But in Amarok 1.4, the developers have been busy polishing up Magnatune support and had no manpower to start bigger tasks. With Amarok 1.4.5, the second version of the Magnatune store was released and developers are really pleased with that version. It works well, and generates a small but growing number of sales for Magnatune.
So it is time to move on. Nikolaj Hald Nielsen, the main developer of Magnatune store, is planning to move things up a higher level by providing a service framework for all streaming music sources. This service framework could, and is in part intended to, be used as a starting point for adding other stores, and will provide a large amount of basic functionality with regards to adding previews to the playlist, displaying data about selected items, and similar "read only" functionality. As a prof of concept, a service that can be controlled using scripts have been implemented on top of this framework. Currently there is no intent to make a framework for the more store specific functionality (purchasing, parsing of info from websites), simply because each store has their own unique way of handling these things. Nevertheless, it's a great step forward for unified streamed music support in Amarok, and in fact, the CoolStreams service has been already ported to this new framework (as a rubyscript), and a Shoutcast browser is coming along.
Now, with the Magnatune store well received and with the possibility of using the service framework, it might be time to contact some of these interested music stores again.
Here is a screenshot showing the experimental "Cool Streams" ruby script running on top of the scriptable service:
If you'd like to get involved in the Amarok 2 development process, you will need to set up a KDE 4 development environment. There are instructions for using SVN available at the KDE TechBase website, or use the kdesvn-build program to automate the whole thing. The Amarok developers accept patches, and will hook you up with SVN access if you require it. They also need help from artists, testers, and people to offer user support via the #amarok IRC channel on the freenode network.
Ladies and Gentlemen, Amarok 2 is progressing very rapidly. To quote Mark Kretschmann, Amarok's lead developer: "If development continues at this pace, we'll be done with Amarok 3 by the time KDE 4 is out ;)" Be prepared for something awesome, as you've come to expect from the Amarok team.
To stay up to date with Amarok news, check out the Amarok Newsletter published by Ljubomir Simin. Special thanks for his contributions to this article. It's my first experience co-authoring, and it went very smoothly. :)
That mockup doesent really look so good to me, but ofcourse i havent tried it, and the amarok developers has previously created awesome stuff, so it cant really be decided untill the product is on the table, and at that time i will give it a full go as it deserves, and i probably will end up like it, as with the current amarok.
Developers: Don't listen to all the GUI whiners! Amarok is the sweetest music player I've ever encountered, and I fully trust you guys/gals will do a great job with Amarok 2.
My only request is that you keep improving the ability to sync with portable media devices. I love the on-the-fly file type conversion, and would like to have more control over that. My MP3 player is only 1 GB, and since I mostly listen to it while I exercise, I'd like it if Amarok could re-encode the files to smaller file sizes when it transfers them to my music player. The treadmill lowers the sound quality anyway, and I could definately do with fitting more songs on it!
Now what exactly do you want? Amarok already can transcode files (install and run the transcode script, then check the settings for devices).
I'm only taking the time to post because I see so much negative feedback. I liked the mockup, but moreover I like the pace and enthusiasm with which Amarok has been developed. You haven't dissapointed me so far so I'm more than happy to put my trust in you :D
I second this!
It sounds like there are 2 main groups of people here commenting.
One uses the context browser and loves the new UI.
The other doesn't use it and hates the new UI.
I think just making the panes collapsible would get rid of a lot of the complaints.
So what you're saying is have it exactly how it is now?
Amarok, in my opinion, is a good player cause it's simply bloody good at playing music. A simple idea that other music players don't seem to get. The playlist is the music, the screenshot of the album cover isn't the music. I don't get why the context menu (which doesn't really have all that much to do with choosing the music to play at all) would get precedence over the playlist. People who are glowing over the new idea seem to be too concentrated on having it look good and are forgetting that Amarok should be centred around one function - playing music.
While I really love this "Road to..." series, it sure does stir up a lot of premature discontent. It seems that each week, the writers add more and more preemptive "this is pre-alpha" warnings, but the negative comments just keep piling up. I hope nobody gets discouraged by all the negativity. I love being able to read these great articles to get insight into the development process, but the negative responses are overwhelming. I wouldn't start belly-aching until release is a little closer.
I think people are reacting like that because of that particuler comment :
Nope, that's a no-go. I'm convinced that the context view needs to be in the center. It's the context information that we want to emphasize in 2.0. The playlist is just a tool.
Also it simply wouldn't look as good.
Coming from a team member, it sounds scary. It could be interpreted as (beware, troll inside) a really GNOME-ish attitude : I think it is, I make the stuff, you just follow.
But don't get people wrong. If they are reacting like that, it's just because they love Amarok and they want it to fit their needs. And as said above, it appears that they are two groups of people. And none of them wants to be left behind because of the implementation. It's not a flamewar, it's just people trying to defend their point of view, and debates are always good. It's better to react now while it's still alpha than later when it's final version, don't you think ?
I think the developers got the point of that debate : adaptability. Amarok should definitely be able to be configured at will. Let's see now what's gonna happen. I trust them, they'll do their best, as usual.
You make a good point, but voicing a concern is much different than blasting out derrogatory remarks. I'm sure coherent, meaningful debate is appreciated to some extent, but words like "sucks" and "hate" will not help anyone. There are way too many of the latter.
It tells the developers that there is a want among the users for being able to customise the GUI, potentially back to the 1.x version. Usefull information no?
no. that information is not useful. With most of the changes we plan to make it would require maintaining two sets of code to give the option. We are changing the way the context works and acts, the way the playlist works and acts. To give an option of switching back would require we maintain the current code as well as the new code, and no one wants that headache.
The 'two sets of code' you're talking about should be rather minimal presuming you're using good OO techniques and abstract your GUI from the rest of Amarok. Actually if its done right you could probably swap with any theme you wanted to presuming they adhered to the api you defined, and these could be designed and maintained by any user with an understanding of C++, QT, and Amarok.
Might I suggest spending a little time focusing on stability? Unfortunately, I've always found amarok to be one of the most unstable programs I have - it almost never runs for longer than a day, and often crashes within an hour. This is and has been true in various releases over the last 2 years, including the latest. It's a shame, because it's the best music library interface available - but I wish I could use something like sox or xmms to actually handle the playback.
Never seen amarok crashing, and i use amarok for several years now.
Did you file bug reports about the crashes?
I don't get it either. I have heard many people complain about the stability of Amarok, but even if I used SVN the most time it crashed very rarely here.
I had stability issues on some old release (1.2? 1.3?) But it's been quite a long time since I've seen Amarok die on me. So long I had forgotten about it :)
Unfortunately I have to agree.
It used to be very stable for me, but, IIRC, from about mid through the 1.3 branch, stability has gone out the window.
The new features and general usability have all been fantastic. No other player comes close in those regards, IMHO.
But increased instability and little bugs like killing the podcast download before it was finished and thereby cropping the last few seconds of the podcast, eroded my confidence in Amarok (and, I'm afraid, also in the development team itself) to such a degree I simply stopped using it.
If the bugs were ironed out, I'd never use another PC music player.
I've never found another player I liked as much, so I may end up writing my own player with the features I want.
That does seem like a waste of time, but debugging a codebase the size of, and with as many apparent bugs as Amarok's, and one I'm not familiar with at that, would likely take longer than I'd be prepared to invest.
I've not noticed any major stability problems with 1.4.x, but perhaps we're using different audio backends. I'm using the xine backend, which one are you using? Have you reported the bugs you have found?
> I may end up writing my own player with the features I want.
> That does seem like a waste of time, but debugging a codebase
> the size of, and with as many apparent bugs as Amarok's, and
> one I'm not familiar with at that, would likely take longer
> than I'd be prepared to invest.
If you're thinking that you can create your own player with Amarok's capabilities from scratch in less time than you could fix a few issues in pre-existing code, then you're probably fooling yourself.
I use Xine too. And, IIRC, I did let it send off a few crash reports.
If I thought I could develop my own player from scratch with all Amarok's features in less time than I could debug Amarok itself, I probably would be fooling myself.
But I wouldn't be developing it in a vacuum. I could rip the visual layout ideas from Amarok, and I could take code snippets from all over the place (Amarok, Juk, etc.) and stick them into my own framework.
Besides, I'd only want to replicate a relatively small subset of Amarok's features. For things like handling my iPod, GtkPod (that and Gimp are the only Gtk programs I use) is much better anyway. It's just that the subset of Amarok's features I do use, I can't find as well implemented, from a usability perspective, anywhere else.
Also, when I read what the problem was that had caused the ends of podcasts to be cropped, I couldn't help thinking it sounded like some of Amarok's internal design was rather flawed. Or at least totally incompatible with how I would want to do it.
I might well have been mistaken, but it made me not even want to bother taking a look. Working with a codebase that would have me grinding my teeth would not speed up my efforts. :-)
Not that Amarok are in any way unique in rushing to stick more and more features in, and skimping on basic quality assurance along the way. The obvious bugs I came across in the Linux kernel's atkbd.c driver a couple of years ago, gave me one hell of a fright. That was worse than anything I expect to find in Amarok. I seriously considered switching to some BSD variant after that. It certainly tainted the development process of the 2.6 tree in my eyes.
The new Amarok release is looking excellent, and I really like that mockup! Great work- Amarok is one of the best apps I've ever used, and I'm sure it'll get even better with the 2.0 release.
Seriously, we didnt like it.
Lets see if the developers of amarok will be sensible enough to NOT go into this path...
And if its already changed, please do like when they tried to chaneg the browser position to horizontal (wtf) and they've reverted some versions back in the svn.... PLEASE, I beg ya
happy (until now) amarok user
We dooon't like it, my preccioussss...
Who are "we"? Sure, there are many that don't like the mockup, but how can you tell that you don't like the actual product when you haven't even tried it - or so I suppose?
And instead of just complaining about how "we" don't like it, why not point out which parts of the mockup and maybe how to improve it? Or is the old way the only way to go?
For the GUI I would say, looks lovely. I am glad to hear that Phonon works out so good for you already. Lets hope Amarokers will push the limit of Phonon-xine to what they had in Amarok-xine already, that would cover one of the backends already quite fine.
Also, reading this stuff, to me this reads like Amarok could kill DRM only shops by the way of making us get to know fairly traded music. That would be your even higher achievement. So yes, push ahead, get Windows versions out there, go to the masses and liberate them of those who hold them hostage with Britney Spears remakes.
Hey what's wrong with Britney Spears remakes ?!
What for i need "now playing" http://static.kdenews.org/content/the-road-to-kde-4/vol12_4x_amarok.png
at the center of the screen that occupies 70% of the screen?! Do you think users are so stupid that cannot understand that highlighted line in playlist is playing?!
Also why did you move buttons to the up left? Is it for mac users? Dont you think amarok is mostly linux player.
Users need to listen the music and not to "rediscover" how to disable unused features.
its a mockup :)
No, its not a mockup. The only mockup in the images is the one that looks completely different (the blue toolbar and redone playlist.) The rest are actual screenshots of what Amarok looks like right now.
Really? Even if the devs are amazing, I don't think they've come this far yet...
And you can thank Dan for it all...
Could somebody fix the layout of this page (and any similar pages) so it doesn't require a super-wide display? Right now a horizontal scrollbar appears when I narrow the Konqueror window to less than 1200 pixels, which is ridiculous! The main article body lines get truncated at about 1000 pixels. If I enlarge the font, it is even worse!
Please keep the old UI! At least make it an option among different layout styles in user preferences.
This article puts forward the idea that Amarok merely copies the playlist style of XMMS/Winamp. That's true in the one-song-per-line sense, but Amarok goes beyond that by displaying way more information than the default XMMS/Winamp playlists ever did: Amarok gives you something more like a spreadsheet where you manipulate the widgets to get the playlist to display to your liking, including column order, sort order, and my favorite feature from recent releases, the highlighting of recently-added tracks. I LOVE that one. So I would say there's nothing "old" or "boring" or "due for change" in Amarok's playlist display. In fact, I think the current playlist format has quite a high information density, assuming all your music files have tag information.
As some others seemed be suggesting in not-so-many words, I agree that Amarok should be playlist-centric. I find three panes annoying, and they seem to stray from being playlist-centric. In the proposed layout, the amount of application real-estate the playlist takes up goes way down.
Totally agree. To compare Amarok's playlist with XMMS's playlist functionality is borderline despicable.
As I said in another thread, I think it's critical that Amarok play to its strengths, and an intuitive playlist (which is already has) is most definitely a strength.
As long as Amarok will not have a true gapless playing engine (as is available with the Crossfade plugin in XMMS), I will not be using it.
All the gizmos in Amarok are sure fine, but if it cannot do the most important thing - playing music and going track to trac without interruption, like is available on a CD player - then it's all for nothing,
it's had crossfade support for a long time.
The issue with crossfading it, Amarok doesn't detect, if tracks intertwine (proper english?). When I have an opus represented by N audio files, and Amarok puts gaps between them or crossfades, even though the tracks should be played directly one after the other, it sucks. I admit, while nice, such a detection isn't quite simple and the bug is more this information can't be embedded in id3 tags, to be read by the player, but still...
Gapless playing is a feature of the engine, not Amarok itself. If the engine supports it, we have it. So, what engine are you using?
It looks like there's a lot of commentary about the GUI. Well, count me on the "it's not broken, don't fix it" side. Really, I rarely if ever look at the GUI in Amarok. I interact with it using the media buttons on my keyboard. I *like* the iTunes-esque (not winamp-esque) interface.
If there's any GUI changes to make to Amarok, the article already points out what they are. For tag management, Juk currently blows Amarok away. I use Amarok as my player but still switch to Juk to do heavy duty refiling and updating. Simple things like the MusicBrainz integration in Juk are far better than Amarok's, which can waste time and lose data more often than not. Please, consider that a UI bug to fix before reinventing the interface.
Would it be possible to have Amarok 2 integrated with XBMC?
- controlling an XBOX MEDIA CENTER ala foxytunes
- streaming an MP3 to an XBMC
amarok is very good player, exept one - the sound! it sounds ugly, even with equalizers! do better sounding, i dont know how, and it will be the best!
In your engine configuration dialogue, make sure you are using the Xine engine, and have the Speaker Arrangement set to Passthrough. Also, the equaliser has been improved a LOT in 1.4.5 (so i've heard, don't use it myself), so if you're running 1.4.3 or earlier - please upgrade now! :)
Are there any plans for a "real" plugin infrastructure, not just dcop calls? Maybe with language bindings for Ruby/Python/Whateva?
you can already write scripts with ruby/python to create amarok plugins
No, we don't plan to implement an interface for external binary plugins. Binary plugins are only used internally. This is because with binaries you end up in binary incompatiblity hell when you're going cross platform. And it's already a problem on Linux with 32bit and 64bit issues.
Also, binary plugins that run in-process are always a stability risk. A bad plugin can crash the whole application.
Therefore we will only allow external plugins with scripting languages (Ruby and Python), just like it is now, but probably with more powerful interfaces.
I like amarok very much and this new version looks promising ;))
Keep up the good work ...
Like the quest for the "perfect" browser, I've long been seeking a powerful, flexible and consistant media player and organizer.
Having been told that Amarok is the best player around, I tried it, and fell in love with about 90% of it.
However, the single thing that made Amarok unusable for me was the "wonky" playlist setup. Creating a play list is simple enough, there's a few logical ways to do it. Where my issues come in with Amarok is that the player seems to believe when I click a song it should then be added to the playlist, rather than played in PLACE of the playlist.
This is so counter intuitive that I've pushed Amarok pretty far down on my list of "decent" players, instead resorting to Rhythmbox or (ug) Banshee.
Hopefully, with the rework of Amarok for KDE4, it will claim it's rightful place on my desktop. That is, if playlists make sense by then.
I like that feature, it makes it simple to create/extend playlists.
If i want to replace the whole playlist with one song, i rightclick on it and select that option.
I'm sorry but the functionality you propose is itself so counter-intuitive it is unreal.
Look at the word playlist. It's a _list_ of songs to _play_. If you want a player which will just play the song you click on automatically, erasing the rest of the current playlist in the process, then the whole point of a playlist is rendered incredibly moot.
Amarok, as well as "Rediscovering your music" through the use of the context panel, is very much playlist centered, it's one of it's strongest points, and thus the default actions for clicking on a song are very much justified.
First off, great work putting this stuff together in a semi-functional state so quickly. I love how it makes the context stand out and much more useful.
However, I always thought that the context would be most useful under the playlist, maybe with a 50/50 vertical layout. It would imply a very nice "Master/Details" relationship between them. It would also provide a nice fat area to display the context so one could fit a good album pic or lastfm style album collage. I usually have fairly short playlists and even if I have a long one, I'm only really conerned with the next 5 songs or so. Maybe some customization could be in order for window placement...
Granted, maybe I've just been working with too many database apps recently which have vertical master->detail relationships, but this screenshot is the first I've seen where the details are to the left of the master... usually for hoizontal layout it's to the right.
Good work so far,