Cue List Tracking after Copying Cues
Posted: 05 Apr 2019, 21:46
Hi All
I'm wondering whether this is a bug or an oversight (or entirely intentional behaviour) so open to others opinions...
If I make a new cue list, with some cues (let's say 1 - 4) and then copy 2-3 to the end of the stack (5 and 6) what I end up with is cues 2 to 3 having values for all parameters of fixtures. Where originally in my first cue I have values for everything and dimmer at full, then only colour in cue 2 and then another colour change in cue 3.
Issue for me:
I go into cue 1, decide to grab fixtures and put the dimmer at half then update cue 1.
Result:
Cue 1 -- fixtures at half
Cue 2 -- fixtures at half
Cue 3 -- fixtures at half
Cue 4 -- fixtures at half
Cue 5 -- fixtures at full
Cue 6 -- fixtures at full
See what I'm getting at? The frustrating bit here is that if I then put them at half again in cue 5 and update that, cue 6 will still send them to full. So I have to keep chasing the information forward or do a RECORD CUE X THRU Y MERGE (which can end pretty badly if I had forgotten about some changes further down the stack...)
I can pop into cue view, and see exactly why it's resulted in that. When copying a cue, it doesn't copy the information that is actually in the cue, but the information cumulatively up until that cue. Which essentially is like every copied cue is a block cue.
I feel like what needs to happen here is some clever stuff in the background when a cue is copied. The information gathered in the same way (cumulatively working out the end result), but then when it's "pasted" in it dumps out all the information which isn't a change from the previous cue. So in my example here it wouldn't result in having intensity information.
--
Alternatively, maybe a "clean up" tool we could run on cue stacks that searches through for redundant data if you are using expecting information to track?
My end goal is cue stacks that are "tidier" in terms of the information stored in them. When working on larger show files that are built upon and built upon (tour to tour, song changes, rig changes) it can become a bit of a mess as it is.
Thoughts?
George
I'm wondering whether this is a bug or an oversight (or entirely intentional behaviour) so open to others opinions...
If I make a new cue list, with some cues (let's say 1 - 4) and then copy 2-3 to the end of the stack (5 and 6) what I end up with is cues 2 to 3 having values for all parameters of fixtures. Where originally in my first cue I have values for everything and dimmer at full, then only colour in cue 2 and then another colour change in cue 3.
Issue for me:
I go into cue 1, decide to grab fixtures and put the dimmer at half then update cue 1.
Result:
Cue 1 -- fixtures at half
Cue 2 -- fixtures at half
Cue 3 -- fixtures at half
Cue 4 -- fixtures at half
Cue 5 -- fixtures at full
Cue 6 -- fixtures at full
See what I'm getting at? The frustrating bit here is that if I then put them at half again in cue 5 and update that, cue 6 will still send them to full. So I have to keep chasing the information forward or do a RECORD CUE X THRU Y MERGE (which can end pretty badly if I had forgotten about some changes further down the stack...)
I can pop into cue view, and see exactly why it's resulted in that. When copying a cue, it doesn't copy the information that is actually in the cue, but the information cumulatively up until that cue. Which essentially is like every copied cue is a block cue.
I feel like what needs to happen here is some clever stuff in the background when a cue is copied. The information gathered in the same way (cumulatively working out the end result), but then when it's "pasted" in it dumps out all the information which isn't a change from the previous cue. So in my example here it wouldn't result in having intensity information.
--
Alternatively, maybe a "clean up" tool we could run on cue stacks that searches through for redundant data if you are using expecting information to track?
My end goal is cue stacks that are "tidier" in terms of the information stored in them. When working on larger show files that are built upon and built upon (tour to tour, song changes, rig changes) it can become a bit of a mess as it is.
Thoughts?
George