I've been developing a nice plugin visualization idea together with Ardour co-developer Sampo Savolainen lately. Sampo originally had the idea of feeding white noise through an EQ plugin, and displaying a spectrum of this to see the frequency response. This way you could see what the plugin is actually doing, instead of some approximation of what it is trying to do. The idea is to update the graph every time plugin parameters are adjusted. This will probably be embedded in Ardour's plugin GUI at some stage (probably in 3.0).

• 

However, this approach had it's problems with getting a smooth graph. After a bit of thinking, I finally noticed we could simply use the impulse response of the plugin, and *drumroll* it works great! Sampo has cooked up a test client, which hosts a ladspa plugin and shows it's amplitude and phase response.

For anyone who knows his DSP, it should be pretty obvious that measuring the impulse response is only useful for LTI filters. However, another idea emerged from this one: Showing the difference between output and input (output_spectrum - input_spectrum) could be useful for non-LTI plugins. Plotting non-linear plugins like this should give valuable information about new signal components produced by non-linearities. However, selecting the parts of the signal to be used for the analysis is not trivial and will need quite a bit of thinking and experimenting.

To say a few words about Ardour development in general: 2.6 should be released any time now and 3.0 is moving forward fast. I finished a region export dialog for 3.0 today. It offers the possibilities to export the raw region output, region output with fades or track output.

So, I've been spending some time not being paid for working on Ardour, but it seems I just can't keep my hands off it...

After quite a bit of changes from the 2.X branch were merged into the 3.0 branch, it was time to merge my Summercode stuff there also. Merging my stuff was mostly pain free, but the 2.X merge seemed to be more problematic. libsndfile was removed from the source tree, but a pre-release version has to be used. Unfortunately, to have Ogg Vorbis support, you need to also get a svn version of Vorbis.

Today I also committed my session merging code, which is capable of merging regions, playlists, locations and the tempo map from external sessions. The GUI still needs work, and tracks is definitely something that should still be implemented.

Ardour's 3.0 branch in general is a bit messy at the moment. One big problem is memory corruption, which we haven't been able to diagnose yet. Some people say things work fine, but other have problems all over the place. Hopefully this will be solved soon.

Most development has moved to 3.0, as commits done to 2.X have to be committed to 3.0 also. That means no more merges to break things ;)

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.