For the last week or so, I've mainly programming Ardour's new main export dialog. So far I've just made the GUI components with not much interaction with the backend. A few widgets do get their data from the Ardour engine, but nothing really does anything yet. Here are some screenshots:

While I was making the channel selection widget, an irc discussion lead to the conclusion, that this design isn't flexible enough. The problem is, you can't make a e.g. a mono mix of a stereo track, because the widget doesn't allow selecting two ports from one track/bus to be connected to the same export channel. Also, interaction with the widget needs some extra clicks here and there to access all the actions. The long term plan is to implement Thorsten Wilms' routing matrix design globally in Ardour, but before that gets done, I might have to make a custom cell renderer for the channel selector widget.

As you can see from the screenshots, I also finished the export format selector. It had quite a bit of problems with signals between widgets getting all messed up, but all that is gone now :)

This week I've been working on Ardour's spiffy new interactive format selection dialog. I thought I had already done all the hard work last week with all that set algebra stuff, but alas, the dialog part was quite challenging also.

The dialog has a set of compatibility items and a set of formats categorized by their quality (see screenshot below). The currently selected quality always reflects that of the selected format. All selected compatibility items form global restraints. All formats that do not fit these restraints are marked red and selecting a red item clears conflicting compatibility selections.

One of the problems (from the programmers point of view) with this dialog is that the selectable compatibility items and selections interact. If gtkmm (the GUI library C++ interface) had a better selections of signals emitted by different GUI actions, it wouldn't be a problem. But the only good signal to listen to is the selections (from TreeView::get_selection) signal_changed, which is emitted always when the selection changes. This includes the situation when the selection is changed from within the code, as well as changes made by the user. The problem with this is, that if code propagated selection changes are not ignored by the selection handler, it will often lead to an infinite signal exchange between the GUI and engine, which will eventually cause a crash.

The signal problem was not my only problem. Some things like clearing several compatibility items at once proved to be difficult also, but nevertheless it's mostly done now. I still need to do some work on the encoding options, which will change according to the selected format, more on that later...

The new Ardour export format selection dialog I've been working on lately has some quite interesting features. The most interesting one is the format compatibility system. It allows the user to select compatibility items like "Audio CD" or "Pro Tools" and the dialog responds by marking the incompatible formats red. The part that makes this hard to implement is the fact that you can select many compatibility options, and selecting a red format should cause the conflicting compatibility item to be deselected.

Like the topic says, I'm using set algebra to solve my problems. Each compatibility item and actual format is of the same base class, which has set algebra operations like intersection and difference. This makes it easy to construct global compatibility restraints and compare them to actual formats.

So, this is work in progress and I haven't tested it yet, but at least I have a good plan. What I have accomplished lately is threading the export post processing. This had to be done in order to support real time exporting - since Ardour uses Jack, it has to respond to Jack's callbacks every period (determined by the soundcard buffer settings), and post processing entire files can not be done in one period...

After I get this format compatibility stuff sorted out, it will finally be time to do some GUI work, and see some of this stuff in action. At the moment I've been testing the export functionality by hard coding an export specification, which is not too slick. Hopefully I'll be able to post some GUI screen shots next week!

In the end of last week I came to the point in my project where I had to take a look at real time exporting. This made me think about many things indirectly related with it.

Ardour's current export scheme allows you to export only one channel configuration into one file format. If you wanted to export the same timespan with different channel configurations to several files, you would need to process the timespan separately each time. So, if you did a real time export with several channel configurations, you probably wouldn't want play through the timespan several times. Something had to be done.

Coming up with a scheme that supports an arbitrary amount of timespans, channel configurations, file formats and filenames was not easy. I had to take out a pencil and some paper for the first time in this project. The model I ended up creating has a class for each component that can be defined in the GUI: timespans, channels, channel configurations, file formats and filenames.

The central component is the channel configuration. When a timespan is exported, each channel configuration registers it's channels to the timespan, which then saves each unique channel to a temporary file. After the timespan has been read, the channel configuration gets the data it needs from the timespan, and writes it to all the formats that are registered to it. If several timespans are selected for import, this process is repeated for each timespan.

Right now I'm in a situation where I've been making radical changes to Ardour's code for four days without being able to test it even once. It will soon be ready for testing, and testing will probably take quite long. The basic structures for the tasks I have scheduled for this week are all ready though, so if I'm lucky I just might stay in schedule. In any case, the changes I've been making now will make future work a lot easier, so I shouldn't worry about staying in schedule on the long run.

The title of this blog entry refers to a feature I implemented for Ardour this week, which caused a lot of discussion. The feature is trimming silence from export products, and the question is how to define silence. A pretty good definition is "a short period of a signal with a low enough RMS value". (skip the next chapter if this doesn't sound interesting ;)

The above mentioned definition is needed because absolute silence is very rare in real life situations, and it implies setting two parameters: a threshold for the RMS value and a length for the period. Setting the threshold level is pretty straightforward, but the period length is a bit more complex. The length of the period depends on the lower bound of the bandwidth you consider relevant. To get a reliable measurement, the period length should be at least half of the wavelength of the lowest frequency. This would mean 1/20 seconds for a lower bound frequency of 10Hz, which is pretty reasonable. If more accuracy is required the measurement could be done with a sliding window, but this would mean much heavier processing.

Anyway, what I ended up implementing doesn't include any of the above, but only trims all the zero valued samples from the beginning and end of the export product. The reasoning for doing the simpler implementation is the fact that doing something more complex should be done in the editor, not in the export dialog. This will keep the export dialog cleaner and allow more precise editing in the editor. However, this more sophisticated silence trimming will some day most probably be implemented as an editing feature in Ardour.

And last but not least a brief status report:
So far this week I have finalized the structural changes I started last week and implemented normalizing and trimming silence from export files. Next I should do adding silence to the beginning and end, and then move on to next weeks tasks.