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

[LRN <lr...@gm...>]

Richard Ash wrote:
> Sorry about the rant, but I've spent weeks reading proposals from people
> with no idea how audacity works internally who want to make more drastic
> changes in 3 months than the entire project has achieved in 3 years.
> Along the way a fair number have given the impression that they not only
> don't know how audacity works now, but don't care, and have no intention
> of trying to understand or fit in, we should throw it out and follow
> their master plan. One of the problems with open source is that code
> usually precedes design, which can prevent coherent thinking from
> emerging.
>    
Heh, you got me here :) I don't really know how Audacity works exactly. 
But also i didn't had any tape- or some other linear audio editing 
experience. So everything i said just came out of my head, it's not 
something i saw somewhere else (or i just can't remember where i saw it).

As for undo stack - it sounds reasonable. However, when merged with my 
view of the issue, it would look like "undo stack with some items that 
weren't done" (because these items will be done real-time, and only 
afterwards some buffered data will be available). I.e. audio data for 
real-time audio effects won't be initially stored [in undo stack], 
because there is no data at the moment. And if there is a few RT audio 
effects, one on top of another, only the last one is rendered and stored 
(it is possible to render and store every effect, but this may be 
inefficient, though an option could control that behaviour).

If you're happy with mixing "Do-Undo" and "Plan-Do-in-a-background-Undo" 
items in one stack - then everything is perfect. Though i would have 
added separate effect (let's say "RT effect collection") that is itself 
a container for real-time effects. That would force RT effect to be 
"first-last" only ("first" is everything before the effect, "last" is 
the output of effect, everything inside is re-calculated when something 
changes; only effect parameters could be stored when editing the RT 
effects, so user can rollback to previous state of RT effects, even if 
it means re-calculating that state from scratch), and it will be always 
undoable in one step, and user won't occasionally mix destructive 
effects with non-distructive (using non-destructive effects will be 
conscious). As you have said, there's a difference between destructive 
and non-distructive editing, and completely different use cases. User 
should be aware of that (for his own good).

Placing destructive audio effect after RT effect will force Audacity to 
finish calculation of RT effect in modal mode (as part of calculating 
the destructive effect).

So yeah, essentially it means that RT audio data is on-demand (with 
[optional] background rendering).