[In 11.4.0] Subroutine Cues

[PhilVale]

What would be useful is to be able to set up a group of cues that can be called from a single cue.

So for instance - I recently had a bunch of cues relating to a car arriving, but I used this at several points in the show. Every time I changed the volume or timing on one of the sets of cues I had to change all of them.

It would have been useful to effectively say - at cue 73 - run cue 23-28 and then come back to the end of cue 74.

This is exactly the same in software terms as calling a subroutine or similar.

This is where Mike now tells me it's there and this is how to do it after I struggled with my last production and all those car door timings.

OK - I've now seen a posting by Mike from a way back where he suggests using Hot Key's - which I'd already thought of, but what I really want is the ability to use a cue to activate the hot keys rather than hitting the hot key.

BTW that was under a heading of EQ for SCS (or similar) which I would also support the idea of EQ and other effects being available.

[Boswell]

Hi Phil,
This was first requested in 2010, but I presume it is a lot of work for Mike to implement
http://www.showcuesystems.com/forum/vie ... =14&t=1408

[PhilVale]

Thanks Boswell,

In part it looks to be suggesting the HOT Key approach which I had considered. But I support on of the posters in that thread, what I really want is the operator just to press the go button each time during the show. It's not always me that's running the show, indeed I'm actually playing with the idea that cueing could come from the lighting board with it's MIDI control and it could then run the sound desk from it's cue list (or indeed the other way round).

I know - I may have a union problem with the lighting guys, but I have been know to work both boards sometimes.

[Mike Daniell]

This was first requested in 2010, but I presume it is a lot of work for Mike to implement

Yes, you're right. Maybe when 11.3.0 has been released I can look into implementing subroutines as this request or variations of it does get raised occasionally.

I've listed some reasons explaining the complexity of the implementation so you can comment on these if you wish:

• It potentially involves running two or more control threads concurrently
• Deciding what to do with activation methods in the subroutine's cues (eg should the 2nd and subsequent cues in the subroutine all be auto-start?)
• If a 2nd or subsequent cue in a subroutine is not auto-start but manual start, then how do we activate that cue, since the 'Go' button etc is really dedicated to the main control thread?
• Can or should the subroutine be a separate cue file (.scs11 file)? If so, do we need to be able to switch 'work spaces' to be able to edit either cue file easily?

[PhilVale]

Mike,

Thanks for the reply and I can see some of your problems/issues.

I think what I'm really looking for is essentially a way to fire a hot key from a cue instead of having to hit the hot key. I wasn't considering running who new sets of cue's from different files, but also appreciate you need to think of the wider picture.

Phil.

[djvomght]

Hello at all,

You can fire a Hotkey Cue by pointing a Goto Cue to it, like this:

HTH Jörg

[rborsey]

Firing a hotkey with Goto changes the next manual cue position as well. An obscure work around which is fine for "small" subroutines is to use BOME Midi Translator (or equivalent) which can convert midi messages to key presses. So you create a hotkey cue to execute your subroutine and then send a midi message out of SCS to BOME (via a virtual midi port), which creates a key press to execute the hotkey cue leaving the next cue pointer in the right place . . .

That said subroutines would be just dandy for me too

Cheers from sunny France

Richard

[djvomght]

Hello at all,

An obscure work around which is fine for "small" subroutines is to use BOME Midi Translator (or equivalent) which can convert midi messages to key presses. So you create a hotkey cue to execute your subroutine and then send a midi message out of SCS to BOME (via a virtual midi port), which creates a key press to execute the hotkey cue leaving the next cue pointer in the right place . . .

My father used to describe such things as "shooting from the back through the breast into the eye"
Of course "Goto" will change the cue position. One can use more gotos, which will create something, what programmers call "spaghetti code".

Anyway, subroutines would be usefull, because plays like "Intimate Exchanges" exist.

Regards Jörg

[lebem]

[*]Deciding what to do with activation methods in the subroutine's cues (eg should the 2nd and subsequent cues in the subroutine all be auto-start?)
[*]If a 2nd or subsequent cue in a subroutine is not auto-start but manual start, then how do we activate that cue, since the 'Go' button etc is really dedicated to the main control thread?

It would be good to be able to have a manual G-O within a sub-routine cue. As for how to handle that, I think the simplest solution may be an alteration to or a new cue type similar to "go to" cue. As pointed out already, currently a goto cue relocates the next manual cue to a different position in the cue list and executes the cue. Either a checkbox within the go to cue, or a new cue type that allows you simply to execute a different cue without changing the location of the next manual cue would solve at least some of this.

A sub-routine manual cue would not really be a manual cue in the traditional SCS sense, in that it would be ignored for the purposes of normal manual cueing, but would exist to be called by the above alternative goto cue type.

Sorry if this made no sense.

[Mike Daniell]

Just to let you know that subroutine cues will be available in 11.4.0, which should be available as a release candidate next week.

There are three new cue types to support this feature: Subroutine, End Subroutine, and Call Subroutine. Between a Subroutine and the corresponding End Subroutine cue you may include whatever cue types you wish, except other Subroutine-related cue types. When a Call Subroutine cue is played, SCS starts playing the first cue in the nominated Subroutine. Cues within a subroutine should all be auto-start cues.

[Willarki]

Any chance of conditional cues eg If Q5 still running then Q6 else Q7 OR If Q12 finished then Q14 else Q13

[Boswell]

I've been holding my breath since 2010 for this.
Looking forward to the release next week
Thanks Mike

[rborsey]

Mike, you just made my day. I was just about to launch into an "all night" session to update 90+ duplicated subcues to add another feature. I guess I'll wait a day or two . . .

Cheers from sunny France

[Mike Daniell]

I'm just about ready to issue 11.4.0 RC1 - it should be available some time tomorrow (Tues 12 May 2015).

I've actually simplified the concept of 'Subroutine Cues'. While working on a Subroutine Cue example to include in the Help file, every realistic scenario I came up with could be implemented using a single cue with one or more sub-cues. Sub-cues, of course, can have different relative start times, so not all sub-cues of a cue have to start together.

The result is that instead of 'Subroutine Cues' requiring three cue types (Subroutine, End Subroutine, and Call Subroutine), in SCS 11.4.0 I have added a new Cue Activation Type of Call Cue, and just one new cue type of Call Cue. A Callable Cue is really just like a Hot Key (Trigger) Cue except that the cue is activated by another cue rather than by a keyboard action. In the Help file I have included a Callable Cue which has an Audio File sub-cue and 3 MIDI Control Send sub-cues, with the 2nd and 3rd Control Send sub-cues set to start at different times within the cue.

[Mike Daniell]

'Callable Cues' and associated 'Call Cue' implemented in SCS 11.4.0.