[LAD] interesting blog post about syncing blender and ardour

[Fons Adriaensen]

On Thu, Sep 24, 2009 at 06:37:56PM -0400, 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.

Interesting ?

* How can this option be modified ?
* If varyspeed slaving is enabled, 

  - How many channels can be resampled ? 
    On my 2G P4 libsamplerate has trouble with 
    just 5 channels in real time.
  - Will Ardour resample signals being recorderd
    as well ?

Note that the latter is essential. If a signal is recorded
with some speed error, and then played back with the same
speed error the result should be the original signal. Since
it will be resampled on playback it has to be resampled on
record as well, in the opposite direction.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.