Re: [Audacity-devel] Real-time effects stacks

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

On Sun, 2008-05-04 at 12:13 -0400, Michael Chinen wrote:
> I have mixed feelings about non-destructive effect stacks in audio
> editors.  Non-destructive real-time effects stacking is a very useful
> and fundamental tool in a digital audio workstation like protools or
> ardour.  That being said, I have always thought of audacity as a
> sample audio editor as opposed a DAW.  The purpose of a audio editor
> leans more towards fast as possible destructive transformation of a
> small number of input tracks, wheras a DAW is more concerned with
> non-destructive playback so that the user can take his time to find
> the best mix between many input tracks.  The main reason that audio
> editors tend to lack this feature is that they have to be very fast on
> rendering the final audio file, and DAWs are not expected to be fast
> (bouncing to disk on protools takes forever.)  Non-destructive
> real-time effects rendering comes with the cost of having to recompute
> the effect when writing the file to disk.  One alternative is to keep
> the "destructive"  copy around, but the implementation for this is not
> trivial - it begins to resemble the on-demand projects we have been
> talking about.
Interesting perspective. To me the more important thing has always been
that you shouldn't need a huge, carefully tuned machine to run audacity,
which implies keeping the CPU and memory needed for playback down as far
as possible. This in turn means rendering effects in non-real time
first.

> If this is the case then it seems like we should prioritize the
> functionality for desctructive, on-demand stacks, and then move
> towards desctuctive real-time effect playback stacks.  After that
> point the non-destructive implementation can be considered.  Would
> other people like to chime in their thoughts on this?

One first step I suggested to another SoC student was to re-factor the
existing undo stack so it could be accessed on a per-track basis. This
would let you undo changes to track A without touching subsequent
changes to track B. This is I think relatively straightforward in
principal, although not trivial.

The next stage would be to ensure that all the effect parameters were
stored when an item was pushed to the undo stack, so that we gained a
per-track redo function, that would repeat the last effect on this
track, on this track. This means redo without storing any audio
information, just using the track state at the start and the processing
parameters.

That's not really useful, but facilitiates the next step, which is an
(offline) way to go back up the stack undoing effects until a point is
reached, then re-do (calculate from scratch on the new audio data)
subsequent operations to get back to where we were, but with one (or
more) effects missing out of the middle.

At about this point is becomes imperitive that the undo stacks can be
saved in the project, not deleted when you exit audacity (although this
needs to be an option, so people's projects don't grow forever).

The main strength of this is that it keeps the primary project state as
the output, not the input, so audacity exports quickly (only the final
mix to do). It also makes use of the existing undo structures, and makes
it trivial to clear away really old history to save disk space
(something that's often quite hard in fully non-destructive editors,
because all of the original files are still needed, even if they only
contribute a few seconds of heavily processed audio).

Hope this makes sense as some possible routes to getting the jobs done,
rather than just cloning how other people do the job.

Richard