Parking violation

I have some lights in my show (conventionals) that have not yet been focused so I parked them off. I put them in the cues at approximate levels. Later when I unpark, the cues should be close if not correct.

When I select "Live" channels however, these channels are not selected because they are parked. It doesn't seem to matter what value they are parked at; they don't get selected. So even though they are live in the cue and parked live, they still are not selected by "Live."

The behavior that I am used to is that they are selected independent of their parked state. If the cue (or the programmer or editor) is calling for them to be live, they should get selected by "Live" independent of their park status. Park is an invisible thing that happens behind the scenes that is never visible in cues.

I suspect Hog has a different mechanism to put channels at values invisible to cues. Can someone perhaps elucidate?
Parents
  • 0
    When I said park is "invisible" I was thinking relative to cues. On most boards, there is no way a cue can determine the status of any parked channels. Parked channels are "invisible" to cues. If I select anything parked, it gets selected in exactly the same manner it would if it were not parked. When I record a cue, the same thing... the cue is unable to distinguish parked channels in any way. The parked-ness of a channel is hidden in every respect except the final output (or the park screen). Submasters and pretty much everything else are also unable to determine the state of park.

    That's what other boards do, and that's the function I would like. I don't care whether you call it "park" or "onion." I want the described functionality. Does Hog3 have this functionality? If so, how do I access it if it's not called "park?" What do you call this functionality on Hog3, or is it missing?

    Now, given the preceding discussion, I don't know the value of the Hog3 park. If I write a cue using a channel that is not parked and then write exactly the same syntax with a parked channel, I get two different behaviors. I would like to understand where that might come in handy because I really can't think of a use for the apparent correct behavior of park on Hog3. When would you want to park something and have it exhibit the behavior of not being selectable, and then unpark it and have it become selectable again? What is the advantage of this behavior over the conventional behavior?
Reply
  • 0
    When I said park is "invisible" I was thinking relative to cues. On most boards, there is no way a cue can determine the status of any parked channels. Parked channels are "invisible" to cues. If I select anything parked, it gets selected in exactly the same manner it would if it were not parked. When I record a cue, the same thing... the cue is unable to distinguish parked channels in any way. The parked-ness of a channel is hidden in every respect except the final output (or the park screen). Submasters and pretty much everything else are also unable to determine the state of park.

    That's what other boards do, and that's the function I would like. I don't care whether you call it "park" or "onion." I want the described functionality. Does Hog3 have this functionality? If so, how do I access it if it's not called "park?" What do you call this functionality on Hog3, or is it missing?

    Now, given the preceding discussion, I don't know the value of the Hog3 park. If I write a cue using a channel that is not parked and then write exactly the same syntax with a parked channel, I get two different behaviors. I would like to understand where that might come in handy because I really can't think of a use for the apparent correct behavior of park on Hog3. When would you want to park something and have it exhibit the behavior of not being selectable, and then unpark it and have it become selectable again? What is the advantage of this behavior over the conventional behavior?
Children
No Data
Related

www.etcconnect.com