The Architecture of Open Source Applications: Audacity

The architecture of Audacity

Lessons from the architecture of Audacity

• user interface should be discoverable: people should be able to sit down without a manual and start using it right away, gradually discovering its features.
• supports LADSPA (Linux Audio Developer’s Simple Plugin API) for dynamically loadable plugin audio effects
• use ShuttleGui to transfer information between wxWidgets library and Audacity in order to avoid tangled repetitive code
• The main problem with the BlockFile structure is that it is exposed to end users. We often hear from users who move the .aup file and don’t realize they also need to move the folder containing all the BlockFiles too.
• Third party APIs such as PortAudio and wxWidgets have been of huge benefit. They’ve given us code that works to build on, and abstracted away many platform differences. One price we pay for using them is that we don’t get the flexibility to choose the abstractions. We have less than pretty code for playback and recording because we have to handle threading in three different ways. The code also does more copying of data than it could do if we controlled the abstractions.
• The API given to us by wxWidgets tempted us into writing some verbose, hard to follow application code. Our solution to that was to add a facade in front of wxWidgets to give us the abstractions we wanted and cleaner application code.
• In the TrackPanel of Audacity we needed to go outside the features that could easily be got from existing widgets. As a result we rolled our own ad hoc system. There is a cleaner system with widgets and sizers and logically distinct application level objects struggling to come out of the TrackPanel.
• Structural decisions are wider ranging than deciding how to structure new features. A decision about what not to include in a program can be as important. It can lead to cleaner, safer code. It’s a pleasure to get the benefits of scripting languages like Perl without having to do the work of maintaining our own copy. Structural decisions also are driven by plans for future growth. Our embryonic modular system is expected to lead to more experimentation by making experiments safer. On demand loading is expected to be an evolutionary step towards on demand processing of real time effects.

references

http://www.aosabook.org/en/audacity.html