Possible fix for 'Chains applied to files do not clear temporary files after processing each file' ?

[Dan Horgan]

I tried inserting a direct call to DirManager::CleanTempDir() in the
relevant place (see patch) and this seems to work in the testing I've
done.  However, it seems like a potentially 'dangerous' routine to call,
so I thought I'd just check that this is ok to do. I think it should be
safe as the dialog ensures only one project can be open, and it is only
used for the batch processing.

Thanks,
Dan

Index: src/BatchProcessDialog.cpp
===================================================================
RCS file: /cvsroot/audacity/audacity-src/src/BatchProcessDialog.cpp,v
retrieving revision 1.29
diff -u -r1.29 BatchProcessDialog.cpp
--- src/BatchProcessDialog.cpp 21 Jun 2009 20:56:00 -0000 1.29
+++ src/BatchProcessDialog.cpp 3 Jul 2009 13:48:04 -0000
@@ -34,6 +34,7 @@
 
 #include "Prefs.h"
 #include "Project.h"
+#include "DirManager.h"
 #include "BatchProcessDialog.h"
 #include "Internat.h"
 #include "commands/CommandManager.h"
@@ -291,6 +292,7 @@
       if (!d.IsShown() || mAbort) {
          break;
       }
+      DirManager::CleanTempDir();
    }
    project->OnRemoveTracks();
 }

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Richard Ash]

On Fri, 2009-07-03 at 15:02 +0100, Dan Horgan wrote:
> I tried inserting a direct call to DirManager::CleanTempDir() in the
> relevant place (see patch) and this seems to work in the testing I've
> done.  However, it seems like a potentially 'dangerous' routine to call,
> so I thought I'd just check that this is ok to do. I think it should be
> safe as the dialog ensures only one project can be open, and it is only
> used for the batch processing.

I'm not familiar with the code, but it would be nice to ensure that we
were only flushing the temp files for the current project, not the whole
of audacity (which is what I read the call to CleanTempDir() as doing).

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


------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dan Horgan]

On Fri, Jul 03, 2009 at 10:31:46PM +0100, Richard Ash wrote:

> On Fri, 2009-07-03 at 15:02 +0100, Dan Horgan wrote:
> > I tried inserting a direct call to DirManager::CleanTempDir() in the
> > relevant place (see patch) and this seems to work in the testing I've
> > done.  However, it seems like a potentially 'dangerous' routine to call,
> > so I thought I'd just check that this is ok to do. I think it should be
> > safe as the dialog ensures only one project can be open, and it is only
> > used for the batch processing.
>
> I'm not familiar with the code, but it would be nice to ensure that we
> were only flushing the temp files for the current project, not the whole
> of audacity (which is what I read the call to CleanTempDir() as doing).

Ah yes - that is what it does; I was under the mistaken impression that
the batch processing dialog checked that only one project was open (and
empty). Instead it just checks that the active project is empty.

> 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


------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dan Horgan]

On Fri, Jul 3, 2009 at 10:59 PM, Dan Horgan<[hidden email]> 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

Ok, I've committed this following brief testing. Temporary files are
removed between applications of the chain as expected, and it doesn't
interfere with other projects as far as I can tell.

In batch mode, is there actually any need to save undo history between
steps in the first place? It might be better to save it once, before
the chain is applied. This would save disk space and would also make
it easy to undo the chain all in one go, which might be better from a
usability point of view.

Dan

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Dan Horgan wrote:

> On Fri, Jul 3, 2009 at 10:59 PM, Dan Horgan<[hidden email]> 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
>
> Ok, I've committed this following brief testing. Temporary files are
> removed between applications of the chain as expected, and it doesn't
> interfere with other projects as far as I can tell.
>
> In batch mode, is there actually any need to save undo history between
> steps in the first place? It might be better to save it once, before
> the chain is applied. This would save disk space and would also make
> it easy to undo the chain all in one go, which might be better from a
> usability point of view.

Apply chain, undo chain, sounds logical to me.

Martyn

> Dan
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Richard Ash <[hidden email]>
| Fri, 03 Jul 2009 22:31:46 +0100
| Subject: [Audacity-devel] Possible fix for 'Chains applied to files do not clear temporary files after processing each file' ?

> On Fri, 2009-07-03 at 15:02 +0100, Dan Horgan wrote:
> > I tried inserting a direct call to DirManager::CleanTempDir() in the
> > relevant place (see patch) and this seems to work in the testing I've
> > done.  However, it seems like a potentially 'dangerous' routine to call,
> > so I thought I'd just check that this is ok to do. I think it should be
> > safe as the dialog ensures only one project can be open, and it is only
> > used for the batch processing.
>
> ... 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?

I'm not aware of any demand from users to do that, and wonder
if undo for each step of the chain might still be appreciated when
applying chains to the current project?

I think users should at least be able to have an "Undo Chain"
entry, which would save the disk space otherwise needed for
each step of the chain. I assume that's what you envisage.



Gale  



------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Martyn Shaw <[hidden email]>
| 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<[hidden email]> 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
> >
> > Ok, I've committed this following brief testing. Temporary files are
> > removed between applications of the chain as expected, and it doesn't
> > interfere with other projects as far as I can tell.
> >
> > In batch mode, is there actually any need to save undo history between
> > steps in the first place? It might be better to save it once, before
> > the chain is applied. This would save disk space and would also make
> > it easy to undo the chain all in one go, which might be better from a
> > usability point of view.
>
> 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.



Gale
 

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dan Horgan]

On Sat, Jul 04, 2009 at 03:44:09AM +0100, Gale Andrews wrote:

>
> | From Martyn Shaw <[hidden email]>
> | 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<[hidden email]> 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
> > >
> > > Ok, I've committed this following brief testing. Temporary files are
> > > removed between applications of the chain as expected, and it doesn't
> > > interfere with other projects as far as I can tell.
> > >
> > > In batch mode, is there actually any need to save undo history between
> > > steps in the first place? It might be better to save it once, before
> > > the chain is applied. This would save disk space and would also make
> > > it easy to undo the chain all in one go, which might be better from a
> > > usability point of view.
> >
> > 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.
>
>
>
> Gale
>  

I've committed a change to do this so we can see what it's like -
it shouldn't be hard to change back if we decide against it.

I think I prefer it this way, although I haven't needed to use batch
chains much for actual work so it's difficult to judge. If it is
reasonable to think of a chain as a fixed sequence of effects that the
user builds once and then uses several times, I think being able to undo
it in one step is logical as the user probably wouldn't want to be
concerned with the individual items in the chain at the time when they
apply it. But I don't know whether that's how it is actually used (or
even whether that's how it's intended to be used).
One thing which doesn't really agree with this way of thinking about it
is the possibility of having 'export' commands in the chain - which
can't really be undone.
But one the whole I think I'm still in favour of undo in one go, since I
suspect in the majority of cases it makes more sense and it does save
disk space.

Thanks,
Dan

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Richard Ash]

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 <[hidden email]>
> > | 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<[hidden email]> 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.
 

> I've committed a change to do this so we can see what it's like -
> it shouldn't be hard to change back if we decide against it.
>
> I think I prefer it this way, although I haven't needed to use batch
> chains much for actual work so it's difficult to judge. If it is
> reasonable to think of a chain as a fixed sequence of effects that the
> user builds once and then uses several times, I think being able to undo
> it in one step is logical as the user probably wouldn't want to be
> concerned with the individual items in the chain at the time when they
> apply it. But I don't know whether that's how it is actually used (or
> even whether that's how it's intended to be used).

I think that's what I would see as the intended usage, so that if you
know you need to mix and match effects to build a meta-effect, you can
use Chains to do so.

> One thing which doesn't really agree with this way of thinking about it
> is the possibility of having 'export' commands in the chain - which
> can't really be undone.
You can't undo the exported files off the disk, but you can restore the
_project_ to the previous state - which short of a time machine is about
all you can hope for.

On very cursory testing, looks like this is working - thanks!

Richard


------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Alec Burgess-2]

Some javascript/style in this post has been disabled (why?)

Dan Horgan ([hidden email]) wrote (in part)  (on 2009-07-06 at
09:51):
> On Sat, Jul 04, 2009 at 03:44:09AM +0100, Gale Andrews wrote:
> > >
> > > | From Martyn Shaw [hidden email]
> > > | 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[hidden email] 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
> >>> > > >
> >>> > > > Ok, I've committed this following brief testing. Temporary
> files are
> >>> > > > removed between applications of the chain as expected, and
> it doesn't
> >>> > > > interfere with other projects as far as I can tell.
> >>> > > >
> >>> > > > In batch mode, is there actually any need to save undo
> history between
> >>> > > > steps in the first place? It might be better to save it
> once, before
> >>> > > > the chain is applied. This would save disk space and would
> also make
> >>> > > > it easy to undo the chain all in one go, which might be
> better from a
> >>> > > > usability point of view.
> >> > >
> >> > > 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.
> > >
> > >
> > >
> > > Gale
> > > 
>
> I've committed a change to do this so we can see what it's like -
> it shouldn't be hard to change back if we decide against it.
>
> I think I prefer it this way, although I haven't needed to use batch
> chains much for actual work so it's difficult to judge. If it is
> reasonable to think of a chain as a fixed sequence of effects that the
> user builds once and then uses several times, I think being able to
> undo
> it in one step is logical as the user probably wouldn't want to be
> concerned with the individual items in the chain at the time when they
> apply it. But I don't know whether that's how it is actually used (or
> even whether that's how it's intended to be used).
> One thing which doesn't really agree with this way of thinking about
> it
> is the possibility of having 'export' commands in the chain - which
> can't really be undone.
> But one the whole I think I'm still in favour of undo in one go,
> since I
> suspect in the majority of cases it makes more sense and it does save
> disk space.

When developing and testing the chain, would it be useful for user (optionally before running the chain) to request that separate steps be "undoable" so he can walk back through the chain to find problem(s), tweak individual step(s) and then rerun the chain?


------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Dan Horgan]

On Mon, Jul 06, 2009 at 04:48:52PM -0400, Alec Burgess wrote:

>
> Dan Horgan ([hidden email]) wrote (in part)  (on 2009-07-06 at
> 09:51):
>>  [snip]
>>  I've committed a change to do this so we can see what it's like -
>>  it shouldn't be hard to change back if we decide against it.
>>
>>  I think I prefer it this way, although I haven't needed to use batch
>>  chains much for actual work so it's difficult to judge. If it is
>>  reasonable to think of a chain as a fixed sequence of effects that the
>>  user builds once and then uses several times, I think being able to
>>  undo
>>  it in one step is logical as the user probably wouldn't want to be
>>  concerned with the individual items in the chain at the time when they
>>  apply it. But I don't know whether that's how it is actually used (or
>>  even whether that's how it's intended to be used).
>>  One thing which doesn't really agree with this way of thinking about
>>  it
>>  is the possibility of having 'export' commands in the chain - which
>>  can't really be undone.
>>  But one the whole I think I'm still in favour of undo in one go,
>>  since I
>>  suspect in the majority of cases it makes more sense and it does save
>>  disk space.
>
> When developing and testing the chain, would it be useful for user  
> (optionally before running the chain) to request that separate steps be  
> "undoable" so he can walk back through the chain to find problem(s),  
> tweak individual step(s) and then rerun the chain?
>

Perhaps... should it be a preference in that case? I'm not sure how
different this would be to just applying the effects one by one to work
out what the chain should be before actually creating it.
Ideally there'd probably be some kind of separate mode for developing a
chain, which would allow this and other features like a preview for the
whole chain.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Richard Ash <[hidden email]>
| 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 <[hidden email]>
> > > | 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<[hidden email]> 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
   



------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

> Gale (Audacity Team) wrote:
> > Richard wrote:
> > 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.
>
> ...as it was before, you could undo stepwise so you
> could exactly get back to an intermediate position.

Hi Dan

One thing I noticed is that if you stop or cancel the chain, you still have the "Undo Apply 'Chain name' " menu entry. I assume you would want to remove the Undo history in that case, as when stopping or cancelling an individual effect.


Gale

[Dan Horgan]

On Tue, Jul 07, 2009 at 06:52:05PM -0700, Gale (Audacity Team) wrote:

>
> > Gale (Audacity Team) wrote:
> > > Richard wrote:
> > > 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.
> >
> > ...as it was before, you could undo stepwise so you
> > could exactly get back to an intermediate position.
>
> Hi Dan
>
> One thing I noticed is that if you stop or cancel the chain, you still have
> the "Undo Apply 'Chain name' " menu entry. I assume you would want to remove
> the Undo history in that case, as when stopping or cancelling an individual
> effect.
>
>
> Gale

Thanks, I should have noticed this... I've changed it now so that the
new state is only saved if the whole chain completed successfully. I've
also made it so that in all other cases, the state is reverted back to
how it was before the chain was started. So it should no longer be
possible for the results of a 'half-applied' chain to be left lying
around. This is, I think, consistent with how normal effects behave, and
so fits in with the idea of chains as 'meta-effects'.

Dan

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel