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
    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.
Reply
  • 0
    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.
Children
No Data
Related

www.etcconnect.com