Hey brain trust,
I recently programmed a show that involved a large number of cuelists, many of which were used to basically run big chains of PAR can flashes via timecode. I found I had a lot of inefficiencies, some of which could be solved by additional cue selection options. Therefore, I have a few suggestions of features that could be added to make this style of programming easier, and hopefully I've thought of logical syntaxes and use cases for all.
1. Selecting cues in a specific pattern.
I spent a great deal of time typing out "Cue 1.2 + 2.2 + 3.2...." and so on throughout this show as we went back over the timecode sections and added more units into the effects. I don't think in my wildest dreams I could have made efficient use of palettes for what I was doing, and so I have a number of possible suggestions for new syntax that would make this easier. The cues were numbered in a logical way to reference bar and beat numbers, such that cue 1.1 was the first beat of the first bar of the song, and so on - let that give context to a couple of these suggestions.
1a. [Cue] [X] [thru] [Y] {Offset} [Z]
This syntax would function similarly to the Offset softkey in patch. If I write [Cue] [1.1] [thru] [10.2] {Offset} [2], I would expect to select cues 1.1, 1.3, 2.1, 2.3, 3.1, 3.3, and so on, assuming that I'm programming my typical pop song with four beats to a bar and I've decided to have a cue on every beat. With only whole-number cues this would return cues 1, 3, 5, 7, etc. This would have saved me a huge amount of time spent typing out a dozen cue numbers at a time in order to selectively update.
1b. [Cue] ([X] [thru] [Y]) .2
This is a more specific use case than the above, but I think still useful and a logical syntax. If I select a range of multicell fixtures and append .1 to the channel selection, I would only modify the first cell of those channels. For obvious reasons, this cannot be the same for cues, but I think that use of parentheses to specify this syntax is reasonable. I would expect [Cue] ([X] [thru] [Y]).2 to return all cues within the range that have ".2". Therefore [Cue] ([1] [thru] [6]).2 would return only cues 1.2, 2.2, 3.2, and so on.
2. Cue Groups
I understand this is something that gets brought up occasionally, hence why it is not my first suggestion, but I think it may have merit. Again, the ability to record a list of cue numbers as a group or palette would have saved me a lot of time on this show. However, I realize that this would probably require a whole new set of features to add this into direct selects and so on, so I can understand that this might be a lot of work.
3. Cue Query
Again, something that I think has been suggested and dismissed in the past, but I would like to make the case, via the following list of useful query selections that I can imagine. I would expect the multiple cue selection that would be returned by this query to respond to Next/Last in the same manner as a channel selection, allowing me to skip through only the cues I'm interested in looking at, at least in Blind.
3a. Cue Query Channel X Is/Is Not Active
3b. Cue Query Contains Palette/Preset X
3c. Cue Query Contains Broken Marks
3d. Cue Query Contains Emergency Marks
3e. Cue Query Block / Intensity Block / etc
3f. Cue Query Has Ext Links
3g. Cue Query Has Part X (I, like many, use Part 20 as a specific Mark part, so Query Has Part 20 would return a list of all cues that I have flagged for marking. I can imagine plenty of other uses for this as well!)
3h. Query-able text fields in cues - could be accessed via Attributes, just like Note and Scene data. Cue Query "Blackout", for example, could return all blackouts; useful if I'm programming a dance school show and the choreographer has decided that her earlier request for full blackouts is not practical and needs them all changing to blueouts.
Hopefully at least some of this makes sense and seems useful to others!
Best,
James