I finally got my Summercode report written. This means that when I get confirmation that it is good enough for the project coordinators, my project is over. However, I will still be giving a short presentation regarding the project at the Openmind conference on Tuesday October 7th in Tampere, Finland.

I must say this summer was a great experience. I would like to thank everyone involved, especially the people who tested my work and gave great feedback. The project coordinators and all other people responsible for organizing and sponsoring the project also deserve credit. They are the people who made this all possible. Thank You!

For now I think I'll take some time off from Ardour and maybe fill my coding desires by writing a LV2 plugin. This is something I've wanted to do for some while, but never got it done. Nevertheless there is still some work that should be done regarding Ardour's export, which I will tackle some time later.

Anyway, here is the report, and as a bonus, the not-yet-published presentation slides I used at the finals.

My Ardour summercode project is getting very close to it's end. The last few days I've been working on minor bugs, GUI tweaks and integration of the new export dialog into Ardour.

If you are up to building Ardour yourself, please check out my branch and do some testing. Everything should be functional now, but there might still be some bugs. Region export is one thing that is not yet functional and will need some planning before it is re-implemented, since the current model has caused a lot of confusion. Again, the best place to report bugs is #ardour @ freenode

For the next two days I'll be writing my final report and maybe touching up a few places here and there in the code. When I get my report done, I'll publish it here with some final screen shots. Until then, Happy Testing ;)

After a lot of work this summer, my Ardour summercode project is nearing its end! All new features mentioned in the project plan are implemented, and it's time to start polishing things up.

The full blown export multiplication mentioned in the redesign document ended up being a bit too complex to operate (and implement), so we decided to use a tabbed model instead. Instead of tabbing only formats (as in this mockup), we decided to tab the whole file section, ending up with a dialog like this:

• 

One thing I've been working on, which is worth mentioning is the preset system. The export configuration is split in two parts: A "local" part consisting of the timespans and channel configurations and a "global" part, which is the format and filename configurations. When the user saves a profile, the global part gets saved to the user configuration directory, and the local part into the sessions files. This way presets can be loaded and saved almost transparently in multiple session, with making changes to both parts. A name matching system for guessing local configurations based on the global configuration was also discussed, but implementing something like this is a job for the future.

So now I have less than two week left of my project, and a few things still need to be done:

• Integration with the rest of Ardour is not as good as with the old dialog, so I'll have to edit (context) menus in the rest of Ardour to get the new functionality integrated as well as possible.
• CD Marker export is not functional in the new dialog. The code for this already exists, so it shouldn't be much work.
• A progress indicator dialog should be made.
• Some improvements to the GUI should be done
• Export Preset and Format XML-file should be made exchangeable

The three first items in the list shouldn't take long to implement. Improving the GUI is more complex. Some parts can be easily improved, but others (like the channel selector) would require writing a rather complex new custom widget. For now I will concentrate on fast improvements.

The last item in the list is something that has been discussed in IRC, but might take too long to implement to get it done during this project. The problem with the current model is, that format profiles are referenced via an id, which is serialized into the XML file to keep things consistent. If users were to exchange format profile files, these ids could conflict, causing problems. Thus, ids with two part must be used: one part is for identifying the format, and the other for verifying that it was created on this specific system. If an id with a conflicting identifier is imported into the system, the situation should be recognized, and the id modified to fit the current system. The same applies for preset files.

Last week of summercoding was not very productive for me. I have mainly been working on Ardour's export instancing/multiplication widget, or more specifically the model behind it, and operations related to the model. The any-number-of-four-different-components-connected-arbitrarily-from-top-to-bottom model is a hierarchical graph, i.e. a bunch of nodes with a bunch of parent and child nodes. And since this model is represented in a GUI that shouldn't jump around, both parents and children have to be ordered.

Well, things got a bit complicated and I experienced a lack of motivation for the first time this summer. To be honest, having done maybe a bit too much work now and then, I had it coming. So, I decided it is time for a vacation. Next week is dedicated for relaxing and, hmm... relaxing :)

For a little over a week now in my Ardour summercode project, I've been mainly stabilizing code, and working on tagging and error reporting. Ogg Vorbis and FLAC files can now be tagged with metadata, which is editable via the GUI I created at the very beginning of the summer.

I've also implemented BWF export. BWF (Broadcast Wave Format) is a fairly common format in pro-audio. It includes a standard set of metadata and lots of extensions, which can be used to extend the metadata when necessary. The most useful piece of metadata is positional info. Each exported file includes a reference to the position in the time line it was originally recorded. A common use case for this could be working on something with two different DAWs. If both support BWF export and import, it is easy to get the files aligned right on the time line. The standard metadata also includes the time of export and originator information.

According to a EBU recommendation the originator reference should include, among other things, a recorder serial number. Clearly no such thing exists with DAWs, so instead I decided a svn revision number would be a good alternative. So, each exported BWF file includes the revision it was exported from. This will definitely help with debugging, if problems occur. Also, since BWF can be used as the default recording format in Ardour, it may also help with non-export-related problems. Including the revision in other taggable formats could be a good idea in addition.

Other things I've been doing include an error reporting mechanism in the main dialog, normalizing that works properly when a multi-channel export is split into mono files and lots more stability compared to the situation a week ago.