MTCTriggering early

[Sebastian Frost]

Hi All,

I have an (as ever) urgent issue....

My somewhat convoluted cuelist is triggered by incoming MTC. But Qs are triggering ahead of time - variable, but approx 2 seconds BEFORE the trigger time.

Has anybody seen this behaviour before, and if so, what might be causing it?


FYI, I'm monitoring the incoming MTC using Timecode Display and this is in agreement with the display on my Rosendahl MIF4.

Many thanks,
Seb

[raymond soly]

Hummm, first thing 'comes to mind is mismatched MTC format for the timecode trigger.

Ray

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

[Sebastian Frost]

Update -

The MTC error gets worse as time continues through a 20min list. The Q at 6" fires correctly, but down at 19' it fires nearly 3" early??

Ray, that was my thought too, but Qlab is VERY picky when it comes to timecode and won't trigger at all if the Qlist frame rate doesn't match the incoming code - Andy/Dave, is this something that could be fixed as I'd rather have it trigger with an incorrect frame rate with a warning of error than not...

However, I switched to using LTC via an audio input and all my problems went away! Qs fire at the correct time...

Both Timecode Display and SMPTE Reader (handy little app!) both display the SAME time...

Also, this behaviour is identical on 2 machines that are running different, but synced Qlists. Admittedly, one Machine is running upto 240 Simultaneous (record? For me..) tracks of audio.......

So, all is working now, but I'd love to work out why the MTC error is occurring. 

Best wishes from Detroit....

Seb

Sent from my telephone

[Sebastian Frost]

Oops, apologies - meant too say Chris/Dave, but also applies to all the fabulous team @F53 .....

Sent from my telephone

[El Armstrong]

The drift makes me think it is a problem with Drop Frame vs Non Drop Frame time code.  In six seconds, the offset isn't a problem, but by twenty minutes in, it would be 60 frames which is 2 seconds. 

El

[Matt]

Hi Seb

Matt here. I agree with the last post - It's most likely a drop frame verses non drop frame issue and the way that Midi time code is decoded verses LTC time code. I had a problem I highlighted to the guys where the Drop Frame version of Timecode was not working correctly if you stream out from Qlab. I can't find the responses currently but, I'm guessing if you are in Detroit you are at the car show and thus getting the timecode from a Video Source and being American its 29.97 frame rate [thus 30 drop frame] and this is casing you issues. Try changing your settings in Qlab to 30 Frame NON drop frame, and don't have any triggers in the 28th or 29th frames and you should find this goes away. If it's film based and it's 23.97 change to 24 non drop and don't have any triggers in the 22nd or 23rd frames and again you should be ok. Midi TC is decoded based on incomming bytes as numbers so every other field contains half the info and then there is a high part of the byte and low part of the byte that decodes the high part of a Frame low part of a Frame, high low seconds, high low minutes, Hours and Frame rate depending upon a header byte. Audio LTC is not decoded this way, it has everything encoded in one chunk, and doesn't care if certain frames are missed, in fact devices have to be more tolerant as in the old days on tape the speed could and would fluctuate and drop out.

Matt Howes

[Rich Walsh]

QLab doesn't _chase_ timecode, so how can it display a cumulative drift like this?

Essentially all a TC trigger is doing is assigning a specific string to start the cue, just like a normal MIDI trigger. If QLab doesn't see the TC code for the ONE single frame event that will trigger a cue, that cue does not fire. For MTC this requires correctly receiving and decoding 8 MIDI messages of the form $F1 $nd, where n identifies the data type and d is the data. The frame rate is in byte 7d, so if it's not the same as the frame rate set in the ONE single string that will trigger the cue, the cue will not fire.

Are the cues that are 3 seconds early 19 minutes in still 3 seconds early when you jump the TC stream forward, or is the error a function of how long the TC has been running? Don't forget that you can't change a TC trigger whilst receiving TC and have it update.

Rich

[Sebastian Frost]

Hi Rich,

Matt and El must be on the right kind of track - the 'drift' occurs even if the TC is started just prior to a Q @19'. I'll try and do a test with a Q @1hr and see if the drift is correspondingly increased.

Matt, you're correct as to my current location... and I can't change the source (GV Turbo) to give me 30fpsND - it's currently 30drop. I know this should be an option but not in this case... However, as Rich mentioned, Qlab won't accept TC at a different frame rate to that which is set in the Qlist settings tab.

[El Armstrong]

Rich, you're right, of course.  I had forgotten that Qlab doesn't chase.  Blame it on the late night.

However, the timing of the drift does looks suspiciously like what you would see in drop/non-drop differences.

El


Rich Walsh wrote:

[Sean Dougall]

Dropframe and non-drop are actually different timecode formats, so if you pick the wrong one, QLab won't trigger at all (just as if you selected 24fps and received 25fps). My first thought was that the difference could come down to video speed vs film speed -- e.g. 29.97 is the same timecode format as 30, but at a 0.1% slower rate. However, that would only result in a discrepancy of 1.14 seconds after 19 minutes -- and would only apply if TC started rolling from the top, not if it started right before 19 minutes -- so I'm not sure that's the root cause in this case.

FWIW, QLab does indeed trigger based on an individual frame and wouldn't normally show any drift of this sort over time. But you could still potentially fool yourself if you get them mixed up. For example, if you have a cue at 1:00:00:00 and want another cue 10 minutes later, you might put in 1:10:00:00 -- but if QLab then receives timecode at video speed (29.97/23.976/24.975), the real time difference between the cues will actually be 10 minutes and 0.6 seconds. (Though in that case, switching to LTC wouldn't fix anything, so I'm stumped as to the original problem.)

Sean

[deepvisual]

I remember having a Qlab bug that was fixed in later versions, where LTC timecode values less than one hour were not triggering correctly. Might just be worth checking this isnt the case here.