Update Cue Only (not Forward)

Try using record merge. You can record merge to multiple cues. IE, you have information in the programmer and want to place it in two different cues, Hit record cue 1 + 2, deselect forward, and hit enter.

hi rick,

the quick answer is [Merge] (Forward Off) (Remove) (State), then touch your cue's Number cell.

i understand the instinct to Update Enter, but, even though it's a LOT slower, Merge really is the proper operation for "updating" cue bodies.

(i think it would be great if "Merge, Enter" would just work, by defaulting to targeting the current cue in the chosen master's list, but instead the command completes without performing any action or presenting any error.)

What's the difference between updating and merging, other than updating doesn't always work? I've noticed that when recording positions, groups, etc., record doesn't work with previously recorded groups whereas merge will. What is the technical difference in these three commands? I know merge takes the info and puts it into whatever, leaving everything else alone. But what does update do that merge doesn't, and what does record do that merge doesn't. Why is the simple command -- update -- not a good choice? What happens when I update if a group is one of the options and I check it? Does that also misbehave like update with cues?

[quote=amerson]Why is the simple command -- update -- not a good choice?
a couple things i'll point out, right away:

Auto-Update is far, far more involved than the ETC "S4-Update" that you're used to, and very often it *is* a good choice.

it's this specific case, where you want the "no-longer-active" changes in your Programmer to be subsequently recommitted using the (State) option, that requires you to use Merge instead.

(and, in my opinion, it's not due to any concept or philosophy, but a UI quandary: the (State) option is not available in the Auto-Update dialog because toggling that option on would alter the collection of values for which Auto-Update needs to resolve record targets, and that would occur after the "checkbox tree" has already been populated and painted)


[quote=amerson]What is the technical difference in these three commands?
Record is more or less "commit the changes in my Programmer to an explicit single or explicit collection of targets"

if when recording you specify an existing target, you'll be prompted to choose whether you want to Insert a new and differently-numbered target at the existing target's location, to "Merge" or combine the changes in the Programmer with the existing target's data, or Replace the existing target completely. a common choice to this question is to Merge, so the [Merge] key has been included as a shortcut for passing your intent to the recording functions so that you need not be prompted.

so, Merge essentially is just a well-thought-out Record.


[quote=amerson]What's the difference between updating and merging
when you perform an S4-Update on an Obsession, it will default to updating the current cue. you can, of course, specify a different cue, or a submaster/group/or whatever. but in any case, you're limited to updating a single item / record target.

(in this sense, S4-Update is equivalent to Merge; you're not asked to Please Confirm just because Cue or Part Already Exists; S4-Update is a well-thought-out selective Record.)

the exception to S4-Update being limited to a single target is when you update a multi-part cue, without specifying which part to update. in other words, you can make changes that affect multiple parts, and S4-Update will take care of the rest; channels in P2 will automatically get updated into P2, channels in P8 will automatically get updated into P8. (of course, that's not how the mechanics of updating part cues work, but for this, it illustrates well)

Where an S4-Update can only operate on a single target which must be explicitly specified if not the current cue, Auto-Update can operate on any number of targets and will, automatically, inspect the changes in your Programmer and, value-by-value, determine the correct target for committing each individual change.

similar to how an S4-Update commits channel levels to their appropriate "source" parts, Auto-Update commits each parameter value to its appropriate "source" target. a single Auto-Update command can modify the current Cue on the Chosen Master's List, the current Cue on a different List on another Page, a Colour Pallette referenced by that current Cue on a different List on another Page, and an Intensity Pallette referenced by a Scene, all at the same time.

the manual does a much better job of describing this practice than do i. you'll notice the Auto-Update pages make frequent use of the term "merge". Auto-Update is a means of performing a "multi-operation Merge" or "multiple Merges by a single command".


if you're, say, changing cyc levels and carrying them through the next ten cues cue-only, when you step into each of those cues you're not saying "i've got these changes and i want you to now go look at every single thing that's contributing in any way to what's live on stage, and merge into whatever sources you may happen to find", no, you're saying "i want these changes exactly here, in this cue. all of them, right here.", and that's really more of a Merge than an Auto-Update. you have a target in mind, and that's the difference.


[quote=amerson]What's the difference between updating and merging, other than updating doesn't always work?
now, for single-list shows, Auto-Update always resolves to the exact target that you would have specified had you been Manual-Merging instead. as such, it's quick and easy and i love it. but as soon as you start employing auxiliary / chase lists, the way in which you're expecting "Update" to work is just going to fall apart. is this maybe what you're seeing? what isn't working for you?


[quote=amerson]What happens when I update if a group is one of the options and I check it? Does that also misbehave like update with cues?
consider as such: Auto-Update "polls" active sources of playback to determine who "owns" a parameter's live-on-stage value. as groups cannot contain parameter values, they cannot contribute to playback, and will never be registered as an Auto-Update candidate.

again, which misbehavior are you seeing?

Quinn,

Thanks for your thorough, detailed, pithy response. It would appear that merge is a bit more tedious than auto update, but somewhat more powerful and flexible, particularly when it comes to handling multiple items of various types.

I think my question should have referenced "palettes" instead of "groups." 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. The programmer can have selected channels, and it can be clear. If I select and update channels, 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?

I must remind that there are a few differences and bugs in merge and update how the timing is recorded, especially when using cue only combined with backward tracking.

[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.

Replace is essentially a delete first and then record option. Replace will take the information in the programmer and replace the selection (cue, palette, or group) with it.

This is useful in the situations where you have your Dude Downstage palette and the dude is permanently moved to another location. By record replacing, you will delete your Dude Downstage palette and replace it with other information, this information will, of course, then be used every time the Dude Downstage palette is referenced.

In terms of use in a cue, it can get a little tricky to record replace depending on where your information is being tracked from, but I digress a bit.

Merging, on the other hand, will take the information in the programmer and combine it with the information in the cue, palette, or group. Provided it doesn't conflict with the information in said cue, palette or group. In these cases the information in the programmer will overwrite the information in the target cue, palette or group. I've tried to write an example below.

Let's say you're working with color palettes. Palette 1 contains fixtures 1 and 2 at red. You change fixture 1 to blue and record merge, or just merge. Now Palette 1 contains fixture 1 at blue and fixture 2 at red. In your cues, if fixture 1 and fixture 2 were at palette 1, previously both fixtures would be red, now fixture 1 will be blue and fixture 2 will stay red.

By using the same example with replace you would end up with no data for fixture 2, as you essentially deleted the information with replace. Your cue would end up with fixture 1 in red, and no color information for fixture 2.

Of course it gets more complex as you add more information to your programmer. Though, with the masking that be done your options are immense as to how and where you put your information. Hope that helps to set a simple example you can apply to your situation.

[quote=amerson]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.
you'll find this is consistent throughout the platform; values will transition to a consumed state whether you choose Record, Merge, or Auto-Update as your commitment operation.


[quote=amerson]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.
...
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.
i want to be very clear about two things: Auto-Update is smart. very smart. and you seem to understand both its purpose and its process quite correctly.

it's not my intent to reduce Auto-Update to anything trivial. in so few words, Auto-Update is aware of its context; kinda creepy, ay?

but for all the smart choices that it makes, twould be meaningless if those choices did not directly result in changes being committed. now, i'm not yet in a position to authoritatively speak to this, but still i submit that Auto-Update's commit-operation-of-choice is Merge.


[quote=amerson]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.
i'm not sure i'd agree to restoring - a "force eligibility override" would affect the set of values returned for passing into a commit operation; the commit operation shouldn't care whether the value it's consuming is or is not normally eligible, only that it's been passed in and needs to be consumed. an expected side-effect of consuming a value is marking that value as consumed; there is no way to mark a value as consumed other than to consume it. so, since you'd be able to choose to include pre-consumed values when passing a change set to a commit operation, that should be enough; it's better to have a way-in than no-way-out, as would be the case when the next operation encounters an "un-"consumed value. also, externally "undoing" an expected side-effect is outright wrong.



"consumed" can be a very useful state, even to a human operator. here's an example: if you've got a refocusable special coming up, you might want to manually mark it during the previous shift. easy, Record only PCB into a follow from your shift cue, then simply Merge what's leftover (the intensity) into your current cue. if "consumed" were completely invisible/internal, that would assume that you'd never want this ability, without having to make tedious sub-selections and knocking out values. Also consider Track Backwards; you might want to perform an Auto-Update/Use I to commit level changes in your current cue, and then perform a second Auto-Update to track the color and gobo changes back to top of scene.

"consumed" is how we keep our designers happy. they'll spend sometimes six eternities working on a cue, working the way they their mind wants to work. you can't order them to mix color or pan/tilt to the correct position prior to turning their lights on. how we build cues is very different from how they build cues, and "consumed" is one of many platform features doing a lot of the work towards bridging the two by simply not interfering, making it so fast to just record, record, record, skip forward, clear, and move on.



Wholehogs are very much tracking consoles, one of the things they use "consumed" for is to help reduce the number of resultant partial blocks as much as possible. if you're carrying changes through an entire sequence, you'll probably start at the top and use Auto-Update on the first cue to make sure any pallettes are updated. all subsequent cues, however, really want that data to be Removed, not updated, cue only. Auto-Update won't be used with Remove, so [Merge] (Forward Off) (Remove) (State) will accomplish the carrying of your changes through a sequence, in a manner preferable to dropping blocked values into your entire cue list via [Rick's Magic Update].



[quote=amerson]When I choose Replace, H3 seems to erase the palette rather than overwrite it. Maybe it's related to this "consumed" issue.
i concur. consumed values are ineligible for use in commit operations; hence, a null set is passed to the Replace operation, which will accurately yield a target devoid of values.


[quote=amerson]I then Merge the same info and it works.
i'll assume that by "same info" you mean "identical values, which have been manually re-entered or otherwise brought again into the programmer as totally-touched"




love the little sunglasses guy, that's great. i hope you're liking your new venue