Subject: [linux-audio-dev] [ ardour news ] ardour now using an EDL
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Oct 19 2000 - 17:19:45 EEST
[ this is mostly a copy of message sent to ardour-dev, but i thought
that some people here might like to see it too.
]
ardour is now using an EDL, at least for playback.
--- What's an EDL ? --------------------------------------------------
for those who don't know, an Edit Decision List is an abstract
representation of the state of a data stream, reflecting a series of
operations that have been performed on it. More specifically, it is a
way for performing non-destructive editing because instead of simply
reading a stream of bytes from a file, an EDL provides you with a way
to re-order the data stream as it is read. for example, if we perform
a "delete" operation on the middle section of a file, that simply
means that during playback, when we reach the start of the "deleted"
section, we just skip to the end of it, and continue from there. the
same is true of inserts and replaced regions. note that the underlying
disk file has not been altered in any way by these operations.
other kinds of edit operations that are by nature "destructive" (they
*must* change the data) are implemented differently. see the next
paragraph.
--- So What Have You Been Doing ? ------------------------------------
i have spent the last couple of days working on a C implementation of
an EDL. it has been done in C with the hope that it might be used by
more people than just myself. i have done about 85% of the testing it
truly needs. destructive editing operations are performed using the
so-called "Add File" model. we create a new file, copy the region to
be modified into it, then perform the edit. then we modify the EDL to
point to the new file for the duration of the region.
--- Implications for Ardour --------------------------------
this is a *momentous* change to ardour, because it means that we can
have an editor perform operations on the EDL, and ardour will be able
to playback the result.
in the degenerate case, as in ardour right now, we have an EDL
containing a single region - the entire track file. this is a very
simple case, and other the code path compared to the one for pread(2)
is almost the same; the difference is irrelevant given that the
typical disk read in ardour takes at least 1-2msec.
--- Implications for Editing -----------------------------------------
i have recently come to the conclusion that no existing linux
soundfile editor is capable of being used as the supporting editor for
ardour. this is primarily because of the necessity for doing disk i/o
in another thread during playback. if the editor cannot playback, then
its not of much use, is it ? well, the editor could ask ardour to do
the playback, but if the editor did edits, how would ardour find them ?
there are two options: either the editor rewrote the disk file, or it
used an EDL shared between them. Rewriting the disk file is *BAD*. Bad
for two reasons (1) its destructive editing, and nobody expects this
anymore (2) its going to be amazingly slow with real recordings.
so, the editor has to use an EDL, and ardour has to be able to read
it.
---- OK, so what now ? -----------------------------------------------
The second part of those two has now been done. i am going to try to
consider how ardour's recording operation should tie into the EDL (it
may not, for example), tidy up the EDL library, and then try to polish
off the remaining tasks needed for a 1.0.0pre release of ardour.
i will also be working on part one: a new editor. it will be rely very
heavily on the capabilities of GtkWaveForm, which appears to me be a
fanastic base to work from. it comes with support built in for up to
32 channels of up to 32 bit samples. i anticipate stealing ideas from
snd, sweep and other open source editors, not to mention CoolEdit,
Samplitude and Bias Peak, as i go along.
as they say around here, have a nice day,
--p
This archive was generated by hypermail 2b28 : Thu Oct 19 2000 - 17:53:13 EEST