Wrong LTC-timecode decoding. Timecode sending from Qlab. Lockstep shows 00 hours, VDMX shows 24 hours. Is this bug?
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.
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!
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
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!
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 ;)