Simple keyboard driven cueing?

Hi,

I’m slowly discovering Score which I would like to use to drive a live production based on TouchDesigner through OSC. For such productions the timeline is usually pretty linear aka. Cue 1 invariably leads into Cue 2 which in turn leads to Cue 3 etc. going back and forth during rehearsals but generally going forward is better :wink: Cueing happen asynchronously meaning that the timing between cues varies from one show to another depending on how long the performers take to do their thing so an operator is usually waiting to trigger the cue manually. Given this context I think it could be quite useful to implement a simple keyboard or OSC driven cue advance mechanism to Score. Similar to what can be found in software such as Dataton Watchout, Millumin etc. where the user can advance through all the cues by tapping the space bar or using arrow keys.

I’ve made a first attempt at this by using OSC triggers and configuring a TouchOSC interface with a GO button. I start playback in Score which halts when it encounters a trigger and waits there until the address value I specified for the trigger is != 0 (initiated by pressing the Go button in TouchOSC in this case). This works fine for only a few cues but it becomes quite tedious to program a show containing hundreds of cues with multiple edits, cutting/pasting/moving/reordering etc. This also does not allow me to easily go backwards. I first have to scroll back, click someplace before where I want to start, press space bar, wait for Score to stop on the next trigger and then press GO…

I’m wondering if I’m approaching Score with the wrong mindset and if there is another simpler way to achieve what I want?

Keep up the nice work, congrats for the forum and thanks!

Hi @tohox !

Thanks for your feedback!

Yes, a simple “launch next available trigger” keyboard shortcut would be a very good addition. It’s been discussed before several times so, this time, I’ve added an issue for that: https://github.com/OSSIA/score/issues/733
Hope this will help it coming to existence.
Would it help you achieve what you want the way I proposed ?

As for the “go back” feature you’re asking, I would like to make sure I understand:
let’s say you’re “on” cue 4, with score playing. You would like that, when pressing e.g. the left arrow, the following sequence occur (under the hood):

  • stop execution
  • start again the playing from just before the previous cue (cue3 in this example) just as if you you right-clicked -> play from here
  • trigger the previous cue (cue 3)
    right ?
    If that’s the case, I guess that shouldn’t be exceedingly hard to do, and also, I guess, an interesting addition!

Did I forget anything ?

Cheers!

Hi @bltzr,

Thanks for adding the issue on Github!

I guess the ideal behavior for the back key depends on the specific case but yes, you got the gist of it.

In my case, the ideal behavior if I’m currently in Cue4 (meaning that the various events or resulting state triggered by Cue4 are already in place) and I hit the back arrow while Score is in its stopped state would be to bring me back to the final state of Cue3 and wait for me to hit Go again.
So if stopped inside a cue:

  1. Immediately recall final state of previous cue (without processing timings, curves etc)
  2. Wait for user input before triggering next cue

On the other hand if score is already playing when I hit the back arrow I would expect it to simply jump back to the beginning of the current Cue and continue playing from there. So if currently running Cue4 and I hit back arrow I would expect for the final state of Cue3 to be recalled and Cue4 to immediately begin playing again.
So if already playing:

  1. Stop execution of current cue
  2. Immediately recall finale state of previous cue
  3. Start playing immediately

I think a forward key with similar behaviors allowing to skip forward without timings, curves etc. would also be a welcome addition.

I know this can rapidly become complicated if you have multiple timelines running in parallel and you want to track all the resulting states of previous events in concurrent timelines. For a first implementation though I think a simple skip back and skip forward to the end states of the currently selected timeline would suffice for most uses.

Many thanks,

thank you!

could you put those additions into the github issue ?
I think they are all quite interesting, even though they might not all happen overnight :slight_smile:

Also, while I’m not sure what it exactly does in detail (what happens of the skipped data), but@jcelerier teased us recently on the team chat with this: https://files.gitter.im/OSSIA/5QgC/loop-2018-04-04_23.53.31.webm
and that might (or might not, not sure) help realizing this…

p

For those interested, the discussion is going on there : https://github.com/OSSIA/score/issues/733