[LAD] interesting blog post about syncing blender and ardour

[Chris Goddard]

Actually, in 2.x, this is an option in the sync tab of the options window.

-- 
Cheers

Chris

On Thursday 24 Sep 2009 23:37:56 Paul Davis wrote:
> 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.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>