[LAD] interesting blog post about syncing blender and ardour

[Paul Davis]

On Tue, Sep 22, 2009 at 12:45 PM, Fons Adriaensen <fons at kokkinizita.net> wrote:
> An app decoding SMPTE to jack transport position would be needed if
> you want to slave a Jack app (e.g. Ardour) to SMPTE. This implies that
> the slaved app is able to adjust its speed over a small range while
> preserving full audio quality - the equivalent of a tape machine made
> to run slightly slow or fast. This means resampling, for both playback
> and recording. Since Ardour AFAIK can't do this, it can't be slaved to
> SMPTE or any other timecode that doesn't run in sync with the sample
> clock. It may locate to and start at the correct position, but since
> its speed is fixed it will not remain in sync while rolling.

this isn't quite correct. ardour can slave to "varispeed" sync
sources, and tracks them with remarkable accuracy. there is an option
that is on by default which tells ardour to expect the timecode source
to be sample-clock-locked to whatever is driving JACK. if it is
enabled, ardour won't bother to even look for speed fluctuations. if
it is off, ardour will do varispeeding to stay very very closely in
sync with the timecode source. this option cannot currently be changed
via the GUI.

however. JACK transport doesn't support varispeed, so you cannot
convert a varispeeding timecode source into JACK transport.