intensity effect overrides new to Hog III

So this is something that has driven me crazy since moving to Hog III, and one of the few places where I really feel they "broke" something with the new OS. Because there are never enough faders, when punting a show one thing I do is record intensity of a group into cue 1 of a cuelist that has other info on it, for example color, for that same group. So I can use the fader to control intensity, the cuelist buttons to change colors. Then on another fader I may do a stack of intensity effects, "slow, med, fast," etc. That way I can easily switch between an intensity effect and regular intensity control on the main intensity control fader.
What is killing me is that now if I change a color while running an intensity effect, the effect will stop running, even if the main intensity fader is down because the new cue has tracking intensity info. On Hog II you could set both faders to use HTP and avoid this, but with Hog III setting a stack of intensity effects to use HTP will disable the effects.
You might think setting the options to 'persist on override' on one or the other or both of the cuelists would fix this: nope. (Not really sure what that option is useful for then...)
The workaround I've come up with is to change the Halt button to Assert, then quickly reasserting the effect after I change the color. But this is annoying to have to do, not to mention disabling the backup functionality of the Halt button.
Parents
  • 0
    [quote=a_sezak;36634]I just tried this (I've had the same problem for a while) and it works. Thanks Marty.

    At the risk of sounding ignorant, how does this work? How does the assert macro work with the persist on override?

    Thanks

    It is really simple actually....since the two lists are set to the same priority level, one will always "stomp" the other partially unless the underlying list is re-asserted, which is what the macro does for you without having to hit the actual Assert key.

    The Persist on Override option simply keeps the list from being "stomped" and released by running it in the "background"....so the Assert Macro essentially tells the list not to run in the "background" but rather inthe "foreground".

    Make sense?
Reply
  • 0
    [quote=a_sezak;36634]I just tried this (I've had the same problem for a while) and it works. Thanks Marty.

    At the risk of sounding ignorant, how does this work? How does the assert macro work with the persist on override?

    Thanks

    It is really simple actually....since the two lists are set to the same priority level, one will always "stomp" the other partially unless the underlying list is re-asserted, which is what the macro does for you without having to hit the actual Assert key.

    The Persist on Override option simply keeps the list from being "stomped" and released by running it in the "background"....so the Assert Macro essentially tells the list not to run in the "background" but rather inthe "foreground".

    Make sense?
Children
No Data
Related

www.etcconnect.com