Re: [QLab] SMPTE Timecode Input

[Dave "luckydave" Memory]

On Tuesday, May 14, 2013 at 9:42 AM, ma...@matthewcotter.com wrote:

Im using an external source of timecode to trigger cues in a cuelist.  I have confirmed the correct input source and am seeing Timecode roll in the new Timecode View Window.  My external track starts at 02:00:00:00.  When I run the track the viewer within QLab starts tracking the timecode, however it starts counting up from 00:00:00:00.  This happens regardless of the source TC.  If I pause the external track and restart it, I'd expect the TC value in the window to mimic my external source.  However it starts at 00:00:00:00 again, even if the external source is 02:03:00:00.

Linear timecode (what most people call SMPTE timecode, but essentially, timecode that is an audio track, rather than MIDI Timecode) takes at least a second to sync up, because between the seconds, it only sends frames, with no reference to where they are in time relative to other seconds. If you let it roll for a second or two, do you see the same thing? It's always important to account for pre-roll when using timecode for this reason.

-- 

luck...@figure53.com 

[ma...@matthewcotter.com]

Hi~

Yes.  Using Linear Timecode based on the SMPTE standard, vs. midi timecode.  

Im just doing basic testing at this point, so even if the first few cues were not fired or delayed based on QLab needing sufficient pre-roll, the problem still exists even beyond the 5 second mark.  Regardless of where I start the external source, be it, 02:00:05:00 or 10:08:03:19, the Timecode window always starts counting up from 00:00:00:00.  The hours/minutes/seconds/frames all start at 0.  If Im sourcing 02:00:05:00, I'd expect to see 02:00:05:00 in the viewer, even if having to wait for a second to see it sync up.

Additionally, when in a timecode sync enabled cuelist, when I go edit the timecode trigger; I enable the timecode checkbox, and the value defaults to 01:00:00:00, I then try and adjust the time to 01:03:21:00, if I TAB out of the box, or hit ENTER. The value automatically resets to 01:00:00:00.

On a side note, I've actually had great success with lighting consoles, EVS playback systems and various show control systems syncing up within a few frames, not full seconds.  Anything requiring that long of a pre-roll wouldn't last very long in live entertainment environment.  

Thanks in advance for the help!

Matt

[Rich Walsh]

On 14 May 2013, at 14:44, Dave luckydave Memory <luck...@figure53.com> wrote:

> Linear timecode (what most people call SMPTE timecode, but essentially, timecode that is an audio track, rather than MIDI Timecode) takes at least a second to sync up, because between the seconds, it only sends frames, with no reference to where they are in time relative to other seconds. If you let it roll for a second or two, do you see the same thing? It's always important to account for pre-roll when using timecode for this reason.

I don't think this is right. I haven't had time to go through the text books, but I'm pretty sure that there is ample bandwidth in an audio signal to send the full 80-bit LTC word every frame, and each word contains a full positional reference. So, LTC tells you exactly what frame you are at every frame, and I've seen it achieve sync in as little as 2 frames.

MTC, by contrast, does not have the bandwidth to send a full positional reference with each "word" and it takes 8 quarter frame messages (ie: 2 frames) to determine the current time…

Rich