Subject: Re: [linux-audio-dev] Alsa Recording Software Programming HOWTO
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Jun 27 2000 - 05:03:10 EEST
>And I see file management as being a different task entirely from
>recording, and if a file already exists on a disk then it has crossed
>the line and is no longer the property of the recorder. There are lots
>of reasons for wanting to delete files, and for not wanting to wait to
>do it later when you are sure that you want to delete it now. An
>elegant file manager, yet to be seen by me in the world of audio, that
>allowed the user to see the names and sizes of all soundfiles on the
>local drives, which projects use the files, which regions of the file
>are referred to in EDL's, which projects use them, which regions of a
>soundfile are not referred to by any EDL in any project, whether the
>files are archived or not, a catalog of the archive, a list of all files
>not on the local drives that are referred to by projects that are on the
>local drive, and provided for file naming, auto-naming, renaming,
>deleting, compacting, and archiving, all presented in a way that is not
>visually overwhelming, would probably allow you to forget about allowing
>the recorder to overwrite pre-existing files.
I broadly agree with this, but with one proviso. I don't think the
user wants anything to do with files, filenames or disks. Ever. Its
terribly confusing, and EDL's make it even more so. No matter how good
a job you do with a UI, once you have an EDL that is referencing
interlaced regions of multiple files, the chances of the user
accidentally bungling a cleanup are quite high if you let them specify
things in terms of files.
Thats why the "compact audio data" option is the only reasonable way
to present this to the user. If they want to get behind this, let them
use the command line and rm. :)
While recording, the only option that is required is "replace previous
take", which would re-use one or more existing disk allocations. This
avoids silly and inefficient use of your "infinite disk space" - after
all, its been centuries since Cantor pointed out the many classes of
infinity, and it should be self-evident that the "infinite creativity"
of musicians is in a class that exceeds the order of "infinite disk
space" :)
Please understand that it is entirely my goal to get the next version
of Ardour (once 1.0 makes it "out the door", and its close) to use
something very very much like the scheme you describe. The *only*
reason it doesn't do that right now is that I wanted tight integration
with a sound editor from early on, and snd's EDL system is hard to
understand and integrate into a scheme with multi-threaded disk i/o.
Note, however, that my experience of DAW's has been that their
recorder interface is confusing. Its rarely clear precisely what
you're doing, you just have to sort of go "on faith" that you have
things set up right (combined with the optimism engendered by a 100%
non-destructive system). I believe that this is partly because of the
interaction model they present, which is completely different from the
one presented by tape systems. I think that the tape model is just
fundamentally more in-line with the conceptual model of what the user
is trying to do - the DAW model is more in-line with how the software
is actually doing it.
I currently believe (or is it just "hope" ?) that its possible to
combine the best of both worlds: the 100% non-destructive system
(except when explicitly and easily over-ridden) with the interaction
model of a tape deck. I will be interested to see if this is really
practicable.
--p
This archive was generated by hypermail 2b28 : Tue Jun 27 2000 - 05:42:12 EEST