Re: [Audacity-devel] The Levelator for Audacity

[Richard A. <ri...@au...>]

On Mon, 2006-12-25 at 05:39 -0800, Doug Kaye wrote:
> Unfortunately, we can't put our code into open source so we can't make
> it part of the Audacity project per se. For legal reasons over which
> we have no control, the downloads will have to come from us and
> they'll have to be binary only. The code currently runs on Windows, OS
> X (universal) and Linux (Ubuntu). The UI is also English-only at this
> stage, but we hope to improve that, too. 
> 
> The good news is that it will be free, just as The Levelator is today,
> so while it won't be open source, we think we're doing it in the right
> spirit. GigaVox Media is a for-profit company, and this is part of the
> free offering we make to the community as part of our marketing. 
In that case it has to be a plug-in, and so quite strongly decoupled
from the rest of audacity. That doesn't mean it can't be
audacity-specific, but I'm not sure it has to be as complex as that.

What I'm thinking of is a generic wrapper for command line tools, so
that anything that can accept a block of data (either through a pipe
(nice), or in a file (slower)) and return another one controlled by
command line options can be used as an effect in audacity. Some sort of
configuration file then defines a UI made up from standard components
which builds the command line, the user presses OK and the command is
run, processing the data. As it comes back from the external binary it
gets put into the project again.

Whilst it's probably not the fastest solution, it does have some major
pluses:
* no licensing arguments - the external code is a separate binary,
unlike a traditional plugin that has to be loaded by the host, and gets
into the GPL/closed source debate.

* Hooking a new application into audacity is easier - all you need to
write is the configuration file for existing CLI applications. They
needn't (at a pinch) be CLI-only - you could hook postfish in there, and
just park the GUI next to audacity. It wouldn't be terribly pretty or
integrated, but it would work.

* Plugins can't crash audacity - if they fail, we just don't load the
data produced, no pointer errors etc to worry about.

* If we do the same for importers / exporters, then we can support any
file format a command line importer / exporter exists for (k3b works
rather like this at the moment), without needing a lot of new code.

* We can also get every feature the command line offers relatively
cheaply. If the user's binary doesn't have the right options for the
GUI, they can edit the config file so it does work - no fixed /
incompatible ABI issues. This could make LAME integration much better,
especially if people hosting LAME downloads could be persuaded to add
the config file to the download, so it always matches the executable.

This kind of assumes that the data is passed to and fro is something
standard like WAV/AIFF/AU formats, which given they have length, channel
count etc headers might not be a bad idea. Alternatively we could do raw
data and a set of command line options to tell the applications what the
parameters are, or even a binary project file format like Bartek's
Octave plugin does (although fewer third party apps would understand
that).
Again, the detail could be set up in a per-effect config file that
essentially described how to convert the information audacity is sending
(things like project rate and duration) into options the processor
understands. It can also say what limitations there are, e.g. only works
on 16-bit audio (so audacity has to dither down to that from the track
data), or only works on stereo data (so can't be applied to mono
tracks). Much of this is related to what we have already in Nyquist, but
with a much wider potential pool of ready-made effects and converters
available.

> I'm not at liberty to explain all the cool things that our new tool
> (Levelator Plus for lack of a better name) will do, but it may be that
> the best place to hook it in is the File|Save As... menu. IOW, it
> might make more sense to invoke the utility as part of output/saving
> rather than within a session. I know that's a little strange, but
> trust me -- it makes sense. :-) 
The problem with that is how do you get the data back to feed to the
half-a-dozen different encoders / compressors that audacity currently
and in the future supports? It's also a nightmare to explain to users,
who play back their project in audacity, it sounds one way and then they
push it out to a file through your code and it sounds different "All I
did was export it to a file?" but it isn't the same data. It also means
if you want to process a part of the project through your code then
continue editing, you can't. You have to round-trip out to a file and
back, which is a hassle.

If what you are really saying is that applying your effects to
multi-track material doesn't make sense, then that doesn't stop it being
in the normal effects mechanism - it just needs to be set up so that if
the user tries to apply it to multi-channel material they get a message
suggesting that they render the material down to a stereo track using
Project > Mix and Render first, then apply the effect.

Richard