> I don't see a way around this, you are always going to need lots of free
> space. For instance, if user loads a 500MB file, presses "select all" and
> the clicks some effect (normalize, compress, filter, noise-removal,
> ... quite common track-wide effects), you will have to have another 500MB
> of free space, if you want to offer non-destructive editing.

I've toyed with attaching a "parse tree" to the edit fragments,
so each fragment is run through a little program as part of
reading it (the simplest such thing is to have a "scaler"
imbedded in it, so scaling a file just copies the current
edit list and resets the scalers, or just wraps it in a
"let" from lisp's point of view); with a fast enough machine
it might be possible to go pretty far down this path.
All I need (besides 48 hours/day and another lifetime)
is one of those terahertz machines I read about.

Reply via email to