Feature Request: Live Updating Palletes

Hmm.  We have historically connected the blind sub buffer to the live output to facilitate the way our TV guys preferred to make live changes.  We have never done the same with blind cue, because on a tracking system the danger of unintended live changes exists (with absolute data, you could make a change to a cue many cues away from a currently active one, but have that change feed to the live buffer because of tracking).      It feels odd to me that we would allow palette/preset changes to feed out instantly to live, but not absolute data. 

It is pretty easy to assert an active cue. 

?

a

Surely if a change you make in blind immediately appears in the live output, then you're not actually making the change 'blind'...... ?

Rob.

another way to state it. 

I agree that this shouldn't automatically update, but... Sure you can [Assert] [Cue], but only if you have no other manual data that has not yet been updated. What if the syntax were extended to: [Assert] <Target>  (in this case [Assert] [Color Palette] )? This could assert the change to the other Color Palettes currently active in the cue without making them manual. And perhaps take it one step further to allow the syntax: [Update] <Target> n [Assert] [Enter] to do it all in one fell swoop.

-M

I totally understand Blind Cues and many other blind things not updating.

My though being with Intensity Palettes specifically, If you were blind editing one of those, the whole point would be that it would track through anywhere the Palette was used. In theory the programmer chose to Palletize an intensity to make global references.

[Sneak] wont update the palette. it would be nice if that command recalled the data. If the palette is tracking, taking the next cue wont reflect the new values until there is a Block or Assert Cue to recall that palette again.

Thanks everyone for discussing.

Hey Sam.  We do have two (related) things on the list that may help.   The first is the Sneak function of which you speak.  Right now, the playback buffer is only "refreshed" by certain actions.  We are going to change it so that Sneak is one of them.  So, for example, you have a channel at an IP stored in a cue.  You make a change to that IP in blind.  Sneaking the channel will refresh the buffer, putting the revised content on stage.

Also, the playback buffer is updated by move instructions.  We are going to change it so that when you press go, we check tracked values as well against the content of blind and replay revised track instructions if needed.

Don't yet have an ETA on when we will make these changes, but they are increasingly high on the list.  Perhaps we should see after that how much closer we are to the behavior you would like to see.

Thanks much all!

a

Hi Anne,

Regarding the upcoming change to replay revised track instructions on "Go", couldn't this create some possible undesired behavior during playback?

I'm picturing a situation where one operator is taking cues, while a second operator is in blind making changes to some earlier cues.  If, for example, that second programmer sets a light to full in blind, but the Go command is taken before the light is put into a proper preset (and then "marked" manually in live), that light would be commanded to full prematurely.

I much prefer the current behavior, where the operator must choose to refresh the playback buffer separately from taking a cue.

Good news that Sneak will refresh the playback buffer, however!

Thanks,
~P 

Hi Anne,

Regarding the upcoming change to replay revised track instructions on "Go", couldn't this create some possible undesired behavior during playback?

I'm picturing a situation where one operator is taking cues, while a second operator is in blind making changes to some earlier cues.  If, for example, that second programmer sets a light to full in blind, but the Go command is taken before the light is put into a proper preset (and then "marked" manually in live), that light would be commanded to full prematurely.

I much prefer the current behavior, where the operator must choose to refresh the playback buffer separately from taking a cue.

Good news that Sneak will refresh the playback buffer, however!

Thanks,
~P 

Hey Paul!  The sneak change is already in the 2.0 branch, since that was a clear need.  

Regarding the tracked value check on Go.   In the case of multiple programmers, some discipline would be necessary to assure unexpected, undesired results did not occur.   But the thing to ponder is if this is offset by other advantages.  

Thanks much!

a