Re: [Audacity-devel] Re: 3 Audacity 1.1.3 Comments.

[Dominic M. <do...@mi...>]

Dave Fancella wrote:
> On Wednesday 09 April 2003 01:13 am, Dominic Mazzoni wrote:
> 
> <snip>
> 
>>Here are the issues we'd have to work out:
>>
>>1. What to do about Undo?  If we really overwrite the original
>>    file, then we'd have to erase the Undo history.  I'd argue
>>    against this - lots of people are now used to Audacity
>>    letting you Undo, even after you Save.
>>
>>    Maybe we should keep the original file around (renamed) until
>>    they either save the project or quit, at which point we could
>>    delete the old version of the file.  If we do this, then
>>    we'd need to reference-count aliased files.
> 
> I'd definitely like to keep the original around somewhere.  How about 
> something like either a subdirectory in the data directory, or just moving 
> the original to the data directory?  When you import, you can have a prompt
> (or a checkbox) that lets you chose between copying and moving the file to 
> the data directory.  How you do it gets important when you're dealing with 
> the probability in Linux of copying/moving across partitions (although the 
> two admittedly wind up doing the same thing).  Then a warning that says 
> something like "Certain functions of audacity will be unusable in this 
> condition" when you edit the file in place without copying/moving it.

I don't like disabling features, and I don't think we should ever move a
file between volumes without the user's permission.  Renaming the file
in place is the least intrusive thing I can think of.

>>2. We should probably add a command to make a project self-contained,
>>    i.e. get rid of all aliases.  That way people could take
>>    advantage of the aliasing to import files quickly, but could
>>    save a self-contained project at some later point.
> 
> This would essentially break down the original wave into a bunch of smaller 
> .au files and store them in a data directory, correct?

Yes

>>On a slightly different topic:
>>
>>* For crash recovery, I'm thinking of dumping out a complete
>>   project file EVERY time we push state.  I'd fix it so that
>>   changing the selection and stuff like that does not push
>>   state.  Let's see how well this scales.  If this really
>>   works, then recovering data directories without a project
>>   file becomes less important.
> 
> Worth investigating, the project file is just a (theoretically) small text 
> file, right?  Would it be worth it to have a file in the data directory that 
> just chains all the .au files together?  You'd have to deal with updating 
> this file constantly, and it would do almost everything the project file 
> already does, of course.  The idea, though, is that if you have to restore 
> from a crash and there's no project file available, this file would at least 
> tell you what .au's go together, even if you have to re-mix the whole thing 
> and redo all your labels.

Yes, that's the idea.

> Just my .02 cents.  :)
> 
> Dave
> 
> 
>>- Dominic
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Audacity-devel mailing list
>>Aud...@li...
>>https://lists.sourceforge.net/lists/listinfo/audacity-devel
> 
>