Subject: Re: [linux-audio-dev] Alsa Recording Software Programming HOWTO
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Tue Jun 27 2000 - 00:10:58 EEST
As David Olofson points out, this is a file management issue.
> >>>15. Don't overwrite
> >>>
> >>>Each new recording should go to a new file. For sure, recordist
> >doesn't
> >>>want the recorder overwrite files without asking.
> >>
> >>
> >>This is simply not true.
> >
> >But maybe it is true.
Please notice the "without asking" part. No one is saying that you
can't delete files any time you wish. The point is that the application
must force the user to be sure that the data to be deleted is truly
useless before allowing any data to be overwritten. In your own words:
> don't think you really want to do that, so you can't". i *do* like
> asking them "are you really sure you know what you're doing?".
In the heat of the moment, when the performers are in the groove, this
is not the time to ask the recording engineer to evaluate the potential
usefulness of a previous take before recording a new one. An
application that automatically generates a new file and auto-names it is
good, and such a feature must be included in any serious app. If you
want the option of allowing the recorder to overwrite to an existing
file, that's ok but now we are talking about granting the recorder
permission to modify an existing file and this is more of a file
management issue than a recording issue. Juhana said that file
management will be the next HOWTO but it seems to be a part of this one
too. Feature 17, gate recording, can also be accomplished with file
management.
> "virtual tracks" strike me as slightly misleading.
>
> if you write data to blocks of data without regard to which "virtual
> track" is in use (but obviously keeping track of which blocks you
> use), then its a reasonable term, but it doesn't really describe
> anything over and above what "EDL" implies.
>
> a track, from an operational point of view, seems to be "a place to
> put recorded material". talking about "virtual tracks" is very odd in
> this context. it seems to me to make more sense to use the terminology
> adopted by Mackie for their HDR system, and refer to "takes" when
> specifically referring to the idea of switching to an entirely new,
> semantically contiguous "place to put recorded material". when dealing
> with the possibilities of EDL's, such as jumping from material
> recorded on one track to material recorded on another, and back again,
> the term "virtual tracks" doesn't seem to help much.
The terms "virtual tracks" and "takes" are both historically accurate in
this context, and their use predates Mackie's entry to the digital audio
market. In fact "takes" are a subset of "virtual tracks". Virtual
tracks are the pool of soundfiles that are not assigned to a track for
playback, but are available to the application for the purpose of
creating the EDL's that will be assigned to playback tracks. Takes are
the most common form of virtual tracks, but they are a specific subset
and refer to a group of soundfiles that are different versions of a
single part in an arrangement of a single song. Individual takes are
not generally made available to songs other than the one for which it
was originally recorded, so unless I am specifically referring to this
case, I will use the term "virtual tracks". I have noticed that the
manufacturers of dedicated hdr's place unnecessary restrictions on the
availability of soundfiles between songs or across disk partitions,
presumably to create an "ease of use" abstraction for non-techie
musicians. Creating false barriers does not seem to be a design goal
here at lad.
> >With hdr there is no need for direct correlation between
> >physical tracks and the files that they are recorded to, it is a
virtual
>
> again, i find this all rather confusing terminology. a recording
> system typically has "tracks" and "channels". the "channels" are
> physical, the tracks are, in an HDR system, somewhat of an conceptual
> simplification because of EDL's. defining what emerges from a given
> channel when monitoring (or producing a master (say, stereo, or 5.1,
> or whatever), is the process of setting up the EDL.
Here I am referring to your stated desire to reuse existing file
allocation. In doing so you correlate the recording of a new take to
the same physical location on the disk as the old take, just like with
tape where you must record a new take to the same physical section of
the tape to maintain synchronization. Unless there is a disk
performance issue associated with seek time, or a file system issue
associated with the overhead of allocating for a new file, I see no
reason to consider recycling pre-existing file allocation.
> >one. A system that is only capable of accessing 24 simultaneous
tracks
> >can simply ignore existing files and create a new one, so there is no
> >need to record over an existing file.
>
> that depends on your disk space.
Yes but this is OZ, and here we have infinite disk space.
> >If the desire to allow over-writes is based on disk space, and not on
> >disk performance, then I think that you are being penny wise and
pound
> >foolish. As disk capacity is now on the order of 10 GB, a 280 MB
file
> >takes up less than 3% of the total disk space and is not worth
thinking
> >about during a recording session.
>
> this is nonsense. if i'm doing a 24 channel 32 bit session, and i'm
<lots of stuff removed>
> editing is 100% non-destructive already, but recording (particularly
> in "tracking" situations), which I view as a different task entirely
> from editing, has the option of being destructive or not, as the user
> sees fit.
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. And if not, then I
suppose that the file manager could be given authority to grant such
permission to the recorder, as an option, but I think that such an
option should be included only if a scenario can be identified where a
legitimate desire can not be met without it.
Tom
btw
David, Cakewalk isn't actually considered to be a top level program.
Anyone who has fully learned to use Cubase, Logic, Performer, or Vision
can detect Cakewalk's shortcomings quite easily, though for most people
these programs are overkill and Cakewalk gets the job done.
This archive was generated by hypermail 2b28 : Tue Jun 27 2000 - 00:30:18 EEST