not at all :) the problem is that MTC is almost impossible for us to generate in a way that other devices will lock to. i say "almost impossible" because i believe that the "firm timers" work in 2.5/2.6 will probably fix this. its hard because although other devices see the MTC that (say) ardour emits, but they note that it doesn't arrive at regular 1-video-frame intervals. instead, its "bursty", following some clock other than the steady passage of SMPTE time (the clock might be the audio interrupt, or the RTC, etc.). my thought was that i could avoid this by actually emitting SMPTE itself, which is an audio stream, and thus can be generated with perfect sample accuracy as we go. this can then allow people with equipment that can read a SMPTE signal and/or convert it to MTC to get their devices to lock to Ardour's timecode, rather than respond to it. this is important because some devices will not handle or emit requests to record correctly when they can't lock to timecode. i still think that using SMTPE as the standard for audio timing is absurd. --p