GUI Plug-ins

From Audacity Wiki
Revision as of 19:10, 17 September 2018 by James (talk | contribs) (Tweaks.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
GUI plug-ins extend the functionality of Audacity in ways that go beyond the processing of individual effects.

Such plug-ins can completely transform the user interface of Audacity. They have access to the wxWidgets  GUI library and can create new complex dialogues and use other wxWidgets facilities. See Creating your own Plug-in for more details.


What API? The API for GUI plug-ins needs to be developed. Please subscribe to our developers mailing list  if you're interested in helping this progress.

  • Will support adding and removing items from the menus via a registration scheme. The code for this is likely to be based on code in the hijacking plug-in from Audacity-Extra where the plug-in registers the menu item and a 'menu position' that determines the order of items in the menus.
  • Will support adding (and removing) pages into the main panel, where the track panel is.
  • Will rely on a refactoring of track panel, so that tracks can appear in other places (as already happens in the hijacking plug-in).
  • Will support adding and removing of toolbars.
  • Will support registering of new track types.
  • Will support registering of new preference panels. There will also be a new plug-ins preference panel that allows entire plug-ins to be enabled and disabled, and also is used to give the credits information for each plug-in.

The general idea of registering and requesting 'resources' is going to be used a lot in the API. There will be a base class that supports the idea.

API Current Status

As of May 2018 we have these plug-ins in the Audacity source tree (under lib-src):

  • mod-null: This plug-in does nothing other than register. It's a starter template to build your own plug-in from.
  • mod-nyq-bench: A nyquist testbench. It adds a new option into the view menu and provides an environment for testing nyquist scripts within Audacity.
  • mod-script-pipe: A plug-in that accepts commands over a named pipe and passes them on to Audacity's internal command handling, and sends the results back. This plug-in has no GUI elements.
  • mod-track-panel: Little more than mod-null, at the moment, this is where a new trackpanel for Audacity will take shape.

The plug-in API includes:

  • A hook for completely hijacking the Audacity API. The standard Frame is hidden, and the plug-in must create a complete new GUI using the exposed services of Audacity.
  • A hook for adding a background task. In our case it's used to run a script engine that takes messages off a pipe and then acts on them using the textual command dispatch code built in to Audacity. In particular it supports running any effect.
  • Samples show plug-ins adding to the menus and using Audacity's ShuttleGui to create dialogs.

See the example plug-in code for how to use these.

API Development Plan

Edit Hint: this is all open to merciless editing...

(extracted from email James->Roger)

I envisage a model where we identify certain services which modules request and offer and develop the API on an as-needed basis. Plug-ins could provide:

  • New Track Types - These should as you say support cut/copy/paste/insert/delete; Also binding of data (either concrete or computed as required) to the track. When we have Johannes' enhancements to wxWidget sizers, these can become true wxWindows, and we will not be constrained to only use them in the main Track Panel.
  • New Main Panels - The TrackPanel becomes a wxNotebook, with wxNotebookPages - including the existing TrackPanel showing the main mix as one of the pages. The language features customisation would add a new notebook page for that.
  • New Preference Panels - There will also be a master plug-ins preference page

In each case we work this by deriving from a common shared base class - which in time comes to define the API. I'm well familiar with issues around mismatch of modules and main application, and changes in API, and I'd suggest that in the early stage we mandate that loadable modules version numbers must match the main core application version number. This may seem overly restrictive, but it isn't. We can later relax this, but being strict about it now saves us from details like making sure that both the loadable module and the core application can veto the loading in a particular combination. Whilst the restriction means that for each release we must recompile all supported modules to the new version, this is no more of a hardship than if they were integrated into Audacity. The upside is that with each release we are releasing a configurable version where level of experimental functionality can be chosen.

Later as the API gets firmed up we can choose which parts we regard as truly stable API and document as such.