Aaron Bockover

Two weeks to the day after the fantastic Alpha 2 release, I’m pleased to announce our third and most spectacular release, quickly leading up to the final Banshee 1.0.

• View the release notes
• Banshee 1.0 Alpha 3 Source
• openSUSE 10.3 users:
  
• Foresight 2.0 users: Use PackageKit or Conary to install banshee-1

Introducing Hardware Support

I landed my new hardware layer in Banshee’s core just a few days after the Alpha 2 release. This layer allows us to interact with hardware in a platform agnostic manner. Currently we’ve only implemented a HAL backend, but this separation layer should make it relatively easy to implement Windows and OS X hardware support. We’re only focused on supporting the kinds of hardware that we’ll need to handle in Banshee of course - this layer is by no means a general solution to platform agnostic hardware support.

So what kinds of hardware do we support?

Audio CD Playback and Ripping

Alpha 3 builds on the new hardware layer by adding full audio CD playback and ripping. We are now using Scott’s new managed MusicBrainz library which uses the new XML protocol from MusicBrainz.

Because of this, we can now store a slew of extra metadata in the database and directly in the ripped files as read from MusicBrainz, including the full album release date, the track artist and album artist tags, and all of the associated MusicBrainz IDs, along with the standard metadata we’ve always stored.

The next release will introduce some additional features for nice audio CD support.

USB Mass Storage Support

Gabriel also implemented support for syncing USB Mass Storage Digital Audio Players. This is the first media player device class that we’ve implemented for 1.0, but we are working on MTP/PlaysForSure support in parallel. MTP support is currently not as complete as USB Mass Storage, but we expect to have both completed for the next release. If you have a USB Mass Storage device though, you should be mostly set with this release. We’ll add iPod support back after we finish MTP.

Experimental Shuffle UI

Scott created a mockup of a new UI for enabling shuffle playback modes. I’ve never seen anything quite like it, but it grew on my very quickly and the metaphor makes sense. However, we’re a little concerned about the general discoverability of the feature. We’ve decided to keep it in for a few releases to gather some feedback. However, if you’re reading this, you’re probably tainted on providing good discoverability feedback since I’m about to tell you what it is and how to access it — but of course all feedback is welcome!

The basic idea is that the next action implies acting upon the model via some rule - the shuffle mode. Shuffle can either be “off” or “by song” (and soon “by album” and “by artist”, among others). So Scott decided to group the shuffle mode UI with the next button. I guess the good thing for the discoverability issue is that the UI is exactly the same that is used in web browsers, particularly Firefox with the grouping of Next with a History menu.

Last night, Gabriel and Scott apparently pulled all-nighters and managed to fix a large handful of bugs — one of which included implementing smarter shuffle logic. Now Banshee will never play songs you’ve already heard on shuffle or songs you’ve skipped.

Performance Improvements and Bug Fixes

While fixing some DPI issues with the way we were using Pango and Cairo, I saw some areas that needed some performance work. I managed to make text rendering in our managed list view about 160% faster. You can actually feel the difference. Awesome. Oh, and yes, the view now respects your system DPI settings, and even properly adjusts to DPI changes while Banshee is running.

On the whole, we managed to close 46 bugs since the Alpha 2 release. Not bad for two weeks of work, on top of implementing a slew of large new features!

I also spent some much needed time cleaning up and organizing the libbanshee C code, which is where our GStreamer layer is implemented. In the process a few bugs were fixed and the code is now much easier to maintain.

Podcasting and DAAP

Alex Hixon has been working on porting the DAAP client feature to the new code base, and Mike Urbanski checked in his new Podcast code. These features are both still under heavy development, so we’ve turned them off by default in the build. I’ll discuss them both in more detail when we release with the features turned on - hopefully in just a couple short weeks. A big thanks to both Alex and Mike for their hard work in these areas.

Other Banshee Things

• I realized a few weeks ago that I never announced to the world Planet Banshee, which has technically been around for about a year now. It’s just a planet site like all the others to aggregate the blogs of Banshee contributors. Follow along if you’re interested. We’re also looking for more people to add. If you’re contributing in the Banshee world, let me know if you want your blog added.

• Will Farrington beat everyone to blogging about this Alpha 3 release, so check what he has to say - a great post.

• LugRadio USA - Tomorrow I’m headed out to San Francisco to give a talk about all of this great new Banshee stuff on Saturday, among um, other things. If you are not planning on attending, it’s not too late to travel! Do everything you can to make it there. Regardless of any expense incurred, it’s sure to be a blast, and the event itself is only $10.

Digg It!

You simply must attend LRL USA this year. It’s going to be awesome. Gabriel and I will be demoing the latest Banshee goodies, there is an impressive speaker and exhibitor list that’s sure to please, and I’m betting the evening social gatherings to be worth it all.

So stop thinking of excuses and just book the flight!

After just under two weeks of hard work, I hereby present Banshee 1.0 Alpha 2!

• View the release notes
• Banshee 1.0 Alpha 2 Source
• openSUSE 10.3 users:
  
• Foresight 2.0 users: Use PackageKit or Conary to install banshee-1

We’re going to be cranking out the releases leading up to the final 1.0 release every one to two weeks, so get used to this!

A Public Screening

You might be wondering what we can accomplish in two weeks? How about full video management and playback?

Banshee 1.0 Alpha 2: all about the video

While the feature is very new, it’s rather complete and solid. We expect to add more goodies on top of this, and I’m sure much bug fixing and tweaking will follow, but I’m quite excited to have finally landed this. We were able to very easily add the video library management by leveraging the power of our new underlying data model.

We will be adding a slick new video collection view in the future to allow you to browse and view your video collection with thumbnails and previews.

Other notable improvements

A number of other smaller features and bug fixes landed in Alpha 2, including:

• Play Count, Skip Count, Last Played, and Last Skipped columns are updated
• Improved column handling in the new list view
• The Bookmarks extension was ported to the new core
• i18n works again
• Improved support for dark GTK themes

For more details on the video support and other changes since Alpha 1, read the release notes. Also don’t forget to read about the previous release which has lots of new juicy feature overviews if this is your first time reading about the Banshee 1.0 alpha releases.

Miscellany

• Building and running Banshee from trunk - mostly applies to the tarball releases
• Other resources related to 1.0 stuff - Mostly developer related
• Become part of the Banshee Community!

Digg It!

As overheard recently in the #banshee IRC channel:

<woodwizzle> Is there a way I can select all the songs in a directory? …
<gabaug> woodwizzle: search for path:directoryname
<gabaug> that’s path[colon]directoryname
<woodwizzle> ooh, thats cool
<woodwizzle> in fact that is friggin awesome

Our query support is fantastic. Try the alpha.

It is my immense pleasure to announce the first preview release of the next generation of Banshee. This Banshee 1.0 Alpha 1 release is a culmination of so much work by so many awesome contributors.

Now, first things first. This is going to be a long post, so let me link to the crucial bits first for the lazy enthusiasts out there:

• Really awesome release notes
• 1.0 Alpha 1 Source
• For openSUSE 10.3 users:
  

Kudos

Before I dive into the details of the release I would like to highlight few people in particular who have really spent a lot of their own time molding Banshee recently.

• Scott Peterson - Scott has been a code and ideas machine. He’s committed huge amounts of work to many areas of the new codebase, all while going to school full time as a drama major at NYU, and working on a number of other related projects we’ll eventually sweep up into Banshee.

• Alexander Hixon - Alex sort of came out of nowhere a couple of months ago and started hacking on the new Banshee by reviving the old Equalizer patch. Alex is also responsible for making Audio Scrobbling work again.

• Will Farrington - Will has been hanging out in our community for a while, but a couple of months ago he started submitting patches and getting familiar with the codebase. He’s new to C# and some of the technical concepts around GTK/GNOME/Mono, but he’s been learning quickly and making valued contributions.

• Gabriel Burt - Having Gabriel on the Desktop Team at Novell working on Banshee with me has been fantastic. We’ve made so much progress in so little time. From Last.fm to our new database and Xesam/Query layers, Gabriel is at the heart of it all.

A Short History

This is the first release that shows off the hard work we’ve done on rewriting the core of Banshee. There were a number of critical flaws in previous releases due primarily to the fact that writing custom data models for the GtkTreeView was not possible until very recently in Gtk#.

We took some much needed time to redesign the database layer of Banshee to be able to deliver powerful model/query/cache level features and provide a framework to build on for years to come.

I decided to ditch the GtkTreeView and it has paid off. On top of this model sits a slick new list view rendered using Cairo. We control 100% of the drawing, so we can take this thing anywhere we want in the future - things you can only dream of with the GtkTreeView. You’ll already notice some nice GUI “bling” when using the view - try reordering columns.

With all of these core architecture changes, what we have now is a truly flexible framework for developing our prized Banshee. Here’s a somewhat dated diagram of how the different components all fit together.

That said, we still have a ton of work to do. This release does not have feature parity with previous releases. We’ve still got some more core changes to make (namely, finishing the new hardware layer) and a number of plugin features to port to the new core. See the release notes for details on what features are not yet available in this release.

Screenshot. Just one.

New Features

Just a quick overview of new features. You should really read the release notes after this.

• Artist/Album Browser - Yes. Finally. Probably the most requested feature over the past three years has been the ability to filter a source by Artist and Album selections. The album view features glorious cover art previews, of course.

• Listen with Peace of Mind - Now that Banshee is built on a solid data model, we can drive playback independent of what source you have in view. This means you can play a song in one source and switch to another source without having the playback switch to the new source once the song you started playing finishes. Playback continues from whatever source you start playing from.

• The Play Queue - Really this is just a small UI layer on top of the dedicated source playback mentioned in the previous bullet. But it’s pretty nice. If the queue is populated, it forces itself to always be the dedicated playback source. Once an item plays from the queue, it is removed. When the queue is empty, playback resumes from your library.

• Last.fm Integration - Last.fm is everywhere in Banshee, and we’re not done by a long shot. The Last.fm radio extension will change the way you listen to music. Try it now.

• Software Equalizer - At least it’s entertaining to play with, though it’s hard for me to be a real fan of software eq. I’m told though that it can help a lot when you’re stuck with a less than ideal sound system.

Performance

The new Banshee has loads of impressive performance improvements that really should be the subject of a separate detailed writing. With that in mind, I’ll just touch on each point.

• Faster Startup - For me, on average it takes 1.5 seconds to fully “boot” Banshee. The key here is that startup time is no longer a function of the size of your collection. While there are still many things to optimize (just connecting to DBus appears to take about 1/5 of a second), this time is impressive compared to previous Banshee releases (startup time was proportional to the size of your library).

  For curious users, starting Banshee from the command line with the --debug argument will print a summary of exactly how the startup time breaks down. This will help us pinpoint services to improve later, leading to even faster start up.

• Decreased Memory Footprint - Again, regardless of the size of your collection, Banshee should have a relatively constant memory footprint that is much reduced from what you might be used to with previous Banshee releases. I’ll talk numbers in a separate post.

Try it now!

One huge thing to note about this release, and all releases to follow - it can be installed and used in parallel with previous Banshee releases. This means you can try the new stuff out without ditching the old! So there should be nothing stopping you from trying it!

Your existing Banshee library will first be copied and then migrated to the new database format. While it is not backwards compatible, the new releases will not mutate any data used by previous Banshee releases.

It’s safe to package, install, and use side-by-side with previous releases. I will be submitting the new release to openSUSE 11 tomorrow and we may ship with both package sets, depending on when we actually can make the final 1.0 feature parity release. I say this to emphasize it’s safe to use… now.

More to come

We’ve got so much more planned. Remember, this is just the first alpha release leading up to the 1.0 release. What will that be? As soon as we reach feature parity with our current stable series - that’s when - and it’s not too far off either. In the mean time we’ll also be adding new features, so stay tuned, and try the releases.

UPDATE: I forgot to mention some resources on the Banshee Wiki that might be useful for those who want to dive in and try this preview release from source tarball or trunk. Quite important, these links!

• Building and running Banshee from trunk - mostly applies to the tarball releases
• Other resources related to 1.0 stuff - Mostly developer related

Digg It

A wonderful patch just landed in Banshee trunk, revived by Alexander Hixon that adds software equalization support — the typical 10-band deal with a pre-amp. We had added most of what was necessary for this about 1.5 years ago, but never got around to finishing it. Ivan Zlatev did much of the player engine work at the time and actually started the effort, I did much of the UI work, and Alexander has revived it all for our new codebase in trunk.

Here’s the old screenshot of the Equalizer UI designed so long ago — I still like it very much, though it does need a bit of tweaking still:

That being said, I hate software equalization. I’m reminded of “The Death of High Fidelity”, a wonderful and sad article in Rolling Stone from a few weeks ago. Very much worth the read, and be sure to listen to the samples at the end of it.

I’m still very happy that we finally have this beast enabled in Banshee though. Thanks to both Ivan and Andrew, and Gabriel for staying on top of the patch.

I had the privilege this morning of being the guest “speaker” for the multimedia-themed openSUSE GNOME community meeting where I discussed some of the high level plans for the future of Banshee and what that may mean for openSUSE 11.

I discussed the incredible performance and memory usage improvements, the new model/view, the album/artist browser, the playback queue, our fantastic new Xesam-based search and smart playlist infrastructure, and so on.

As a result of feedback from the meeting, I wrote a guide for building Banshee from trunk on openSUSE 10.3+.

And here are some related links:

• Transcript of openSUSE GNOME Meeting
• Build Banshee trunk in openSUSE - mostly applies to other distributions too!
• High-level Banshee Roadmap
• User-query search language in Banshee
• Xesam home page

And of course, if you’re interested in making your voice count in openSUSE, please join the meetings!

It was brought to my attention this evening that something rather critical was missing from my Banshee 0.13.2 release blog entry.

dude a release blog without a 1-click link is like coffee without caffeine
–Larry Ewing

So without further ado…

1-Click Install
for openSUSE 10.3

Only a few months overdue, we’ve finally released a new stable Banshee. This release includes a slew of important bug fixes and a handful of new features.

iPod

On the iPod side of things, there have been some pretty heavy changes since the last release. We now require PodSleuth and the latest ipod-sharp. This is the first release that drops libipoddevice, the hardware layer that was obsoleted by PodSleuth.

What users should care about is that this release supports the new Nano and Classic iPods. We currently are not supporting the iPod Touch nor the iPhone. Of course, my personal stance towards any iPod, especially the iPod Touch and the iPhone is to simply avoid the hardware and the lock-in that goes with it.

Last.fm

The biggest new feature users will notice is the Last.fm streaming plugin that Gabriel Burt wrote a few months ago. This plugin allows you to listen to Last.fm radio stations with all the love/ban glory expected from Last.fm clients.

We have opted to disable this plugin at runtime by default for now, but it is built by default and can easily be enabled through the plugins dialog. Gabriel has blogged in detail about this awesome new plugin.

Album Track Editing… now even easier… again

A couple of months ago I found myself in the position, yet again, of wanting to import a CD that didn’t have metadata in MusicBrainz. I have blogged about the excellent track editor in Banshee before, but I continue to want to improve it. Editing an entire album’s metadata can be a tedious task, but I think I have greatly simplified it yet again.

Now you can select a table or list (from a web site, for example) of track names for the album you are editing and paste the entire selection into the first “Title” field in the track editor. The selection will be parsed and applied to all of the tracks in the editor.

For example, I went to Amazon.com, found the album, selected all of the tracks, and pasted it into the first title entry in the Banshee track editor. I didn’t have to type any of the titles on the CD. I created a screencast of the entire process of filling in all of the album metadata manually. Slick, though it’s still of course always better if the metadata can be found in the first place via MusicBrainz.

Screencast demoing the new batch title editing for albums without automatically resolved metadata. Ogg/Theora, 46 seconds, 3.2 MB.

With metadata on the mind, I should note that Banshee’s metadata services stack is very versatile and allows for any number of metadata providers. We have a few, including MusicBrainz, Rhapsody, and Amazon. However, the Amazon provider does not fetch metadata, it just downloads cover art (and same applies for the Rhapsody one). It would be really nice if someone provided a full Amazon provider (or Rhapsody) that used their web services API.

The problem with this however, for Amazon, is that it requires a developer key (at least it did in years past), and this is why we have never invested time into implementing one. Instead we just rely on MusicBrainz, and perform cover art downloads from Amazon if the MusicBrainz metadata has an associated ASIN.

Ugh, this song sucks!

Another minor little feature users may notice is a new “Play next song” button that shows up in the notification area bubbles. It’s quite nice when you’re listening to music in the background and a song you hate starts playing. Easy to skip without switching interfaces. Of course, if you have multimedia keys set up, I suppose that’s even easier.

Notification bubble allows skipping songs!

MTP

Alan McGovern has nearly completely rewritten our MTP support and we are close to enabling it by default. The next release should have solid MTP support, and we hope to roll 0.13.3 within the next two weeks. The new MTP support uses libmtp instead of libgphoto2. This decision was made for a number of reasons, though I am really not informed enough to convey them properly. Alan has blogged a bit about his changes and his reasons for switching libraries.

We encourage users to try the new MTP support in this release, but we do not want to see distributions packaging it at this time. To enable MTP support from source, pass --enable-mtp to configure. There are a handful of known issues with many MTP devices, and these will be addressed in 0.13.3. Nevertheless, we wanted to get something out the door.

Mono.Zeroconf

I blogged about my new Mono.Zeroconf library a few weeks ago, and this release of Banshee is the first to require it. It greatly simplifies zeroconf logic inside Banshee itself by allowing us to target only one API instead of two (Bonjour and Avahi). Only the DAAP plugin uses it, so if you do not wish to install Mono.Zeroconf, pass --disable-daap to configure.

Great, but what about the really cool stuff?

While 0.13.2 is a solid release with some exciting new features, the real goodies are in our unstable trunk. We have done a ton of work on trunk, rewriting Banshee nearly from the ground up. Performance improvements are massive, and we expect to have some sort of preview release out within the next two months. Now that we are winding down with this stable series, 0.13.2 is out the door, and winter holidays are over, we will be heads down on trunk, making great strides.

Expect lots of blogging in the coming months about details of trunk. In the mean time we have a high level roadmap that can be tracked. Stay tuned, because a lot of really exciting stuff is happening in the Banshee universe!

We are hard at work on the next generation of Banshee, and I’ll be posting details and juicy screencasts and screenshots soon. What I’m curious about now is what we should call Plugins in our UI. We use Mono.Addins in trunk now, and I have been thinking about renaming Plugins in the UI to something else, such as Extensions. My first thought was, “what does everyone else use?”

That wasn’t so helpful:

• Banshee, Totem, gedit: Plugins
• F-Spot, Epiphany, Firefox: Extensions
• Tomboy: Add-ins

While this is just a small sampling of GNOME applications I thought of in 30 seconds, by far I think Tomboy loses. Add-ins, especially hyphenated, is weird. Note that Firefox seems to mix Extensions and Add-ons. Extra weird.

So the vote is between keeping it Plugins or switching to Extensions. I don’t care either way, but it would be nice to settle on some consistency within GNOME. Or maybe it doesn’t matter. Just a thought.

Some other names we have thought of include: Plugstensions, Bundleups, Snap-Ins, Snap-Ons, and snorp even recommended Butt-Plugs, but I don’t want to think too far into that one. I am sure Strap-Ons was in the running at some point too.

This is where you leave your €0.02. I hope it gets philosophical.

UPDATE: It seems like Extensions wins. Bugs filed against Totem, gedit, Rhythmbox, Tomboy, MonoDevelop, and Banshee. Other applications I’ve run across are already using Extensions, like F-Spot and Epiphany.