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.
read more