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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
