Design Topics

From Audacity Wiki
Jump to: navigation, search
Design Topics
This page is a selection of topics about design.

Discoverable User Interface

One of Dominic's founding principles with Audacity is that the user interface should be 'discoverable'. The intention is that someone should be able to learn to use Audacity and be able to find all its features without having a manual. It's a superb principle, and one that is challenging to maintain.

One consequence of the principle is the two panels for keyboard and mouse preferences. That way the shortcuts are documented in the program by the same interface that allows you to change them.

Plug-in Architecture

As of September 2012 Audacity supports the following compilable plug-in modules which can be found in the lib-src directory in the Audacity SVN source code.

  • mod-script-pipe: As made mainstream by Dan Horgan. Previously it was necessary to visit the audacity-extra project on SourceForge to obtain this code. Some help with using the Scripting module can be found at Scripting in the Manual.
  • mod-track-panel: This is the start of an experiment that will ultimately provide a more flexible panel for the audio, label, MIDI and note tracks. It allows us to safely experiment with new additions to these core features.

Graphic Design

We have a general principle of using blues and greys in the Audacity GUI. New developers tend to like using red to make their new features stand out. However, we try to curb this tendency and tone it down to get a quieter look. We often get people offering replacements for our already well established Audacity icon/logo. The icon/logo is in many ways the cherry on the cake. At this stage in Audacity's development we are more interested in computer savvy graphics designers who will help us on an ongoing basis, improving the look of the wiki, the manual, icons in the program and so on, rather than just a new logo. We would like to have a unified appearance rather than a patchwork and, when we have Theming working well, we would definitely like new skins for Audacity.

Simplified Versions of Audacity

Cleanspeech (now relegated to experimental status) added new functions to Audacity and also attempted to simplify Audacity to a particular role of speech recording and processing. The problem with simplified versions of Audacity is that different people have different ideas about what the core functionality is.

A modular system such as CLAM gives tremendous flexibility in the interface design. However it makes it hard to get the same kind of integration of features and ease of use that we have achieved in Audacity.

A configurable interface that allows you to add and remove and rearrange buttons on the toolbars would help. Our system for hiding menu items probably helps too. In time we may be able to completely remove 'cleanspeech' code from Audacity and instead have it happen through a more advanced variant of the Theming feature.

We are planning to add more tabs to the main panel so that we can have different views for working on the audio. For example, we may add a navigation view.


Earlier versions of Audacity ended up with very turgid code for creating and using dialogs and mapping the widget controls to program variables. ShuttleGui makes that code much shorter and more readable. There are plans to use ShuttleGui more widely in Audacity. The intention is also that classes derived from 'Shuttle' can be used in many places where we need to take simple variables from one place to another, for example from GUI to program variables, to preference variables to command line parameters.


Theming is a first attempt at the moment. All the images and colors live in a single compound png. This is nice for displaying the complete set of images, but it isn't a very good format overall. A lot more needs to go into a theming file than that. In the future we hope to use a zipped XRC file. We plan to use wxFormbuilder to build and view the themed version of Audacity, using a custom plug-in to wxFormbuilder.


If you read the comments at the start of TrackPanel.cpp, you will see that this is one of the classes we want to refactor. We had a GSoC project to write a wxDragGridSizer which in principle would allow us to build the trackpanel using custom widgets of our own for the individual tracks. At the moment the trackpanel is owner-draw, and in effect the individual widgets in it are drawn as flyweight objects.

However, various factors, most notably the behaviour of wxWidget containers on resizing, are pushing us away from breaking the trackpanel up this way. When you delegate the resizing and redrawing to wxWidgets you lose control over repaints and can get undesirable flickering even when you double buffer the individual controls. Moreover we would at least in principle like to be able to have a very large number of controls in the trackpanel. We've seen wxWidgets 'bog down' when there are a thousand controls - a number quite easy to get up to when you have grids. Also at some point we would like to experiment with using OpenGL for rendering in Audacity.

The likely evolution is that we will develop flyweight substitutes for wxWidget widgets (this means we will not need a windows object associated with each one). This will also entail sizers which can work with flyweights. Flyweights will be owner draw, and switching them to draw with antigrain, cairo or openGL will be an option.

LibAudacity and Mezzo

LibAudacity and its successor Mezzo were planned but unfinished audio libraries without GUI based on a substantial rewrite of Audacity's core audio manipulation code. Separating GUI from audio algorithms will be a good thing. The scripting support is helping us to do that, and current opinion is that it may be more productive to work directly on Audacity to achieve the same goals.

Development Process Improvements

There are lots of opportunities for improving the process of producing Audacity. We could use scripting to generate screenshots for the Manual and in testing. We are looking at improved ways of getting translations. We'd like to have a unified build system (perhaps CMake) so that both Linux and Windows 'makefiles' stay in step. We'd like The Ideal Bugtracker to keep track of the different pieces of work we are doing including bugs, features and answering common queries so as to reduce the workload in giving help to users.