Page 1 of 1

Subcue relative timing

Posted: Sat Mar 22, 2008 1:56 am
by Theatre III Sound
When a cue with multiple subcues having relative start times is playing (or paused) and you manually advance the top level subcue (the <1> subcue) by dragging its slider bar, shouldn't the countdown times of the other subcues be advanced also?

Also, in the editor it would be nice to be able to play the top level cue and have all of its subcues fire off at their appropriate times and also allowing the <1> cue to be advanced with adjustments made to the other subcues' countdown times.

In both cases, I would think that if the <1> cue is adjusted past the relative start time of a subcue, then that sub would be skipped.

For example: Let's say I have a sound file cue of music coming out of a radio on stage and a gunshot sound cue timed to a particular place in the music coming from backstage. I define the gunshot sound as a subcue of the music cue with a relative start time. During rehearsal, it would be nice to position the music cue to just before the gunshot, start it and have the gunshot play at the right time.

Re: Subcue relative timing

Posted: Sat Mar 22, 2008 7:10 am
by Boswell
I think this would just bloat the software for little gain.
If you wan't to test a cue with delayed subcues, just come out of the editor and try the cue

Re: Subcue relative timing

Posted: Sat Mar 22, 2008 9:09 am
by jkowtko
(I misread the original post and am revising my reply ...)

Since SCS knows the exact start timing of each subcue, and since you can drag the play position on any running cue and have SCS figure out where it is in the audio file, it is conceivable that by positioning a "primary" cue to a certain point in time from the start would allow SCS to figure out where the dependent cues are relative to their countdowns, fade levels, and/or audio file positions.

Mike, don't know if SCS actually keeps track of this stuff internally this way (especially the fade positions) ... but if it does, the coordinated positioning of sub- and dependent cues may be something to consider for a future release.

-- John

Re: Subcue relative timing

Posted: Sat Mar 22, 2008 10:08 am
by Mike Daniell
Theatre III Sound wrote:When a cue with multiple subcues having relative start times is playing (or paused) and you manually advance the top level subcue (the <1> subcue) by dragging its slider bar, shouldn't the countdown times of the other subcues be advanced also?

Also, in the editor it would be nice to be able to play the top level cue and have all of its subcues fire off at their appropriate times and also allowing the <1> cue to be advanced with adjustments made to the other subcues' countdown times.

In both cases, I would think that if the <1> cue is adjusted past the relative start time of a subcue, then that sub would be skipped.

For example: Let's say I have a sound file cue of music coming out of a radio on stage and a gunshot sound cue timed to a particular place in the music coming from backstage. I define the gunshot sound as a subcue of the music cue with a relative start time. During rehearsal, it would be nice to position the music cue to just before the gunshot, start it and have the gunshot play at the right time.
This is a valid point, but it can get very complicated when you consider the possible scenarios. For example, skipping the gunshot if you drag the <1> slider past the gunshot's start time is OK, but if instead of a gunshot it was a longer effect, such as the arrival of a vehicle, then you may ideally want to start that subcue at the corresponding later position. Also, if there are fades or level changes involved in the subcues the program would need to determine the level to be set at the point you have dragged the <1> slider to. Having said all that, advancing the relative start times of the subcues is a good suggestion, even though it still leaves some issues in complex multi-subcue cues. In the short term, John's suggestion of using separate cues will give you more control in situations like this. Trouble is, I guess, the scenario you have described probably only happens occasionally during rehearsals, and maybe on cues you weren't expecting to have to re-run, so deciding beforehand wich cues should be split is not always easy!

Regarding testing in the Editor, since you can easily switch between the Editor window and the Run Screen window (as suggested by Boswell), you can test the complete cue in the Run Screen. Each of these windows is shown separately in the task bar at the bottom of your screen, so you can just click on the required window reference to select that window.

Re: Subcue relative timing

Posted: Sat Mar 22, 2008 12:54 pm
by Theatre III Sound
Theatre III Sound wrote: For example: Let's say I have a sound file cue of music coming out of a radio on stage and a gunshot sound cue timed to a particular place in the music coming from backstage. I define the gunshot sound as a subcue of the music cue with a relative start time. During rehearsal, it would be nice to position the music cue to just before the gunshot, start it and have the gunshot play at the right time.
Alright, the above was a bad example and not relevant to what prompted me to ask for this feature, so I'll attempt to give a better one...

I'm working on sound and lights for a ballet and I'm using SCS's MIDI send capability to control the lighting desk. On one particular track that's 3min:57sec in length, lighting effects take place at 3:29 and 3:54 in conjunction with gestures from one of the dancers who is cuing off the music. During rehearsals, the director might want the dancer to run that segment a few times to get the gestures right and in time with the music and lights. As it stands right now, whether the MIDI cues that are sent to the lighting desk are independent autostart cues or subcues of the audio file cue that plays the music, I have to run the entire track in order to keep the lighting cues in sync with the music.

So, I just thought it would be nice if I could select this cue from the cue list, position the slider to 3:20, say, and run the cue from there and still have the lights go at the specified times of 3:29 and 3:54 relative to the start of the music.

In the absence of this feature, I already know how to address this problem during rehearsals - simply edit the music track and clip out the last 30secs or so and use that clip in a temporary cue along with modified MIDI subcues. If I assign this cue to a hotkey, I'll be able to run it anytime and as many times as needed.

Bruce

Re: Subcue relative timing

Posted: Sat Mar 22, 2008 7:01 pm
by Boswell
That's a better example, but I'm against overcomplicating the software for a feature that may only be used by a couple of people on relatively few occasions.
I would rather have a programme that is rock solid, bug free and does 99% of what 99% of the users want than one that does 99% for 99% of the users and 100% for 1% of the users but keeps falling over and is harder for Mike to maintain.
We have a perfect example of 'Bloatware' in Windows! How many of the features in Office2007 does the average user use? not many I bet.

I'm not having a go at you personally but this is a good programme as it stands and I don't want to see it 'Improved' by the addition of little used features and go downhill in term of reliability.
SCS locking up in the middle of a performance is not my idea of a good night!
/rant off :D

Regards

Re: Subcue relative timing

Posted: Sat Mar 22, 2008 8:56 pm
by sound
Well said, Boswell - I can't agree more.

Re: Subcue relative timing

Posted: Sat Mar 22, 2008 10:40 pm
by SimnaWeb
Why not set your midi cues to start Auto <TIME> from the end of the cue? It would function the same and allow you to start the track closer to the midi cue time.

Re: Subcue relative timing

Posted: Sun Mar 23, 2008 11:17 am
by Theatre III Sound
SimnaWeb wrote:Why not set your midi cues to start Auto <TIME> from the end of the cue? It would function the same and allow you to start the track closer to the midi cue time.
Hey SimnaWeb, Thanks for the suggestion - I tried it and it works great :D

Given that Mike indicated it would be complicated to implement and others expressed a desire to KISS, I can live with the alternate methods described in previous posts and so I withdraw my request.