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