Add a "launch next available trigger" keyboard shortcut

[bltzr]

as requested on http://forum.ossia.io/t/simple-keyboard-driven-cueing/33 and discussed before, it would be great to a keyboard shortcut to launch the next available trigger this would solve most "performing arts" use cases, e.g. with the right arrow for next available trigger

optionnally we could have more shortcuts for when there are several available (pending) triggers, like 0 key (from numeric keyboard) for next available trigger and 1, 2, 3, etc... for the next ones (ordered by default date)

what about this ?

[bltzr]

also, as discussed in the same forum thread, we could add a "go back to last trigger" with the left arrow key - that would certainly be much appreciated from the performing arts folks! something like the following sequence would then be happening 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)

[tohox]

I guess the ideal behavior for the back key depends on the specific situation.

In my case, the ideal behavior if I’m currently in Cue 4 (meaning that the various events or resulting state triggered by Cue 4 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 use cases.

[Seablade]

So take this with a grain of salt as I just arrived and am just now starting to look into possibilities with ossia, but in the theatrical world, it would make sense NOT to stop execution of current cue necessarily, thinking of playback/show control systems like QLab here, where you use forward and back to navigate between cues rather than to change current state of playback (For instance if you are told to not take a cue by a SM in theater could be because other cues associated with it can't fire for safety or other reasons, in which case you might skip the cue and continue on)

The stop playback could be bound to a specific key itself instead, while QLab for instance has a panic key(ESC or stop all playback, either on a fade if hit once or immediate if hit twice), it may make sense for ossia to have just a 'stop current cue' key as well.

[bltzr]

Hi @Seablade ! Welcome and thanks for the feedback.

I'm not 100% sure I completely get your point, so I'm rephrasing it: so you want to be able to skip a cue without stopping the playback of the rest, that's it ? If so, I guess that's an interesting point, but a little bit different from what @tohox asked for (am I right, both ?) We actually had this kind of request a while ago from theatre folks, indeed... In score, that would mean dismissing a trigger and everything that follows it until the next trigger. Right ? Though I don't know if that's feasible with the current model, @jcelerier is the one able to know this.

Concerning your second point, remember that, in most cases, score is not dealing with media themselves (as Qlab does, for instance), so that means we don't have access to media playback, fade-outs and so on...

[tohox]

@Seablade I think I see your point. You would for instance like to be able to advance to Cue 5 while Cue 3 is still playing, skipping over Cue 4 entirely?

Perhaps a key combination would do? Something along the lines of:

• Shift+Right (skip ahead without stopping playback and wait for GO)
• Right (stop playback, skip to next and wait for GO)
• Shift+Left (skip back without stopping playback and wait for GO)
• Left (stop playback, skip back and wait for GO)

Rereading my previous posts I think It might not be clear that a separate GO key would be required in addition to the skip keys. I guess this could simply be a different Trigger type perhaps named keyboard? Ideally this trigger could be easily/rapidly inserted or might even be a Trigger's default state upon being created? That way one could immediately start moving through the timeline , testing transitions, fades etc without having to configure OSC, MIDI conditionals and such upfront.

Don't know how well this fares with Score's current architecture...

[bltzr]

I guess this could simply be a different Trigger type perhaps named keyboard? Ideally this trigger could be easily/rapidly inserted or might even be a Trigger's default state upon being created?

Yes, having this as the default sounds like the best option to me. There could for instance be two more fields in the trigger inspector:

• The first: "In GO sequence ?" toggle would be on by default, and when becoming (the first chronologically) available trigger, the trigger could be triggered by the GO key
• The second field would allow to set specific key or key combos (in the example above that would be either the letter a lower case or alt-B) that would trigger this particular trigger when available.

For the GO key, that could be:

• down arrow
• 0 key of the numeric keyboard (with 1, 2, 3, etc... for the chronologically 2nd, 3rd, 4th available triggers)

[bltzr]

Concerning the other points, I guess I need to let this turn in my head, but what you have to consider is that, in those kinds of cases (ie. jumping to points in the scenario), what score does (and it's a nice thing IMHO) is that it "compiles" all values that would have been sent out until the chosen "jumping point", and only outputs the last one for each address. So, considering your use cases, that's pretty straightforward if the scenario is just a collection of cues (as you seem to be considering), but if it's being multilinear (as in the example below), then, that means that the scenario might be starting from the middle of an interval (in this case of an automation) That's fine with me, but I guess that's something to consider.

[bltzr]

So, in the previous example, what you mean @tohox by

recall final state of previous cue

would be to go approximately where the screenshot shows (more precisely, that would a tiny bit later, at the date of Cue2, with Cue2 waiting to be triggered) Which means that, when doing that, the value being automated would be recalled at the current value (in this case something like 0.43 or something).

Also, I'm not 100% certain you both are talking about the same thing when talking about "skipping cues":

• A: @tohox you seem to be wanting to skip everything until the next cue, and trigger it ("jump to the next cue")
• B: while @Seablade you seem to be wanting to skip everything until the second next cue (ie. everything until the next cue, the next cue itself, and then everything until the cue after this one. The difference I see between those both cases is that, in:
• A: you want to be in the same state as if you played everything up to the next cue (a kind of "instant fast-forward")
• B: you want to skip everything between the next and second next cue. Question: what should happen if we did what you describe in the situation of the screenshot below ? I guess that would place us just before Cue4 (actually at Cue4's date, with Cue4 pending), like this:

but, state-wise (i.e. for the values of the parameters addressed by the states/processes) would we be

• in the same state than just before we "skipped" ? (ie. at ~0.5 of the automated value)
• at the state just before Cue3 (automated value at 1.) ?
• in some other state ? (if so, please describe it)

[bltzr]

I guess some input from @jln- @pach or @reno- might valuable here also

[tohox]

Here is an example taken from a Vezér screenshot. The play head is currently stopped at Cue3 and the last values transmitted for each track (from top to bottom) were 1.0, 0.5, 1.0, 0.0.

Suppose I hit the back key once I would expect the play head to jump to Cue2 and the following values to be transmitted: 0.0, 0.5, 1.0, 1.0. Pressing GO would then start the transition from Cue2 to Cue3 again. On the other hand if I had pressed the forward key once I would expect the play head to jump to END and also have the values 0.0, 0.5, 1.0, 1.0 to be sent.

Vezér seems not to transmit anything when jumping around manually and only transmits values when the play head is moving by its own. I guess that option could be left to the user. To track or not to track...

[bltzr]

Thanks for the feedback !

Yes, “compiling” the previous states is sometimes very useful, but could be undesirable in some cases. In score v2 there is a kind of experimental GOTO feature (the one I was mentioning at the very beginning of this thread) that @jcelerier teased us with a while ago. @jcelerier, can you tell us what it does ? Does it only output what’s under the playhead ?

If so, then I guess we have all the tools to implement the features described here, and we just have to make some “macro” commands that would combine them with a keystroke. Am I right, @jcelerier ? To sum things up, the actions we want to be able to combine:

• jumping to a date in the scenario, with or without “compiling values” (as in “play from here”), while playing or when stopped
• jumping to the date of a trigger, with this trigger pending
• internally getting a (constantly updated) list of all available/pending triggers, sorted by (default) date
• adding keystrokes for each combined action, including a GO to trigger the next available (and optionally more keystrokes for the next available triggers),
• adding the possibility to define custom keystrokes for each trigger

Are all of theses actually doable, @jcelerier ? Are some of them hard ?

[jcelerier]

can you tell us what it does ?

check the local device's transport parameter; it only moves the execution of the root at that point - but can do so during execution

Does it only output what’s under the playhead ?

yes

I think that the first thing to get right for this is to have a timebar that can be moved through direct user interaction and then add key shortcuts (and OSC controls) that would move it.

[bltzr]

I think that the first thing to get right for this is to have a timebar that can be moved through direct user interaction and then add key shortcuts (and OSC controls) that would move it.

right!

what about adding a little widget, such as the triangle below, that the user could move to the desired place, and then we'd add options to "track or not to track" (ie. compiling values as in "play from here") ?

[jcelerier]

yep !

[tohox]

Sounds like a good start! Thanks for taking the time to listen/understand :)