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 got myself a MacBook (got it three days ago), mainly to be able to work where ever I want next summer. As hardware I really like it. It has lots of nice small details like the MagSafe connector and battery charge indicator on the bottom of the battery. I also like it's size and all in all it's a good laptop. The only thing that didn't quite impress me was the fact that the iSight camera stopped working today. I had to remove the battery and reset something to get it working again. According to some googling I did, this doesn't seem to be a rare problem...

What about OS X then? Well, my first impression using it was quite nice. Power management and connecting to hardware wirelessly work like a charm and installing applications was easy. Otherwise I must say I didn't like it too much. I've been a Linux power user since 2002 and I'm used to having lots and lots of windows open. The fact that OS X makes a big separation between windows and applications was something I didn't like. Expose makes things a lot easier, but e.g. popping up a new terminal, when I already have some open is overly complicated to do via context-clicking.

Coding on OS X is something I haven't done much yet, but I'll say a few things about it anyway. Getting some *nix programs to compile on OS X can be hard.

Ardour was naturally the first one I tried. I started by installing Macports, which made installing some libraries easy. Still, since Ardour is not in Macports, I had to install every library separately, which took time... After a few hours of fiddling, I got the 2.0-branch to build, but I haven't had success with the 3.0-branch yet...

My next attempt was Crumbled Earth, which uses ClanLib. After a moment of trying I gave up. The main reason was lack of motivation, but again I would have had to do quite a lot of configuring and library installing to get ClanLib to compile. If somebody wants to play Crumbled Earth on OS X please tell me, and I'll give it a second shot. At the moment I just don't have the motivation.

As a conclusion I could say that if I had a large package repository for OS X, I would be very happy with it. I'll probably never have it on a desktop, but I might very well keep it on my MacBook. Some things will most likely start to feel more natural as I get more experience using OS X, but then again I'm quite sure some wont ;)

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 ;)