Exclusive Cues (in 10.1.0)

[Theatre III Sound]

Hi,

Newest member chiming in. I've only worked with SCS for a few weeks and have not used it yet in a show, but it certainly looks like a great package.

I do tech stuff for a number of theater and ballet groups. I just completed a gig as TD for a production of "The Nutcracker" where we had issues with CD players and volume levels from track to track. It looks like SCS would work well in this case.

I'm setting up a demo to show the artistic director and stage manager. The second act consists of a number of tracks, each cued manually on stage manager call or visual on stage.

One thing I noticed while setting up this demo is that while one cue is running, you can hit the "GO" button which starts the next one and so on. That's of course a desirable feature when dealing with multiple effects, but I think a nice feature to consider is the concept of "exclusive" cues, i.e. when such a cue is running, the "GO" button is disabled until the cue ends (or the operator manually stops it). This should be on a cue by cue basis and could be implemented as a check box in the editor.

What do the members of this forum think of this idea?

[SimnaWeb]

What do you mean by "manually" stopping a cue? Many of us create a Stop cue that is triggered by the GO button which would be disabled in the way you describe this.

If it was a "disable new start cues" or something of the sort I could see a use for this, especially in dance.

[Theatre III Sound]

I was referring to using the "Stop" button that is provided for each Audio File Cue that appears in the bottom half of the main screen.

I hadn't thought of the Stop Cue situation, so disabling new Audio File and Playlist Cues would be a better feature.

I'm suggesting this feature as a way of preventing accidental starting of an Audio File or Playlist Cue while the current one is running.

[SimnaWeb]

I understood what you're intended goal was. I just wanted to make it more "every user friendly" shall we put it. The stop button on the cue file itself can work but I do not recommend using those in a live setting with an audience.

Being able to prevent future start cues from firing may be a good idea for the inexperienced operator.

[Mike Daniell]

Bruce,

You mentioned originally considering the request for this feature in the context of "The Nutcracker". Although I can see some general benefits in providing an 'exclusive cue' property on a cue, I have recently been working with a user who runs SCS for music production and has been trialling some new Production Properties for music productions. One of these properties is 'Solo Cue', which is similar to your 'exclusive cue' property, except that it applies to the whole cue list. For a ballet or other music production, do you see a need to be able to set this property for selected cues only? It shouldn't be difficult to add this as a cue property, but since I already have it programmed as a production property I thought I'd ask.

[Theatre III Sound]

I haven't had much experience yet with putting together productions, so I'm not sure if a global or individual property is more useful. Here's a brief description of the "Nutcracker" demo as it stands at the moment:

Q1 is a random looping playlist of preshow music, followed by a Fade Out Cue to fade out the preshow.

Q2 is an Audio File Cue that plays for the entire first act.

Q3 is a repeat of Q1 for intermission music.

Q4-Q16 are Audio File Cues, one for each track of the second act. This is the section where if you have SCS set up to use the space bar as a "GO" command, I was concerned that a 2nd track might accidentally get started. For an inexperienced operator, the space bar is probably the easiest to use, but also prone to accidental operation.

Given the above, a global property would work as long as it didn't affect the Fade Out Cues. However, what if you had a situation where for some cues, you'd like to be able to run more than one and for others, you'd like to make sure they're solo? In that case, having the property individually settable would be better.

Perhaps both methods could be combined by having the production property be the default setting for all cues, but allow an individual cue to override the default.

[Mike Daniell]

I'll adjust the code I've written in relation to the 'Solo Cue' production property so that the 'Go' button will be enabled if the cue to go is an SFR (stop, fade out, loop release) or Level Change cue. With that in place it seems to me that this global approach would meet your needs. The reason it was made a production property and not a cue property was that the initial requirement was for music productions (eg bands) where all the cues are to be solo. (Every cue actually has several sub-cues, all playing toegther.) Setting the 'Solo Cue' property at the production level saves having to remember to set the property on every cue.

[Theatre III Sound]

Yes, I think what you're proposing will be fine. Probably should include MIDI cues in the list of types where the 'GO' button remains enabled.

Thanks for being so responsive to user requests.

[jkowtko]

Mike,

I like the idea of the "solo" cues. However I'm surprised that whoever requested this for a Musical production wouldn't want to set this at the cue level.

Sure, the music tracks all need to be serialized with respect to each other (since you will never play two songs on top of each other), but the sound effects can overlay on top of everything, including music tracks and other FX cues. This is pretty standard usage to me. And if you have one FX that overlays on anything, you can't use a program-level solo setting.

One thing we did in my company (whose software has nothing to do with audio but the same principle applies on concurrent processes) was to add a "serialization key" attribute to the process definition. You could specify any arbitrary text string in that field, but if you do, that process won't be able to execute if there are any other processes still running that use that same serialization key. This allows you to single-thread everything on one key, or create multiple keys each with their own set of cues that are dependent on them. Maybe overkill for SCS usage, but completely flexible. A simpler UI for this would be to provide, say, four "solo" channels and put four checkboxes on the audio file cue property sheet.

So, in summary, I think the need to serialize some of the cues and leave others overlay-able would still be desired.

Is this critical for me? No, because I tell people just "don't hit that spacebar" ... but I'm sure the day will come when someone's finger will twitch and they'll fire off the next song too early, and we'll wish we had this feature

Thanks. John

[Mike Daniell]

Interesting suggestion, John. As you'd be aware, there's often a compromise between functionality and usability. Another possibility is to have an optional 'exclusive group' identifier as a cue property. All cues that may be run together would be given the same exclusive group identifier.

[jkowtko]

Some more thoughts --

From a UI standpoint, I'm not sure which concept is easier for someone to grasp -- all cues can be overlayed unless you specify otherwise, or all cues must be executed serially unless you specify otherwise. I believe the latter is what you just suggested, and calling it something like a "overlay group" might be easy enough for people to understand. However, if we visualize them they are two different things that could each have their own purpose:

Serialization groups:

1) A --> B --> C --> D --> E
2) F --> G --> H --> I
3) J --> K --> L --> M

Overlay groups:

(AFJ) --> (BGK) --> (CHL) --> (DIM) --> E

As you can see, the dependencies are set up differently between the two and the behavior can be quite different.

From my standpoint, the original purpose of this is feature request is to prevent the user from accidentally firing a cue to early before another cue it is dependent on has finished. So the most intuitive way of me programming this is to allow the user to create a sort of a pert chart (which would be most flexibly and maybe not too difficult to understand either) - -to explicitly name the dependencies for each cue. You could just call it a "wait-for list".

[Mike Daniell]

I've been re-reading your posts, John, and realise now that your original suggestion of a serialization key is, in fact, the same as my suggestion of an exclusive group identifier. I had mis-interpreted the suggestion you gave in your first posting. In your second posting, the examples of serialization groups:

1) A --> B --> C --> D --> E
2) F --> G --> H --> I
3) J --> K --> L --> M

match the concept I also had in mind, eg group 1 (A thru E) corresponds to what I had called an 'exclusive group'.

To include a 'serialization key' property in the cue properties would be quite workable. In the Help file I'd suggest using the initial cue number for the serialization key, eg 'A' for cues 'A --> B --> C --> D --> E'. What do you think?

[jkowtko]

That sounds good to me Mike.

And as for terminology, the term "exclusive" doesn't mean as much to me in this context as the term "Serialization" ... so my vote would be for something like "Serialization Group" or "Serialization Key". (Of course, whatever it's called, once we know where it is, it will be quite useful

Thanks. John

[Boswell]

How about being able to define what happens when a cue starts
ie advance to next cue at the start
advance to the next cue at the end of this cue etc

This would remove problem of starting a cue until the previous one had completed

[customdigi]

I'm starting to have the same feeling that I used to in High School Calculus class...when the whole class is grasping something and I was scratching me head...