Scripting



The scripting module is an experimental GUI plug-in that allows Audacity to be driven from an external Perl script. Commands are sent to Audacity over a named pipe. Any scripting language that supports named pipes can be used in place of Perl. External scripting is one of several ways to extend the functionality of Audacity.

How to get started with scripting
Audacity can currently only be used with scripting if you compile a separate plug-in module from SVN Development Code called "mod-script-pipe", as well as compile Audacity itself. See the Wiki Developer Guide for help. You'll also need the scripting language Perl to try out the examples. For actually writing scripts however, any language that can write to and read from a named pipe should be able to use the interface.

We may provide a ready-compiled mod-script-pipe at some future time. If you just want to use scripting but don't want to do the developer steps then you will need to wait for that to be released. Feel free to let us know if you would like ready-to-go scripting in Audacity, and what you would use it for.

Building
Ensure you have the latest SVN HEAD Development Code version of Audacity built and working. The scripting module, "mod-script-pipe" is in SVN (under lib-src), but is not built automatically.

In MSVC, open "mod-script-pipe.vcproj" and build. If all goes to plan, the DLL will be placed in the "modules" directory.

Under GCC, move into the lib-src/mod-script-pipe directory and type "make". This will build the module and copy the ".so" to the modules directory.

ToDo Mac instructions here

While mod-script-pipe allows a script to communicate with Audacity, it is not concerned with the actual interpretation and processing of received commands. That is done by Audacity itself, so for full scripting capabilities it is important to have a recent build of the main program as well as the scripting module.

Testing
A basic test script "scripts/pipe-test.pl" is included in the development repository. Naturally, this requires Perl. It contains a variety of tests and subroutines for sending commands on the pipe.

Run Audacity first, and then execute the test script.

If everything is fine, the commands in the script will be sent to Audacity, executed, and the results sent back to the script.

You can experiment with changing the commands in the script (see below).

If the script hangs, waiting for a response, it probably means that Audacity did not load the scripting module. Examine the logging output to check if this is the case.

If the module wasn't loaded, it could be because it has not been placed in the correct directory or because the module version does not match the version of Audacity. The surest way to avoid this problem is to build both Audacity and mod-script-pipe from HEAD at the same time.

Commands
Some documentation for the parts of Audacity that can currently be controlled via script command follows. Be aware that this is likely to change significantly until scripting has matured. Note also that commands and parameters are case-sensitive.

The command invocations should take the following form:

This is followed by a line break. Then the command is executed, and any responses are written on the return pipe, on separate lines. The end of the responses is signalled by an empty line. Further commands should not be sent until all responses have been read.


 * See also additional commands on the Audacity Wiki.

BatchCommand
This can be invoked differently from the other commands because, at the moment, all unrecognized commands are treated as batch commands. To see what these commands do and how they should be formed, please examine the Edit Chains dialog. As an example, the batch system can be used to apply an effect to some selected audio.

It is also possible to explicitly call a batch command, but be aware that it is not currently possible for a parameter value to contain spaces, so this way of doing it is fairly restricted. If ChainName is provided, the command applies the saved batch chain of that name rather than a single command.

Parameters:

Examples:

CompareAudio
With two tracks selected, running this command compares the tracks sample by sample, and counts the number of samples whose absolute difference exceeds the given threshold. The total count is returned, as well as the number of seconds of audio that these samples represent.

Parameters:

Example:

MenuCommand
Executes a 'menu command', using the system that controls the Audacity menus. This is simple but powerful, and many of the tasks that can be performed by clicking menu items or pressing hotkeys can also be triggered by a script using this command. Use GetAllMenuCommands to see a full list of available commands.

Parameters:

Examples:

GetAllMenuCommands
Returns a list of all available menu commands. These are the commands that can be sent using MenuCommand.

No parameters.

-

GetTrackInfo
Allows information about a project's tracks to be returned to the script.

Parameters:

Examples:

Help
Returns information about the parameters accepted by a given command.

Parameters:

Example:

Message
Sends a message to the command's status target. Since command status messages are currently sent to the script (if the command was triggered by a script), this means the message is sent back to the script.

Parameters:

Example:

Screenshot
The screenshot command is modelled closely on the Screenshot Tools dialog and takes three parameters.

Parameters:

Example:

Select
Provides some control over the project selection. Tracks between FirstTrack and LastTrack inclusive are selected, and the time interval selected is from StartTime to EndTime. Alternatively, if TrackName is specified, then the track with that name is selected.

Parameters:

Example:

GetPreference
Prints the value of the requested preference as a response.

Parameters:

Example:

SetPreference
Sets the preference with the given name to the given value.

Parameters:

Example:

SetTrackInfo
For setting track information - currently track name only. (Note mute/solo can be set with menu commands)

Parameters:

Example:

Import
Load audio data from a file into a track. The file type is detected from the extension, and any format understood by Audacity can be used.

Parameters:

Example:

OpenProject
Opens an audacity project file, optionally from a supplied file name. If the Filename parameter is omitted or empty the user is prompted to choose a project to open. Note that if the current project is not empty and unsaved, a new project window is opened, which may break your script.

Parameters:

Example:

SaveProject
Saves an Audacity project file, optionally to a supplied file name. If the Filename parameter is omitted or empty the user is prompted to choose a saved file. Note: trying to overwrite another existing project will result in an error message to the user.

Parameters:

Example:

Export
Save audio from the project into a file. The file type to export to is detected from the extension, and any format understood by Audacity can be used.

Parameters:

Example:

Adding Commands to Audacity (for developers)
For a command to be callable from a script, a CommandType object for it must be added to the CommandDirectory, which is a singleton class. A CommandType has the job of creating specific Command objects, which actually do the work.

To implement a new command called Foo, it is simplest to create new classes FooCommandType and FooCommand which derive from CommandType and CommandImplementation respectively, and then override the virtual methods as appropriate. Then add an instance of FooCommandType to the CommandDirectory.

In the future, the repetitive nature of some of this code may be reduced, for example by using macros (as in wxwidgets). For more information on the workings of the command system, see the source code - in particular the files in the src/commands directory.

Known Issues & Missing Features

 * Parameters to BatchCommand can't currently contain spaces.
 * Scripting only works with one project at a time.
 * For some menu commands, the project window must have focus for the command to succeed.
 * Scripts have no control over the type and verbosity of responses they receive. (Related: it's not straightforward to get 'output' responses from commands like GetTrackInfo.)
 * Current commands could have stricter parameter validation.
 * There's no consistent way to abort or interrupt commands.
 * There are still many parts of Audacity that can't currently be controlled from a script because commands for them have not yet been created.
 * Due to a slight problem with module management, the scripting module is not unloaded when Audacity quits. This means the script pipes are not properly deleted.
 * There may or may not be security problems relating to the use of pipes. You're advised not to use mod-script-pipe on a system with multiple simultaneous users.
 * The interface on the script side of the pipe is still quite low-level. It may be possible to generate libraries for specific scripting languages from the internal descriptions of the commands.