LTC timecode decoding from Qlab

#1

Wrong LTC-timecode decoding. Timecode sending from Qlab. Lockstep shows 00 hours, VDMX shows 24 hours. Is this bug?

0 Likes

#2

0 Likes

#3

Hey!

I’ll see if we can recreate this, but please send us a bug report via the Help menu for this kind of stuff, along with exact steps we can follow to reproduce the issue.

0 Likes

#4

So with a quick test, I can totally reproduce this when sending from QLab, but not when I use a pre-generated LTC signal from an audio file.

I’ll need to follow up with the QLab team, but it looks like they are sending off +24 hours on their LTC, and Lockstep is set to loop after 24 hours, whereas VDMX lets the hour indicator keep climbing.

Here is a screenshot from when I tested with a pre-generated file, which I’ve attached here: LTC_00_58_00_00__1mins_30.wav.zip (745.1 KB)
(I generated this using http://elteesee.pehrhovey.net/)

If you can give this a try and let me know how it goes with this wav file (either way!) that would be great!

0 Likes

#5

Thank you for unswerving.

I did the same as you with generated audio files from el tee see site. Time in VDMX was correct.

But when I sent QLab LTC timecode to Light Console - Console shows correct time to. So I don’t know where is problem.

Many people using QLab for sending timecode.

So please try to fix this if is possible.

1 Like

#6

Yeah, I think that the general convention other apps use is to limit the hours to 0-23, so the QLab issue (if that is the case…) doesn’t present itself.

In addition to reaching out to their team I’ll look into making a similar change in VDMX for our next update for good measure – thanks for bringing this to our attention!

0 Likes

#7

PS This should be fixed in our next minor update, if anyone else runs into this odd case, hit me up and I’ll send you a link to test it out before we post it to the public ;)

0 Likes