Redesigning Ardour's export infrastructure
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.
Comments
Post new comment