Summer in the northern hemisphere is not an easy time for the Amarok team, 35°C in the shade is definitely not the ideal operating temperature for most hackers. Nevertheless, work on our Google Summer of Code projects and regular Amarok development is proceeding at a frantic pace.
GSoC projects won’t be merged and released until later, so what we are releasing right now is a beta release of what we have cooked up during the spring, including the Amarok sprint in Randa, Switzerland.
Prominent changes include several redesigned user interface elements and dynamic playlists, and a significant number of bug fixes.
When the Google Summer of Code program was announced again this year I decided to submit a proposal for a project that would hopefully take Amarok in a new and interesting direction.
My proposal was accepted, so this year I’m a GSoC student again, for my third time, working on an Amarok port for mobile devices, primarily tablets.
Why mobile? In the past few years some profound changes have been set in motion in the computing market. What we still call “desktops” might soon become mostly workstations and gamer rigs. We’re not there yet, but computers are already becoming increasingly mobile, invisible and wearable, and computing is becoming ubiquitous. In this changing environment, complex desktop apps like Amarok 2.x will have a harder time staying relevant, and are being challenged by leaner, simpler and flashier mobile counterparts.
Amarok has a strong brand and a good reputation as the ultimate music player for GNU/Linux systems, prominent features where Amarok innovates and excels are web services integration and smart context-sensitive information. I believe the Amarok team can take advantage of that and make a successful entry into mobile markets.
There is certainly a lot of work involved: the existing GUI simply would not work well on touch screen devices, and a lot of the underlying stuff is also not so well suited for a mobile app because it provides a very extensive feature set and requires a lot of dependencies.
The foundations for a mobile version were laid down about a year ago, when Amarok developer (and my GSoC mentor) Jeff Mitchell made some deep changes to separate Amarok’s core logic from “everything else”, including collections, the user interface, etc. However, not much happened after that besides maintaining this separation, so I simply figured that if we indeed want to see Amarok running on tablets and handsets the actual porting work had to begin.
So what am I aiming for? At this point, a platform that is accessible almost immediately is MeeGo (and Maemo 6), represented by the upcoming Nokia N900 successor and Intel x86 based tablets, as well as devices which come with other operating systems out of the box but have a MeeGo port. While during this GSoC project I’m focusing on MeeGo, when making technical decisions I will be taking into account their impact on possible future ports to other platforms.
This port will require a completely new GUI, but since I’m not a QML GUI designer (yet), so far I’m only promising to deliver the underlying stuff.
Until now, I’ve done a bit of work on yanking out Amarok’s core and building it with a minimal set of dependencies, and setting up a MeeGo development environment. The next step will be porting this core to MeeGo, and then building the required functionality on top of it while keeping the whole app light but smart
Building on the foundations of a fun and innovating 2.4 release, the Amarok team is proud to announce the immediate availability of Amarok 2.4.1, codename “Resolution”, the first maintenance release of the 2.4.x branch.
Many bugs have been fixed, and we even managed to sneak in a few new features, including remote NFS/CIFS collections and a gpodder.net service.
Check out the full release announcement here to see what’s new in this release.
Hot on the heels of a great 2.4.0 release, the Amarok team is proud to announce the immediate availability of Amarok 2.4.1 Beta 1, codename “Ringscape”.
Aside from the usual load of bug fixes, this beta release brings several new features, such as a new preview mode for the Organize Collection dialog, integration with the gpodder.net web service and remote NFS and SMB collections.
This is a beta release, which means that although it’s quite usable for daily use, it might still contain serious issues, eat your chocolate brownies, melt your ice cream or set your microwave on fire. Read the full announcement here and if you wish to help us make Amarok 2.4.1 even better, please report any new bugs you encounter at bugs.kde.org.
I’ve been asked by Lydia, the ultimate social media ninja of KDE and Amarok’s community manager to put together a brief post about my opinions on the importance of mentorship and organization in a student outreach program such as Google Summer of Code based on my experience as a GSoC student. I’ve been a GSoC student twice and a volunteer Summer of KDE student the year before that, so I hope I can provide some insight from a student’s point of view. The KDE GSoC admins&mentors team has done a terrific job so far, and I’m very satisfied with their performance. Thank you, GSoC admins&mentors!
I have tried to gather a list of situations where as a GSoC student I could greatly benefit from good mentorship:
- Planning. While I surely did have a vision and a somewhat clear direction where I wanted to take my project, I wasn’t always sure about the details of the implementation, and specifically how and where to tie my stuff in with the existing codebase. My mentor helped me a lot with planning and design, and we shared a design document in Google Docs that was to be kept up to date for the duration of the GSoC program. I believe that while the strong motivation of a student pushes the project forward, the direction has to be overseen and frequently discussed with the mentor to make the student’s project useful for the organization and to avoid rookie mistakes when laying out the design.
- Code review. When I started with GSoC I was very much a noob about Qt and I didn’t have a lot of coding experience. Regular code review by my mentor and the other team members was very important to improve the quality of my output. I believe that at least occasional code reviews in the first weeks of the GSoC program (unrelated to the final review before merging the branch) can straighten out important details before they become serious issues later on.
- Team interaction. When I started with GSoC I didn’t know anybody in the Amarok team. I didn’t know anything about the social structure and most importantly, I didn’t know which team member I should poke about specific parts of the codebase. In those times it was very important for me to have someone (mentor, community manager) to ask questions such as “Who has knowledge about this bit of code? Can I make change X on code Y or would that make person Z angry?”. I did ask those questions pretty often.
- Technical questions. The life of a GSoC student can be pretty intense, between coursework, exams and coding. For this reason, while my output was quite consistent, coding could happen at any time of the day. I’m very grateful that my mentor Nikolaj Hald Nielsen was almost always available to answer my questions, and when he wasn’t, there was a clearly appointed second-in-command I could go to. This is perhaps the most important entry in this list. Rules such as “the whole team will mentor you” or “ask in the IRC channel and someone will answer” just won’t do with first time students! I know I wasn’t very comfortable with asking just any question in IRC, especially if I felt that the answer could be something that “anybody ought to know”. Sometimes I just needed a confirmation to make sure I was doing the right thing.
To sum it up, I believe that KDE has a great admins&mentors team, and I can testify that also because of this doing GSoC for KDE was a very rewarding experience.
However, it has come to my attention (also during this year’s Google Code-in) that for the fairly small admins&mentors team a large scale student outreach program such as GSoC creates a huge workload.
KDE contributors are encouraged to help with the organization to make the recently announced GSoC 2011 the most successful GSoC ever: feel free to add your ideas to our GSoC 2011 ideas page, and if there’s an area of KDE you know well, why not be a mentor this year?
The KDE GSoC team is looking for good mentors with lots of cool ideas, and especially if you’re a former GSoC student and you’re not a student any more, you might be the perfect candidate to become a GSoC 2011 mentor. To apply as a mentor visit #kde-soc on Freenode.
On behalf of the Amarok team I’m pleased to announce that Amarok 2.4 codename “Slipstream” has just been released.
This release finally brings some of the Google Summer of Code stuff we have been blogging about a few months ago, many new features, as well as many performance and usability improvements. We are especially proud of the new, completely rewritten and much more reliable collection scanner, and I’m personally very happy to be able to show/hide the menu bar again
Check out our release announcement to learn what we’ve been up to for the past few months.
Unsurprisingly, this fall has been a busy time for the Amarok squad: we had several heaps of code to merge from this year’s Google Summer of Code projects, and we cooked up lots of new features. All the stuff that our GSoC students blogged about months ago and much more will finally be released in January 2011 in Amarok 2.4.
But first, to make Amarok 2.4 rock-solid we would like to ask you, our users, for some help.
We have just released Amarok 2.4 Beta 1, codename “Closer”. In the hope that this release brings us all closer to creating the perfect music player, get it, play with it, test it, and if you find something that needs to be fixed please do send us bug reports at bugs.kde.org.
If the next few weeks are holidays for you, the Amarok team wishes you a happy holiday season!
While lots of new features are still pouring in from this year’s Google Summer of Code projects, it will take us a while to make sure they don’t crash and burn and hopefully release them some time later this fall. In the meantime, why don’t you help us weed out some bugs to make Amarok 2.3.2 the rock solid release we would like it to be?
To make the task easier, we have deployed a sentinel to look out for bugs: Amarok 2.3.2 Beta 1, codename “Sentinel” is out.
Since the last release in the 2.3 series the Amarok team has been working through the laziest days of summer to implement very much needed fixes, changes and even some new features, especially concerning filtering and podcasts. Read the full announcement here and don’t forget that to make Amarok 2.3.2 even better, bugs.kde.org is the place to be
It’s been GSoC season for over a month now and I haven’t blogged, so now I’m going to try to fix that. After last year’s Multilevel playlist sorting project, one of my proposals has been accepted again for GSoC 2010: I’m going to implement on-the-fly transcoding in Amarok.
Amarok is a music player and manager built around very general concepts of tracks and media sources. The collection tries to decouple the format from the data itself and presents the music as tracks (with metadata) rather than files. In other cases, music isn’t even stored in local files. These concepts, and others, allow one to truly rediscover music through seamless internet sources and media devices integration, and the user in fact doesn’t have to care where the actual data comes from. The many sources at one’s fingertips are accessible in a consistent way and playable from the playlist.
However, even in this day and age of stuff in the cloud, there are situations in which the user still has to worry about media formats, e.g. when acquiring new music, or copying existing music from one collection to another or from the collection to a portable music player. That’s where transcoding kicks in.
For example, one might have a quantity of Windows Media Audio files that should be transcoded to a more Free format in order to be usable in the future, or a quantity of Monkey’s Audio files, which, while lossless, are not well supported everywhere, especially in PMPs. And then of course, even if someone has a collection full of FLAC files, which is a reliable and Free codec, a conversion into a lossy format such as Ogg Vorbis or MP3 might be necessary for use with a PMP simply for reasons of storage capacity.
So my idea is this: whenever the user can copy files, give him or her the choice to either just copy, just transcode or transcode with custom options. That way, we cover both of the following use cases:
- “I’m running late for a 4 hour train ride and I haven’t updated the music collection on my portable player, I need to quickly copy over my tunes while making sure they will compatible with the portable player”
- “if I tweak the quality rating of the Vorbis encoder exactly the way I want it I’m going to save 1% of the space on my portable music player and still get the audio quality my sensitive ears deserve”.
The current situation is that the transcoding operation (in the strictest possible sense) works, so the next thing I have to do is integrate it nicely with Amarok’s existing collections framework. The current implementation uses FFmpeg, but I’ve placed FFmpeg-specific stuff in a wrapper class so something else could quite easily be used in the future if need arises.
The following screenshot represents the current state of the still quite unfinished transcoding GUI.
On a somewhat unrelated note, I’ve been to the KDE Multimedia+Edu sprint in Randa, Switzerland.
It was a lot of fun and very productive too. I wish to thank the whole organizers team. Special thanks go to Mario Fux for his mad organizational skills, to the cooking team which I had the pleasure to share the kitchen with while preparing vegan stuff and to Knut Yrvin for arranging a much needed meeting with the Brisbane office of Nokia, Qt Development Frameworks regarding QtMultimedia and the future of Phonon. Finally, thanks Anne-Marie Mahfouf for a gift she gave me which allowed me to taste again something I like very much but haven’t been able to eat because of nickel allergy.
Amarok 2.3.0 has just been released but the Amarok team is already working hard on the next release. Shortly after mainline opened for feature commits I pushed a feature that will hopefully result in the next Amarok release being based on user feedback even more than 2.3.0: LikeBack integration.
What is LikeBack?
Short answer: a client-server system for gathering context-related, anonymous and immediate user feedback.
Long answer: described in a blog post by Valerio Pilo, KMess developer.
Pics worth more than 1K words (hint: the icons in the top right corner):
In Amarok the LikeBack bar is enabled by default only for testing releases i.e. git builds and betas. When the user has a good or bad experience, or gets an idea for a feature, he can click on one of the icons in the top right and submit a message. With LikeBack we gather comments of the types “like” “dislike” and “feature idea”, single and short suggestions, not discussions or bug reports. Bugs are still handled through the usual dialog that takes the user to bugs.kde.org, a system much better suited for bug tracking than LikeBack: this also means that if we receive something like a bug report under the guise of a “dislike” through LikeBack, we will have to consider it invalid.
The feedback we have received so far (several dozen comments in half a week) is quite positive, no insults yet (yay!).
LikeBack is available in Amarok’s git mainline (and in git/nightly builds if your distro provides them) as of a few days ago (*not* in the 2.3.0 release), so feel free to give it a spin and let us know what you think, either through LikeBack or the usual channels.