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

On Tue, Sep 22, 2009 at 11:36:24AM -0400, Paul Davis wrote:

> then either convince someone to finally write a JACK client that does
> the conversion between SMPTE and JACK Transport, or alternatively buy
> a SMPTE<->MTC converter box. they don't cost much (less than someone
> should get paid to write that client, thats for sure).

I did write such an SMPTE decoder almost five years ago. It should
be somewhere in the attic...

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.

Applications that just use Jack position and as a time reference,
and that don't record or playback audio but generate or trigger it
(e.g. sequencers), could do this more easily.

To use Ardour as the master controlling a slave expecting SMPTE, all
that is required is to 'stripe' your session, i.e. have an SMPTE track
along the full lenght. Once transport is rolling, the slave(s) will
receive the time code, locate if necessary and then sync. To make
them locate before transport is rolling some extra mechanism would
be required.

Ciao,

-- 
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev