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?
  • LIVE makes selections from Playback and the Programmer....it will not select fixtures that are PARK-ed.

    You must make selections manually if fixtures are PARK-ed and you want to have them recorded into cues.

    This is the expected/specified behavior that was true on the old Hog-2 as well.

    This is exactly because PARK is "invisible"....it is "invisible" to LIVE as well.

    Hope this helps:) .
  • there's a similar, lonely and unanswered thread about this here.

    [quote=amerson]Can someone perhaps elucidate?
    deep down, park is just a mega-high priority Scene. as you'd expect to get values from active Scenes when using Live, parked values will always be "asserted" or "not-stomped".

    i agree, it's a big fat bug.

    [quote=Marty Postma]This is exactly because PARK is "invisible"....it is "invisible" to LIVE as well.
    definately not what i see happening, perhaps there's a feature parity problem with the Windows builds?
  • Personally I don't see any problem with PARK functionality in this regard.

    If I Park worklights I certainly don't want to have them recorded into any Cues or Scenes I program!:eek:
  • ok, so here goes:

    new show, one desk channel
    park at full
    desk channel one touch.

    now, the parked value is in your programmer. that doesn't seem very "invisible to Live".
  • [quote=quinn]ok, so here goes:

    new show, one desk channel
    park at full
    desk channel one touch.

    now, the parked value is in your programmer. that doesn't seem very "invisible to Live".

    Of course not....because you "manually" selected the fixture :rolleyes: (which is why it shows up bright orange....to warn you that it is Parked).
    ;)

    If you Park Desk Channel 1 at any value and perform any of the other LIVE functions such as:
    - LIVE, ENTER
    - LIVE, SUCK
    - LIVE, TOUCH
    .....then Desk Channel 1 is not brought into the Programmer as expected.:cool:
  • in the big state evaluation pipeline, i think there are some serious inconsistencies surrounding Parked, which fail to create sense and order.

    Touch is one example, Live is another. the fact that the resulting selection sets differ speaks more to the heart of the problem than either of the two actions do alone.

    specific to [Live], let's not refer to parked values as "invisible". if they were "invisible", that would mean to me that the state evaluation pipeline would start from fixture defaults, progress through active lists and scenes, account for the programmer, and STOP before taking state from Parked. the final computed state would be returned, and the parked values would not be applied, making them "invisible".

    rather, let's refer to parked values as "anti-visible". a parked desk channel would typically have a default of 0%, might be in a cue at 50% and parked at FL. if the state evaluation process were to ignore the parked value it should return 50%, but rather the entire fixture is removed from the selection set, just because it's parked.

    in other words, Park can directly affect what happens in the programmer, which is completely contrary to the very notion of parking.

    and to put it as crudely as possible, Hog2 handled parking just fine. the Expression 1 handled parking just fine. but if you park something on a Hog3, editing could go one of four different ways. and that's absolutely unacceptable. Park should affect DMX output only, period.
  • 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?
  • After reading this, I now have a question that someone might be able to help me with. I'm a Hog guy, but I used an Eos recently on a show, and was able to accomplish what I'm about to describe, but I'm not sure how to on the Hog.

    I had 3 electrics of toplight with scrollers, all patched indivdually but also in a group. I had to wait for 5 scrollers to come in (one row) and had to program before they arrived. On the Eos, I parked this series of dimmers at 0, because I didn't want a row of un-colored light onstage. I did all my cueing as normal, and all color and intensity values were recorded in my cues as normal. When I used the [Select Active] which is equivelant to [Live] all of the units were selected, including the parked channels. The Eos acted as I expected it to, when I unparked the intensity of the units with scrollers, all the recorded information was there, and it was like I had them the whole time.

    I get what Marty was saying about not wanting to record parked channels if they are work lights, but there are useful situations where I DO want to record parked channels into cues, for later use.

    I know this is a rare situation, but now I'm curious as to how the Hog would handle this case, and to see if anyone has any pointers with using Park.


    Thanks,
    --Kirk Fitzgerald
  • Kirk,

    You used park precisely as I would expect to use it. Selecting [Live] or [Select Active] should ignore the park status as Eos does. Then you could park scroller lights and have them work when you unpark them. Or you could park the worklights on and not have them appear in any cue.
    [quote=kirkf1tz]I know this is a rare situation, but now I'm curious as to how the Hog would handle this case, and to see if anyone has any pointers with using Park.
    It's probably not as rare as you think, but I would like to know the same thing you're asking.
  • I can see where this option could be useful. I have logged a suggestion for a user configurable option as item #12611.

    thanks!
Related