On May 12, 2004, at 7:14 AM, dmclean62@... wrote:
> My name is Donald McLean and my regular job is as a software engineer
> for the Space Telescope Science Institute. At the moment, I work in
> Java, but I've worked on two C++ projects. All together, I've been
> working as a software dweeb for over 16 years including almost 10
> years working in OO languages with about 5 of that in C++.
> As mentioned in previous messages, I'll be using CygWin on Windows XP.
> I'll probably use xemacs (in viper mode) for editing unless someone
> has a better suggestion.
> Now that I can build the system, I'm going to start work on a feature
> that I really want - but I don't want to step on anyone's toes if
> anyone else has already started it.
> I need to be able to create scripts to perform a set of tasks in a
> pre-defined way. Some of the tasks that I want to perform are:
> 1. Read from a sound file.
> 2. Amplify a piece of sound data.
> 3. Change the speed (resample) a piece of sound.
> 4. Generate a piece of silence.
> 5. Glue a number of pieces of sound together serially into a longer
> 6. Output a piece of sound to a file.
> All of these are things have already been implemented, fotunately.
> Once the basic framework has been created, adding additional tasks
> should be fairly straightforward.
> I was planning on implementing this in two stages:
> 1. Read and execute a script.
> 2. Graphical script editor.
OK, several issues here.
First, as Alexandre mentioned, this has been discussed before. There
is a bit of contention, because there are two different approaches to
automation that are both called "scripting":
1. embedding a language interpreter, such as libperl or libpython (or a
custom language), directly into the Audacity binary. A user could tell
Audacity to execute a Perl or Python script, which Audacity would do by
passing it to the embedded interpreter. The interpreter would have
access to Audacity's internal data structures by way of bindings that
simply wrap Audacity's method calls. This is what the UNIX world
generally means by "scripting," cf. vim, emacs, gimp, blender, etc.
+ relatively simple, well-understood
+ it's what UNIX users expect
- for platforms without a perl/python installation (windows), Audacity
would have to ship the standard source files for the language.
third-party modules would also have to be installed with Audacity.
Supporting an interpreter could be troublesome.
- you have to choose one language, which might not be people's favorite
- doesn't lend itself to automation from outside the application
2. establishing some kind of RPC protocol by which Audacity can be
controlled over a pipe or socket. Any language could support this by
writing code that supports this protocol.
+ language agnostic
+ keeps interpreters out of Audacity, reducing support issues
+ it's what Mac users expect (?)
+ supports outside automation
- requires added complexity of pipe/socket mechanism, and designing a
protocol to go over it
- requires added complexity of making external commands cooperate with
UI commands, without screwing up scripts. (If your external script
asks "how many tracks are there?" and you say "3", but the user then
deletes a track, your script is going to get messed up. It seems like
the script would probably have to block the UI)
Dominic is strongly in favor of (2). I used to favor (1), but now I'm
The second issue is that Audacity is currently undergoing a rewrite
that will make it more friendly to scripting, largely because the APIs
will be cleaner and more self-sufficient. The rewrite is called Mezzo,
and you can read more about it here:
Since the library will be independent of the GUI, it will even be
possible to write scripts like you propose that run from the
command-line! Of course, since Mezzo has a long way to go, this
doesn't help you now.
Here's what these issues mean for you. First of all, if you work with
the current Audacity code-base, you shouldn't expect your code to be
very enduring. On one hand, 1.2.x is young and we can expect it to
live a long time (a few years at least). If your scripting interface
is reasonably stable, it could perhaps go into a 1.2.x release. On the
other hand, it would almost certainly need to be rewritten when Mezzo
becomes Audacity's back-end.
Secondly, you ought to flesh out your specific plans for what
"scripting" means to you. If this is a feature you need, then no one
is going to prevent you from writing it, but it will have a better
chance of making it into a release if your approach is in unity with
Audacity's goals. Also, we will want to keep support issues to a
All that said, good luck. :)
> I was thinking of creating a "scripts" directory under source for
> this. I also have to figure out where the best place to put this on
> the Audacity menus - once I figure out how to modify the menus :-)
Look at Menus.cpp and follow the conventions there; it's not too