My first week of summercoding was full of work and accomplishing - this week was the opposite. I started out by merging changes from Ardour's 3.0-branch to my branch and taking a look at what has been done there.

Next it was time to do some planning. Ardour's export code was not very modular, and I noticed I'll have to brake it down in any case. So, I decided to take a look at multimedia frameworks like gstreamer to use in renewing the export process. Unfortunately I didn't find anything that satisfied me.

Basically I had three requirements: quality, reliability and the possibility to export Wavpack encoded files with floating point samples. The last requirement might sound a bit strange, but Wavpack is actually the only free and open way to encode floating point audio losslessly. The other two very important formats: FLAC and ogg vorbis, are already implemented in a prerelease of libsndfile, the soundfile i/o library used by Ardour.

Since I didn't choose to use any new tools, I decided to start reordering the existing code. Ardour is distributed with its own patched version of libsndfile, since it needs some functionality that libsndfile doesn't have. I started by updating Ardour's version of libsndfile, which was not a very successful process. Libsndfile uses autotools and Ardour uses scons, so I tried to build it with scons. After many hours of fighting with it, I decided to just do an ugly hack, calling './configure' and 'make' from a python script executed by scons. In the end this was not a bad choice, since once the new version of libsndfile is released we will not need to distribute our own version of libsndfile anymore, and the hack can be dropped...

Next, it was time to do some actual reordering. Because exporting includes steps where the amount and format of data changes (SRC and format conversions) I decided to use a graph model, where I pipe the different processing modules, and feed the data into the first module. I made a simple C++ template based graph model (less then 100 lines of code), and moved the existing code into modules implementing the graph model so that It will be easier to add new functionality.

I haven't yet done any testing on the modules, so I think I'll start doing that right about now...

So, I have one week of full-time open source coding behind me now, and I must say I've done a lot and learned a lot during the past week. I am one week ahead of my schedule and everything is going pretty well.

Let's start with what I've accomplished: Briefly said, I added basic metadata support to my branch of Ardour. Ardour sessions now include a chunk of XML that includes metadata related to the track, album and people involved in creating the track. As an extra feature, not included in my project plan, I added support for selectively importing metadata from other sessions. The screenshots below show the editing and importing dialogs:

The XML format currently used for metadata is probably not final. It will be further improved later on. As the data is internally stored as strings in a C++ STL map container, and the serialization and deserialization functions are both less than 20 lines long, changing the format will not be a big task, as long it is done before releasing a version of Ardour that uses the functionality.

Otherwise the code used is very modular and extensible. I ended up refactoring the GUI code about three times, the result being strong encapsulation and modularity. Each type of data field, set of data fields and dialog have a common base class. All information about which data is included in a dialog is defined in the dialog base class. This ensures that all metadata related dialogs have the same sets of data. The type of the dialog is determined by which class derived from the data set base class is given as a template parameter to the dialog class.

What did I learn then? Well, for one, I learned that the perfectionist inside me might make me code from ten in the morning to three o'clock at night. This certainly is not healthy and something I should learn not to do. I also learned that I should plan well before implementing and that if something will be extended it should certainly be made extensible from the very beginning. These are all things I thought I already knew, but for some reason I still fell for them...

I also learned lots of boring stuff like how gcc doesn't like some things you should be able to do with template classes, but I won't want to bore anyone to death with that, so I'll just stop here...

Oh yeah, I also added a Summercode project page that includes my current status in my planned schedule among other things.

Today was my first day as an open source professional, i.e. I started my summercode project. I must say I've really enjoyed the day, and hope this feeling will last through the summer...

So far I haven't got much done. The biggest news is that I have an svn branch, which can be found at http://subversion.ardour.org/svn/ardour2/branches/sbergen/ So, if anyone is interested in following my progress more closely than this blog, feel free to take a look at the svn branch!

I picked up this meme from the summercode IRC channel via myrtti. (You can follow it back quite far from there...)

sbergen@jt7-153 ~ $ history|awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}'|sort|uniq -c | sort -nr |head -n 10
155 ./sconsi
91 gtk2_ardour/ardev
65 sudo
23 cat
20 cd
19 svn
18 gtk2_ardour/ardbg
11 scons
10 mysql
9 ls


You can clearly see what I've been doing lately, and I thus suggested that this would be part of next year's summercode applications ;)

I ended up being one of the five selected to the Finnish Google Summer Of Code equivalent Kesäkoodi, or Summercode in English.

This means next summer I will be paid for hacking on Ardour for three months. My work will consist of renewing Ardour's Export dialog while adding functionality to it, and adding meta data and tagging support to Ardour. More information can be found in my project plan.