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?
The programmer can have selected channels, and it can be clear. ... it can also have a third state of "selected channels" that are "not usable for updating but captured nonetheless." What is this latter state and how can I observe it? Can I determine it by opening the programmer? this is briefly discussed in section 19.1.2, or on page 204 (2.5.0-EN):
The Contents of the Programmer after Recording a Cue When you record a cue, the values remain in the Programmer, but the background colour changes from blue to grey. This indicates that the parameter values in the Programmer are no longer touched, and so are available for recording to another cuelist, but not to the same cuelist. You can keep the values in the Programmer to act as the basis for the next cue on the same list, but because of tracking, only the changed parameter values will be recorded. For an overview of tracking, see Tracking.
in this paragraph, the hyperlinked, glossary-defined term "touched" is slightly misappropriated; it would be incorrect to describe these leftover values as "un-touched" since the programmer is still very much asserting the same control that it would were they "totally-touched". so i'm going to refer to values in this third, declined state as consumed.
[quote=amerson]If I update a palette is the programmer unable to update another palette before I release it? Maybe the question I have is "What is saved in the programmer?" or "What is lost from the programmer?" when I update. not unable, but certainly reluctant, and for good cause.
for example, you might have a fixture @ 50 and positioned to the "Dude DR" pallette. if homeboy gets re-blocked half-a-step left, obviously you'll adjust focus and probably @ -10, too.
now you've got a problem. your new focus wants to go into your focus pallette, and the intensity should stay in the cue body, but you've got both sets of data in your single programmer.
this third state is what allows you to commit these two change sets separately.
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.
so as for what is "saved" versus what is "lost" when you update, i'll say: values which were able to be consumed by your operation are "lost", values which were unable to be consumed by your operation are "saved" for further action.
and as for being unable to update another pallette, this might now make more sense to you: though poorly named, the (State) option exists to force eligibility upon consumed values for participating in Record/Merge operations.
The programmer can have selected channels, and it can be clear. ... it can also have a third state of "selected channels" that are "not usable for updating but captured nonetheless." What is this latter state and how can I observe it? Can I determine it by opening the programmer? this is briefly discussed in section 19.1.2, or on page 204 (2.5.0-EN):
The Contents of the Programmer after Recording a Cue When you record a cue, the values remain in the Programmer, but the background colour changes from blue to grey. This indicates that the parameter values in the Programmer are no longer touched, and so are available for recording to another cuelist, but not to the same cuelist. You can keep the values in the Programmer to act as the basis for the next cue on the same list, but because of tracking, only the changed parameter values will be recorded. For an overview of tracking, see Tracking.
in this paragraph, the hyperlinked, glossary-defined term "touched" is slightly misappropriated; it would be incorrect to describe these leftover values as "un-touched" since the programmer is still very much asserting the same control that it would were they "totally-touched". so i'm going to refer to values in this third, declined state as consumed.
[quote=amerson]If I update a palette is the programmer unable to update another palette before I release it? Maybe the question I have is "What is saved in the programmer?" or "What is lost from the programmer?" when I update. not unable, but certainly reluctant, and for good cause.
for example, you might have a fixture @ 50 and positioned to the "Dude DR" pallette. if homeboy gets re-blocked half-a-step left, obviously you'll adjust focus and probably @ -10, too.
now you've got a problem. your new focus wants to go into your focus pallette, and the intensity should stay in the cue body, but you've got both sets of data in your single programmer.
this third state is what allows you to commit these two change sets separately.
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.
so as for what is "saved" versus what is "lost" when you update, i'll say: values which were able to be consumed by your operation are "lost", values which were unable to be consumed by your operation are "saved" for further action.
and as for being unable to update another pallette, this might now make more sense to you: though poorly named, the (State) option exists to force eligibility upon consumed values for participating in Record/Merge operations.
