Big Architectural Ideas

From Audacity Wiki
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This page is about designing a new architecture for Audacity.
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.

  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.

Edit hint: Keep discussion on the talk page, clear design on this page.


  • Clips: audio, label, envelope, spectra, midi, clip-container. One abstract clip class. We can use idioms from label with audio (drag handles, stacking in a track). We can have effects, e.g smoothing, that operate on an envelope. As things stand selection might be a kind of 'clip' too. Operations:
    • Cut / Copy / Paste / Delete / Move
    • Apply effect to
    • Move Edge?
    • Render to canvas.
    • Get start-time / end-time / duration
  • Command: we currently have several different kinds of command - menu commands, commands that can be invoked by chain and commands for scripting. Can we have a single command class? Operations:
    • Define chosen parameters for command.
    • Bind command to: menu item / button / script keyword.
    • Add-to-History / Do / Undo
  • Project class which knows nothing about what kind of project it is dealing with - does not even know that it is audio. It does know about files and probably about XML tag handlers. It knows about menus and windows. Commands register with it. It defers some specific operations to derived classes. If we still need it, we can derive AudacityProject from it. Operations:
    • open / close / exit
    • most-recently-used-list
    • autosave / recover
    • register command / menu-item / button / toolbar

Channel and Track Grouping

UI mockup 1
UI mockup 2
  • Multichannel support:
    • Any number of channels as a single entity
    • Record from multichannel sources
    • Knows about channel layout (x,y,z coordinates?).
  • Grouping mechanism = Tree
    • To encompass multichannel support, mixes/submixes and clip-library (no implied mixing).
    • It’s nestable grouping, so it is a tree.
    • Also allow for multiple views of the same data, for example a spectrogram and a wave view of the same data shown in the same track.
    • For the grouping mechanism to handle these different options we need the tree nodes to tell us how to combine elements in a group, e.g. mix and do-not-mix.
  • UI
    • Needs to make it easy to work on a group "as if it were a single track". Code for this needs to be handled outside the effects class so that we do not duplicate it for each effect.
    • UI mockups by LRN (right) are drawn from user's point of view, but architecture should match that (generic group class that can accept any simple operation and mirror it to all sub-tracks/groups). More details on talk page.

Developer/QA Backing

  • TBD


  • See talk page.