Timecode oddities

AndrisAndris Registered User
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.

Comments

  • teericksonteerickson Registered User, HES Alumni
    edited November 2006
    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.
  • AndrisAndris Registered User
    edited November 2006
    It seems to me that there should be more logic built into the Release List macro where it would avoid this loop situation if you are at the end of a cuelist. If I put a release macro at the end with no other cues following, it should release the list, and not pay attention to the timecode if it is farther along than the last timecode triggered cue in that list.
    I have tried putting the release macro on an empty cue that autofollows the last timecode cue, but it still does strange things. It will loop the top couple of cues (or at least it seems that way) and cause the pause button LED to flicker at random. The Reset on Release was diabled too.
    The 'disable timecode' workaround, although it's a bit kludgy, does work.
  • teericksonteerickson Registered User, HES Alumni
    edited November 2006
    Andris,

    Feel free to disagree with me, but here are my thoughts:

    There are a few things that I like about our current behaviour.

    From an operator's standpoint, I like that I don't have to press play to tell the console to begin listening for timecode. I can always tell that when Enable Timecode is turned on the list will fire cues and when I press Play it will be a go and not just starting timecode.

    I also have far more control and ability when working with multiple lists and / or multiple timecode sources. Being able to enable and disable timecode for each cuelist (and especially being able to do this with comment macros) offers huge amounts of flexibility.

    When I think about the issue that you're seeing, the behaviour makes sense in my head. I can understand why the console is doing what it's doing. I personally don't think adding a special case for a list being released in its last cue is the best solution because it puts the list into a state where I can't really tell what's going on. I look at the cuelist and see that timecode is enabled, but cues aren't being fired.

    What I think might make more sense is to add could options that would enable timecode when the list is played from a released state and disable timecode when the list is released.

    What do you think of this?
  • AndrisAndris Registered User
    edited November 2006
    I like your idea for the enable/disable option. I'd like to see it implemented.
  • AJBRATAJBRAT Registered User
    edited December 2006
    I’m programming a show using time code and I am wondering which is the best way to take my single cue stack to the top of the show so that it may be triggered by the time code generated?

    Best Regards-
    AJ
  • teericksonteerickson Registered User, HES Alumni
    edited December 2006
    AJ,

    You will probably get more responses for this if you post a new thread in the Wholehog 2 forum.

    There are a couple of ways that you can accomplish what you're trying to do and what will work best for you depends a bit on the details of your situation. What I would suggest is using one of your timecode reset points. You can set 3 timecode reset points within the Inputs Control Panel (Setup -> Imput Panel). You can then jump to these points, either with the buttons on the timecode conrols toolbar or by using the >F1, >F2, and >F3 comment macros. If you have a timecode value assigned to the first cuelist in your show, you should be able to jump to it (or before it) with the resets.

    I hope this helps. Please let me know if there are any other questions I can answer.
  • AJBRATAJBRAT Registered User
    edited December 2006
    So if I'm following you correctly I should be able to set a time code reset point in my input Control Panel and by typing in the comment space ">F1" within my only master cuelist, running just one for this show, it will reset the time code to that point, i.e 00/59/58.00. So if my first cue triggers @ 01/00/08.00, show runs and finishes, I can take my cuelist back to the top of my stack and sit in a rest state if I comment macro ">F1" timecode reset point? Let me know if I'm reading you right. Thank you for the quick reply.

    AJ
  • teericksonteerickson Registered User, HES Alumni
    edited December 2006
    AJ,

    It sounds like you understand my suggestion. Feel free to let me know if you have any troubles with this or if there is anything else that I can help with.

    Thanks.
Sign In or Register to comment.