Update Cue Only (not Forward)

I modified the look onstage and then performed an update cue only. I then did a go to the next cue and again tried to update cue only from the info held over in the programmer and the Hog 3 refused to update. I had to release and reenter the info into the programmer to make it update. How do you update two consecutive cues cue-only without having to reselect everything?
Parents
  • [quote=quinn]
    if you first merge into your position pallette (which will assume a Use P mask), your position data will be set to consumed, so that only intensity data remains eligible for committing, which you subsequently merge into your cue body. (otherwise, you'd have both a focus pallette full of intensities and a cue body with hard pan/tilt data instead of a pallette reference.) all of this happens without your needing to make sub-selections or explicitly set masking options.


    Auto-Update, again, simply generates this correctly-ordered sequence of Merge operations and executes them for you. and unless you de-select a target, all the values in your programmer will have been consumed by the end of the Auto-Update sequence.
    Quinn:cool:, as always you've given a fabulous description. If that is the mechanism of auto-update, it makes sense to have values "consumed" and of course, once consumed, no longer available for updating.

    My mental picture of how auto-update is accomplished was different, and though obviously incorrect, it makes sense to me. I picture auto-update looking at what you choose to update as a single, whole operation rather than a sequence of independent operations. In my image, auto-update looks to see if you chose to update a palette used in the cue (or scene or what ever is higher in the hierarchy), and if so, it does not update the cue reference to the palette; it simply leaves it alone. If, for example, you only update a palette and only values in that palette, only the palette would change. The auto-update would notice that the palette change had effected the desired cue change. If I don't check the palette update box, then the cue itself would have the palette reference removed and the numeric values inserted instead leaving the palette unchanged. In order to accomplish this, auto-update would need to be smart enough to wrap all the changes into one operation rather than treat them as a series of merges.

    Alternatively, to accomplish my desired behavior using the method you describe, the auto-update would need to note the "consumed" state of everything before updating and restore it after the update completes. Thus "consumed" would be an invisible internal state.

    Merge vs. Replace is still a little obscure to me. When I choose Replace, H3 seems to erase the palette rather than overwrite it. Maybe it's related to this "consumed" issue. I then Merge the same info and it works. I haven't yet had the time to sit down and figure out exactly what it does on Replace, but I know Merge works unless I want to remove something from the palette or cue.
Reply
  • [quote=quinn]
    if you first merge into your position pallette (which will assume a Use P mask), your position data will be set to consumed, so that only intensity data remains eligible for committing, which you subsequently merge into your cue body. (otherwise, you'd have both a focus pallette full of intensities and a cue body with hard pan/tilt data instead of a pallette reference.) all of this happens without your needing to make sub-selections or explicitly set masking options.


    Auto-Update, again, simply generates this correctly-ordered sequence of Merge operations and executes them for you. and unless you de-select a target, all the values in your programmer will have been consumed by the end of the Auto-Update sequence.
    Quinn:cool:, as always you've given a fabulous description. If that is the mechanism of auto-update, it makes sense to have values "consumed" and of course, once consumed, no longer available for updating.

    My mental picture of how auto-update is accomplished was different, and though obviously incorrect, it makes sense to me. I picture auto-update looking at what you choose to update as a single, whole operation rather than a sequence of independent operations. In my image, auto-update looks to see if you chose to update a palette used in the cue (or scene or what ever is higher in the hierarchy), and if so, it does not update the cue reference to the palette; it simply leaves it alone. If, for example, you only update a palette and only values in that palette, only the palette would change. The auto-update would notice that the palette change had effected the desired cue change. If I don't check the palette update box, then the cue itself would have the palette reference removed and the numeric values inserted instead leaving the palette unchanged. In order to accomplish this, auto-update would need to be smart enough to wrap all the changes into one operation rather than treat them as a series of merges.

    Alternatively, to accomplish my desired behavior using the method you describe, the auto-update would need to note the "consumed" state of everything before updating and restore it after the update completes. Thus "consumed" would be an invisible internal state.

    Merge vs. Replace is still a little obscure to me. When I choose Replace, H3 seems to erase the palette rather than overwrite it. Maybe it's related to this "consumed" issue. I then Merge the same info and it works. I haven't yet had the time to sit down and figure out exactly what it does on Replace, but I know Merge works unless I want to remove something from the palette or cue.
Children
No Data
Related