Re: [LAD] interesting blog post about syncing blender and ardour

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@email-addr-hidden> 
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@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> 
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev