[linux-audio-dev] fyi: whats going on with ardour

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] fyi: whats going on with ardour
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Dec 13 2000 - 22:13:42 EET


i've recently been digesting the 432-page pro-tools reference manual.

as a result of the inspiration from doing so, it seemed inevitable to
me that i would need the patchbay/router infrastructure in order to
make forward progress on a number of sticking points, including the
major one: xfades at edit points. i'm probably about 75% of the way
through the tricky part of switching to using the patchbay/router
object.

at the same time, i am abandoning completely the "dynamically created
xfades" that took me so long to get right this spring. all xfades will
be created post-facto, using a single standard mechanism. i wish i
could tell you exactly what that was, but i can't right now :) as a
result, for the near term future, ardour will be a little broken when
it comes to punch-in/punch-out, since it will produce brittle and
abrupt terminations.

one nice part of doing this is that i have readopted the use of my old
friend, the lock-free, fixed-sized ringbuffer for the buffer structure
used between the audio and butler threads. this has made the code in
Track::roll() very much simpler to comprehend, at least for now. i
believe it also helps with a vaguely noticeable reduction in system
load. OTOH, in my development tree, there is no monitoring either.

in the meantime, ardour has gained a 64 bus architecture. tracks can
be assigned either to physical output channels or a bus. they will
soon be able to be assigned to multiple busses (read: panning and
surround sound).

the protools manual is a good read. some things are really amazingly
bad: did you know that you have to restart your *computer* if you
change the equivalent of frames-per-cycle ? hell, i'm about to make
that changeable directly from the GUI!

their xfade methodology is interesting, but its indelibly tied into
the fundamental unit within a protools session being a "region". they
don't encourage the notion of the track as an unbroken stream of sound
at all: all your work really consists of defining and then
manipulating "regions".

they create xfades on disk, and effectively splice them into the
playlist at the right point. however, you can't cut-and-paste, as far
as i can tell, if your edit begins and/or starts in the middle of an
xfade, and xfaded material definitely seems to have "special status".

anyway, on with the show. at some point, i'll make up a list of things
from protools that seem really worth adding.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Dec 13 2000 - 23:05:45 EET