Re: [Audacity-devel] Possible fix for 'Chains applied to files do not clear temporary files after processing each file' ?

[Gale A. <ga...@au...>]

| From Richard Ash <ric...@go...> 
| Mon, 06 Jul 2009 21:48:35 +0100
| Subject: [Audacity-devel] Possible fix for 'Chains applied to files do not clear temporary files after processing each file' ?
> On Mon, 2009-07-06 at 14:51 +0100, Dan Horgan wrote:
> > On Sat, Jul 04, 2009 at 03:44:09AM +0100, Gale Andrews wrote:
> > > 
> > > | From Martyn Shaw <mar...@go...> 
> > > | Sat, 04 Jul 2009 00:30:49 +0100
> > > | Subject: [Audacity-devel] Possible fix for 'Chains applied to files do not clear temporary files after processing each file' ?
> > > > Dan Horgan wrote:
> > > > > On Fri, Jul 3, 2009 at 10:59 PM, Dan Horgan<da...@go...> wrote:
> > > > >> On Fri, Jul 03, 2009 at 10:31:46PM +0100, Richard Ash wrote:
> > > > >>> Can we simply purge all the undo entries for the current project, which
> > > > >>> should have the same effect of freeing all the files (this becomes
> > > > >>> something of a stress test for the project structure as well...)? This
> > > > >>> should be safe, or at least if it isn't it needs fixing. Would we even
> > > > >>> want to delete the undo history after every item in the chain when in
> > > > >>> batch mode, so as to minimise disk space usage within each chain?
> > > > >>>
> > > > >>> Richard
> > > > >> This sounds like a better solution - I've not looked closely at the
> > > > >> history code yet but I'll get working on this.
> > > > >>
> > > > >> Thanks,
> > > > >> Dan
> > > > > 
> > > > Apply chain, undo chain, sounds logical to me.
> > > > 
> > > > Martyn
> > > 
> > > I don't feel strongly opposed to that, and possibly the balance of
> > > argument is in favour of undo in one go. 
> > > 
> > > However I note (though not exactly comparable) that we went in the
> > > opposite direction with envelope undo, removing the former aggregation 
> > > of history and making every envelope edit undoable.
> 
> I agree with Martin, and I don't think that the comparison with envelope
> is valid - what we object to there was that if you moved an envelope
> point twice you couldn't get back to the intermediate position using
> Undo, despite the fact that it had been there on your screen.
> 
> In the chains case, you never get the intermediate states in your
> project or on screen, so I don't see how I would know what there was to
> undo back to.

Fairly obviously, you can see what is applied in the individual chain 
commands, and as it was before, you could undo stepwise so you 
could exactly get back to an intermediate position. 

Sod's law decrees that someone will object to "reduced functionality"
even if it may be better for the majority. Though I don't use chains 
much, I can see some value in examining the effect of the individual
chain steps on the waveform by using undo, then redoing subsequent 
steps manually with different values via the Effect menu. This could be
a convenient way of testing different values in the chain without having
to go in and edit and run the entire chain to try them. 

As a concrete example, if a chain causes clipping, it may not be 
obvious which step has caused that. With undo for each step, it is so.

If we can only do one of "stepwise undo" and "undo chain", then "undo
chain" may well be the way to go, but I certainly don't see the case for
it as clear cut as you do. Nor have I myself seen complaints about disk 
space usage specifically when applying chains to the project.

If users are not worried about the disk space, how about a special 
"Undo Chain" entry in File Menu for those who want to go straight
back? If they are worried, then maybe undo behaviour could be an 
option eventually in a new "Chains" tab in Preferences. Chains is very
underdeveloped, and could do with customisation ability (for example 
to turn off warnings when applied to the project, choice of export 
directory...).   

Maybe we should see the reaction in 1.3.8 to the change, anyway.   



Gale