Per-screen hotkeys for larger shows

[cajun-rat]

Is your feature request related to a problem? Please describe.

I've used linux-show-player run audio cues for the last 2 shows at my local theatre group. It works great, thank you!

I've been triggering cues from the cart layout using hotkeys, so for example B triggers the 'Blue Danube' cue, and I annotate the script with the hotkeys. This works nicely in the sound booth: there is no extra hardware to mess with, and my laptop has backlit keys.

However: the Christmas show has more than 26 cues...

Describe the solution you'd like

Ideally, hotkeys would be per-page in the cart view. I'd then have 'Act 1' and 'Act 2' pages, and the hotkeys would be scoped to those.

Describe alternatives you've considered

The alternatives I've looked at are:

• A MIDI control surface => Something else to to wrong + need a way to label the buttons
• Switching to the list view with 'Go next' => I'm not keen on this because it increases the chances of a major screw-up. If the actors go-off script, or do something unexpected I want to be able to respond in a rehearsed way.
• Using the mouse to select cues => This requires looking at the screen, and I often also need to be driving the mixer and looking at the stage too. It is nicer to get a finger on a key and wait.

Additional context

I'm up for implementing this, given a few pointers on how to fit it into the design. The obvious implementation would be a breaking change for existing users, which might be too disruptive?

[FrancescoCeruti]

I'm up for implementing this, given a few pointers on how to fit it into the design. The obvious implementation would be a breaking change for existing users, which might be too disruptive?

The "easy" way would be a global switch, but it's too limiting and I don't think it's what you've in mind.

I'd suggest to add a flag to identify which shortcuts should be scoped to the cue page, and extend the plugin to check this condition. Currently, the plugin stores a list like [key, action], we could move to a dict {key: <value>, action: <value>, ...}, to make it extensible.

I'm working on a mechanism to migrate the session files between version, so, for now don't worry about breaking compatibility.

[cajun-rat]

Thank you! I'm looking through the code and getting a handle on how things fit together. Right now I can't see how to inject knowledge of 'the currently visible page' into the process.

As I understand it, the Keyboard Protocol emits events, and these end up in Controller, where __cue_map routes them to the execute method on a suitable Cue. I think I'd need to know about CueCartModel.current_page, and the mapping from Cues to Pages, but I can't see a way to get visibility to that?

There is another possibility here, which is that I'm using it wrong :) I had a look at the QLab documentation, and it appears that Keyboard shortcuts are global in that too. That implies that most productions don't need this functionality, so they must be doing things in a different way.

[FrancescoCeruti]

There is another possibility here, which is that I'm using it wrong :) I had a look at the QLab documentation, and it appears that Keyboard shortcuts are global in that too. That implies that most productions don't need this functionality, so they must be doing things in a different way.

I guess most people with similar needs use a MIDI device or something similar :)

Thank you! I'm looking through the code and getting a handle on how things fit together. Right now I can't see how to inject knowledge of 'the currently visible page' into the process.

We could add a new abstract method to the base layout class lisp.layout.CueLayout, to checks a cue "visibility", and implement it in the layouts:

• In the ListLayout should always return True.
• In the CartLayout you can use the to_3d_index to get the page of the given cue and test against the current page.

From the plugin you can access the layout with self.app.layout