[ardour-dev] Re: [ardour-users] MTC & MMC - CORRECTION

[Paul Davis]

>Correction:  sorry, but I refer to song position pointers - that's not
>actually accurate - song position pointers are used in conjunction with MIDI
>Clocks, which is another, older, MIDI way of syncing (MIDI clocks slave by
>tempo - it's not time code)

this is not your only error, i'm afraid.

>>	   now I assume if ardour was SENDING MTC, the slave machines would
>> follow any slow downs (that's what you want) - that said, what about
>> implementing MTC SEND?  is that a harder thing to do?  why are we focusing

that's far from clear. the extent to which MTC/SMPTE slaves follow
"varispeed" from the master is implementation dependent. its not clear
to that most MTC slave devices are capable of handling varispeed
correctly; how they respond to "burps" in the MTC stream is also undefined.
some even have configurable options to define the length of a "burp".

>> on MTC slave?  in practice, I'd actually rather have the multitracker be
>the
>> master of the time code.

because no Linux box can currently deliver MTC correctly. it requires
an interrupt-driven timer with a resolution measured in hundreds of
usecs. approximate it using 1msec timer? perhaps. but some devices
won't lock to it.

>> my staunch opinion always has been and remains that implementing MTC as
>> opposed to straight SMPTE will be far more useful - most gear these days
>> deals with MTC and NOT straight SMPTE.

but MTC is a discrete "packetized" protocol; SMPTE is a continuous
stream. guess what kind of signal ardour handles more easily ...

>> bear in mind that there is no practical, in-use difference between the
>two -
>> MTC is the MIDI implemention of the SMPTE standard, so that SMPTE time
>code

as mentioned above, there are very big differences in implementation
details that make a huge difference.

>> can be sent over the MIDI stream (without having to have an audio track
>> recorded, or a BNC connector for SMPTE - that's why it makes sense that
>most

you can send SMPTE over any audio connection.

>> But I'm not totally convinced of that if what we're calling MTC
>> implementation is just Ardour responding to MMC start, which is easy and
>has

the point is this: there is nothing about MTC that requires that a
slave has to chase it at all times. you might consider that a good
design, and i might not disagree with you. and in fact, ardour as
currently implemented should start the transport in response to
locking in to an MTC stream. 

>> what about ADAT sync?  just a thought.  I assume that would be harder, and
>> it's also less universally useful.  But it was on the list at one point.

ADAT sync is easily handleable, but currently no ALSA driver provides
ADAT sync to user-space. the code in ardour has been designed to
handle any positional sync source.

>> MTC obviously includes a start/stop command, coupled with a song position
>> pointer.

it includes a Locate command, which is more like what you are thinking
of.

--p