Timecode oddities

I have recently run into some really strange behavior with the hog3 system and timecode.
I have a main cuelist that the show runs from and an auxiliary list that plays some FX cues using fixtures from the main cuelist. Both lists are triggered from timecode, but never at the same time. I have the FX list set to run through a sequence (lets say 12 sequential timecode 'go's in 45 seconds) and at the last cue, which is empty, has a macro to release the list so the main list regains control over the fixtures.
The problem is the FX list gets caught in a loop and never really releases. It will sometimes just keep looping the last three or four cues, and sometimes it will jump around at the top of the list with the pause LED flickering every few seconds. The fixtures affected by that list also 'tweak out' when they shouldn't be doing anything.
I have done much voodoo with different cuelist options like toggling different combinations of 'reset when released', 'trigger forwards only' and having the RL macro cue triggered either by timecode or an autofollow.
I finally had to resort to disabling timecode/releasing for that list when it reaches the end and re-enabling it later from the master cuelist when needed.
This is all a little cumbersome and non-intuitive to me. It took me a long time and several phone calls to figure out what was happening and I still don't quite get it. It seems that it is fairly easy to mess up the execution logic if one doesn't have all playback option settings just right.
Parents
  • 0
    Andris,

    Wholehog 3 cuelists handle timecode slightly differently than the Wholehog 2 did. The new functionality offers some additional features and flexibility, but it can seem odd at first. The most important thing to note is that there is no need to play a cuelist before it will start listening for timecode. If timecode is enabled for a cuelist, it will play (even if it is released).

    Now, for the details about how it all works...
    All of the following assume that timecode is enabled for the cuelist being discussed.

    When a timecode frame is received, the console looks for the cue that has the highest timecode time stamp that is equal or less than the current timecode being received. This is the cue that the console believes it should be in.

    If there happen to be a series of non-timecode cues between this cue that was found and the next timecode cue, and the current cue is in this section, then the console assumes that it is already in the right place and will not trigger another cue until it gets to the receives the timecode value for the next timecode cue.

    So, what's probably happening in your case is this:
    Your cue with the Release List comment macro is fired by timecode.
    When the list releases, the current cue indicator is left on a timecode triggered cue.
    As soon as the next frame of timecode is received, it re-plays the cuelist.
    The cue to play is determined as described above and happens to be the cue with the Release List macro.
    This causes the cuelist to basically try to play and release itself non-stop until a timecode value is received for a different cue in the cuelist.

    There are 2 ways you can get this list to behave like you want to:

    1) As you already discovered, you can use Enable and Disable Timecode macros to control when this list listens for timecode.

    2) Rather than have your Release List comment macro be associated with a timecode cue, record an empty cue where you want this to happen and give it a fixed wait time (like 0s). When the release happens, the list will now be sitting after the last timecode cue and will not attempt to re-trigger until the next appropriate timecode value is received. This will *only* work if the Reset On Release option is not set. If you turn on Reset On Release, the current cue indicator will be reset to the first cue of the cuelist when it is released and this will probably cause the list to again trigger from timecode.

    I hope this helps.
    Please let me know if you continue to have problems, or if you have any other questions.
Reply
  • 0
    Andris,

    Wholehog 3 cuelists handle timecode slightly differently than the Wholehog 2 did. The new functionality offers some additional features and flexibility, but it can seem odd at first. The most important thing to note is that there is no need to play a cuelist before it will start listening for timecode. If timecode is enabled for a cuelist, it will play (even if it is released).

    Now, for the details about how it all works...
    All of the following assume that timecode is enabled for the cuelist being discussed.

    When a timecode frame is received, the console looks for the cue that has the highest timecode time stamp that is equal or less than the current timecode being received. This is the cue that the console believes it should be in.

    If there happen to be a series of non-timecode cues between this cue that was found and the next timecode cue, and the current cue is in this section, then the console assumes that it is already in the right place and will not trigger another cue until it gets to the receives the timecode value for the next timecode cue.

    So, what's probably happening in your case is this:
    Your cue with the Release List comment macro is fired by timecode.
    When the list releases, the current cue indicator is left on a timecode triggered cue.
    As soon as the next frame of timecode is received, it re-plays the cuelist.
    The cue to play is determined as described above and happens to be the cue with the Release List macro.
    This causes the cuelist to basically try to play and release itself non-stop until a timecode value is received for a different cue in the cuelist.

    There are 2 ways you can get this list to behave like you want to:

    1) As you already discovered, you can use Enable and Disable Timecode macros to control when this list listens for timecode.

    2) Rather than have your Release List comment macro be associated with a timecode cue, record an empty cue where you want this to happen and give it a fixed wait time (like 0s). When the release happens, the list will now be sitting after the last timecode cue and will not attempt to re-trigger until the next appropriate timecode value is received. This will *only* work if the Reset On Release option is not set. If you turn on Reset On Release, the current cue indicator will be reset to the first cue of the cuelist when it is released and this will probably cause the list to again trigger from timecode.

    I hope this helps.
    Please let me know if you continue to have problems, or if you have any other questions.
Children
No Data
Related

www.etcconnect.com