• Date
    jbenghiat
  • Date
  • Replies 12 replies
  • Subscribers 186 subscribers
  • Views 8456 views
  • Users 0 members are here

Request - Cue as reference

On a recent project, I had a number of cues with an A/B/A/B/A sort of structure (think aside, restore, etc.).  This got me thinking that I would find being able to specify a cue as reference to be quite useful.

For example, cue 1 is the scene.  Cue 2 is the special moment.  To build the restore, I could select all at cue 1.  Any future updates to cue 1, then, would be reflected in cue 3.

While I understand that I could just make cue 1 a preset, here are some advantages to what I'm proposing:

- I generally liket to see levels for intensity and labels for NIP pallets and presets, all of which would be relabeled if I made the model cue a preset.

- This may be just me, but I would want any changes made to a referencing level (not in the model cue) to default to absolute.  In my example, if I wanted to update  cue 1 while in cue 3, I would [Update] [Cue] [1], and expect to see manual values in the current cue replaced with "Q1".

- In the course of building a show, it's much more efficient to just reference another cue, rather than go back to the model cue, record as a preset, label the preset, go back to the cue I'm building, and recall from the preset.  Any tools to help program in the moment are always a plus.

- I would want to be able to reference channels that had null data.  If I were to add channel 10 to cue 1, it would also get added to cue 2 via the reference.

Just curious if anyone else would be interested in a feature like this, or if something is in the works.

-Josh

Parents

  • I'm going to throw out another way to look at this:

    What about the possibility of "cue groups" - being able to store a number of cues to a group.  So [cue] [1] + [3] + [4] + [7] + [9] [record] [group] [6] would be valid syntax.  This would let one easily jump into blind and modify all the 'A' cues or all the 'B' cues in your example.  So, when a cue group is selected in blind any changes entered are applied to all cues and if one did an an update in live, all cues in the group would be affected.  To provide easy access I would suggest that this be embedded in the normal group functionality - once a group has cues recorded to it it becomes a cue group, will not accept channels, and has some sort of visual indicator in pool and direct select views.  This could be extended further to use the database functionality similar to query - i.e. update cues based on their label.

    This gives you almost the same functionality without getting even more complex references going (there's already enough layers in my mind....).  Of course, even without this functionality, you can achieve what you want to do pretty easily with the [update] [x] + [y] + [z] syntax.

Reply

  • I'm going to throw out another way to look at this:

    What about the possibility of "cue groups" - being able to store a number of cues to a group.  So [cue] [1] + [3] + [4] + [7] + [9] [record] [group] [6] would be valid syntax.  This would let one easily jump into blind and modify all the 'A' cues or all the 'B' cues in your example.  So, when a cue group is selected in blind any changes entered are applied to all cues and if one did an an update in live, all cues in the group would be affected.  To provide easy access I would suggest that this be embedded in the normal group functionality - once a group has cues recorded to it it becomes a cue group, will not accept channels, and has some sort of visual indicator in pool and direct select views.  This could be extended further to use the database functionality similar to query - i.e. update cues based on their label.

    This gives you almost the same functionality without getting even more complex references going (there's already enough layers in my mind....).  Of course, even without this functionality, you can achieve what you want to do pretty easily with the [update] [x] + [y] + [z] syntax.

Children
No Data
Related

www.etcconnect.com