Timecode oddities

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.

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.

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?

I like your idea for the enable/disable option. I'd like to see it implemented.

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

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.

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

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.