[ardour-dev] Re: [ardour-users] MTC & MMC - CORRECTION
paul at linuxaudiosystems.com
Wed Sep 22 18:23:54 PDT 2004
>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
>> 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
>> MTC is the MIDI implemention of the SMPTE standard, so that SMPTE time
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
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
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
it includes a Locate command, which is more like what you are thinking
More information about the Ardour-Dev