2 Jun
2009
2 Jun
'09
5:28 p.m.
On Tue, Jun 2, 2009 at 12:46 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Tue, Jun 02, 2009 at 12:20:47PM -0400, Paul Davis
wrote:
there are "hidden" options. the default settings assume that the
timecode source and the audio interface that is driving JACK share a
sample/word clock, so that 1 second of timecode time == 1 second of
audio samples, and thus no varispeeding is necessary. essentially, we
just notice that timecode starts, stops and jumps non-linearly, and
respond appropriately.
however, you can change this setting (there is no GUI for it because
i've yet to find anyone who can actually defend adding this option to
the GUI), and in that mode ardour will varispeed to stay locked to the
master. it will stay locked to within 8-30 samples of the master's
timecode position. the varispeed interpolation (linear, fixed point)
is weak, and so technically quality will suffer. whether its suffering
worth fixing is a matter that reasonable people might reasonably
disagree about.
when i initially developed MTC slaving, i used an Alesis M20 ADAT
*without* sample/word clock sync. ardour would follow the wow+flutter
of the M20 perfectly. it would even follow it if i used the
shuttle/scrub controller on the M20.
Ardour syncs to MTC, which is just re-encoded
timecode. I've been told
by a company that specializes in timecode sync hardware that it syncs
faster and more accurately than any other product in the market place.
Is that sync with varispeed ? If the analog machine
runs 0.5% slow because it has been a long day, will
Ardour do the same, and without loss of quality ?