SMPTE Timecoded show jumping to end

Hello,

I am an issue sporatically with my Road Hog console running SMPTE 30 over LTC widget. The playback will snap to the last cue containing a timecode value. It only happens at one of two times (the show has two timecoded segments, and for the section between them another cueslist is run manually), and both of those are when timecode has just been enabled on the list. It never occurs in the middle of a timecoded segment, only when timecode starts up after a period of being stopped. This issue seems to occur most often only at least the second time the show is run after the console after booted. Also there seems to be no way to predict when it will or will not go wrong, sometimes it goes a month between occurences and sometimes it is twice in the same week.

The console is running 3.2.1 although the issue was present before that upgrade I believe. My "Jump after" setting is 60 frames to give SMPTE plenty of time to stabilize and also I have tried more than one LTC widget with no difference.

It is a nuisance because the first cue in each segment is a slow fade up and only with a couple of lights, whereas the last cue in the show is the brightest state of the whole show so essentially it blasts the whole audience with bright light and completely ruins the opening of the show because it takes a few seconds to correct it each time.

Any advice/assistance in any form would be greatly appreciated.

(posted this in another forum too but then realized this is the more appropriate location given that I am using the most recent software version)
Parents
  • Hi Chris,

    The basic structure is as follows:

    SMPTE comes from TASCAM DA-98 deck

    First half of the show, locate point is 4/57.00 and first cue after timecode rolls is 5/00.15, giving just enough time for timecode to lock with a jump of 60 frames.

    Last cue in the first section is at 29/01.29, and timecode stops at about 29/04.00, timecode is disabled by a macro in the last cue, then this list is released.

    Manual bit in the middle on a different cuelist and meanwhile the DA-98 decks re-locate to 33/03.00 for the start of the second half of the show. Manual cuelist, on its last cue, releases itself, triggers the appropriate cue back in the timecoded list (the cue before timecode rolls) and re-enables timecode on that list.

    Second half of the show, first timecoded cue is at 33/06.02.

    Last timecoded cue in the show is at 49/01.07.

    I don't know if it makes a difference, but I often find that once the tapes are located/stopped, the "input timecode" in the timecode bar does not match the "current timecode". The hours column usually jumps ahead several hours, last time around 8. I have a bit of a feeling that this is a root cause but I don't understand why as the console should be waiting for that first 60 frames of SMPTE before locking, and the timecode is always accurate when running, just not after being stopped.

    A head scratcher indeed.
Reply
  • Hi Chris,

    The basic structure is as follows:

    SMPTE comes from TASCAM DA-98 deck

    First half of the show, locate point is 4/57.00 and first cue after timecode rolls is 5/00.15, giving just enough time for timecode to lock with a jump of 60 frames.

    Last cue in the first section is at 29/01.29, and timecode stops at about 29/04.00, timecode is disabled by a macro in the last cue, then this list is released.

    Manual bit in the middle on a different cuelist and meanwhile the DA-98 decks re-locate to 33/03.00 for the start of the second half of the show. Manual cuelist, on its last cue, releases itself, triggers the appropriate cue back in the timecoded list (the cue before timecode rolls) and re-enables timecode on that list.

    Second half of the show, first timecoded cue is at 33/06.02.

    Last timecoded cue in the show is at 49/01.07.

    I don't know if it makes a difference, but I often find that once the tapes are located/stopped, the "input timecode" in the timecode bar does not match the "current timecode". The hours column usually jumps ahead several hours, last time around 8. I have a bit of a feeling that this is a root cause but I don't understand why as the console should be waiting for that first 60 frames of SMPTE before locking, and the timecode is always accurate when running, just not after being stopped.

    A head scratcher indeed.
Children
No Data
Related