After ESC... start cue x

[micpool]

Feature Suggestion.

One of the problems I keep coming up against when programming carts as controls for QLab is not being able to disable the ESC key. (However, I'm not about to suggest this would be desirable or sensible as a feature!)

For instance, If you change the cart button colors in response to the state of other cues, for instance  by using  network cues with durations, AppleScript loops, or looped group cues to provide visual feedback, then you can design a cue list that maintains the correct visual state of a cart by controlling its color , until someone presses ESC. At that point, all the cues stop and the visual feedback freezes on the cart and any processes which might change the visual state of the carts to the state after the ESC press  are also stopped.

This is particularly problematic when a cart only contains start cues to fire group cues which do other things, and feed back the fact that they are the last run group cue to the cart by changing the color of the cart button.

Or you might have a loop or network cue with duration which is sending things like next cue title or other info to Touch OSC on an iPad. etc. Again. that cue mechanism will cease to update when ESC is pressed leaving Touch OSC in a state that does not reflect the current state of QLab

I was experimenting with this problem using Keyboard Maestro. It's quite easy to disable the ESC key  (either universally, or only in QLab, or even only in QLab workspaces with "#NoESC#" somewhere in the workspace name.). But I'm not going to suggest you do that!

Another approach is to intercept the ESC key press and allow it to pass to QLab, but get Keyboard Maestro to then trigger a QLab cue (using Applescript or MIDI) . e.g a cue numbered  "ESCreset" which could then, for instance clear any illuminated carts (color changed)  to indicate  that no audio is currently running. Or to restart a looped group to send data to other programs.

This works well using Keyboard Maestro. (I have set it up to only intercept ESC keys to workspaces with names that contain  "#ESCreset#)

Would it be worth considering incorporating this as a feature in QLab general preferences,  as another 'When something happens, start cue number' option?

e.g  When workspace is panicked, Start cue number   x

I think it's a good solution to many scripting problems,  and still maintains the permanent  STOP EVERYTHING function of the ESC key.

Mic

[tylera...@gmail.com]

Mic,

One of the things I’ve done to get around this is create a hotkeyed OSC cue that panics everything, as well as another hotkeyed OSC cue that starts a specific cue you want. Both cues, in this case, would be triggered by the same hotkey. In my case, I used “~,” which is right under ESC on most keyboards, I believe.

Of course, the discrepancy would be that you then can’t use escape. Would love to see that feature as well.

Best,
Tyler Berg

[Rich Walsh]

If you're using a different hotkey why not program it to panic only the things you want to panic, eg: all cuelists that have a number?

I think the issue is the muscle memory of hitting escape.

Rich

[micpool]

Indeed, That was my point, that currently when you design schemes such as the one you describe into your workspace, everything works fine until someone hits ESC. And as we've been hitting ESC to stop cues in QLab for over 10 years it's a difficult habit to unlearn. 

Because you can deselect all the other keymap controls and put them on triggers of  your own group cues to change their functioning, e.g.hijacking the space bar to GO but also send updates of the current and next cue position to a display the only thing that prevents tis being a complete foolproof solution is that you can't do this with ESC, which is permanently assigned on the keymap.

As there are many reasons why allowing ESC to be disabled in the Keymap would be a bad idea, I made my suggestion as the next best thing.

Mic

 

[micpool]

On Wednesday, February 13, 2019 at 8:41:24 PM UTC, Rich Walsh wrote:

I think the issue is the muscle memory of hitting escape.

Yes that's exactly the problem. Even if you can train yourself to do it, (and I can't) , it's still going to happen (unless you put a physical cover over the key)

Mic

[Sam Kusnetz]

Hello Mic

Thanks very much for this nice, detailed write-up of how you would make use of such a feature.

It’s interesting! It’s on The Big List, and we’ll see what happens.

Best

Sam

—

Sam Kusnetz | Figure 53

s...@figure53.com

[Drew Schmidt]

Or what of you could opt to make a cue "Panic Proof", but a double esc, a hard panic still stops the "Panic Proof" cues?

When I want to just stop something, I hit esc. When I'm really panicking, I double tap. Which seems to be the intended behavior.

I personally would apply this to other cues (especially video) that need to be persistent; masks, backgrounds, etc.

[micpool]

Reviving this thread about persistent cues that break when ESC is pressed to panic.

Since we last discussed this, I have been using a solution involving a Pure Data patch, in an AU wrapper, stashed in an unused audio cue  effects insert,. This  sends  the  OSC message  /cue/dontPanic/start  at a programmable interval so that any cue that needs to keep running  can be numbered, or  put in a group cue numbered, dontPanic, so that it restarts after an ESC key panic.

Because this method resides so many levels deep in the structure of QLab  and potentially could cause all sorts of problems, I have kept the method to myself (and a few select people who had an urgent requirement for its functionality).

However, I have just found an alternative method, which, because it  just uses standard QLab features in cue lists, is possibly  much more acceptable for advanced general  use, although I  am firmly  in agreement with  the tenet of QLab design philosophy, which requires that anyone without detailed knowledge of a particular workspace should be able to stop everything by hitting escape!

The rather brilliant  technique was conceived  by Gareth Risdale, in a script he wrote to keep a script persistent, in order to guarantee automatic saves would be made of a QLab workspace at regular intervals. It works by programming the wall clock of the script cue to execute the next save, thus rendering it immune to a panicked workspace.

My version is based on his script,  but uses much shorter intervals so that a panicked cue will restart in seconds.It also uses 2 wall clocks to eliminate edge cases where the timing of an ESC key press can interrupt the updating of the wall clock on the script cue.

I'm  just giving it some exhaustive testing, but in the meantime here's a video of it in action entitled THIS CUE WILL NEVER DIE.

Mic

[Taylor Glad]

Throwing in another trick that can work in some cases...

Opening a second QLab workspace on the same machine. This makes a "panic proof" workspace while focus is on a regular show workspace.

Maybe some of this behavior has changed with recent updates, cause it's been a little while since I played with it.

Using Companion you can still target a specific workspace with a specific Companion instance (so you could have 2 panic buttons if you wanted to).

For keyboards, whichever workspace is on top will get all the key strokes. (Spacebar and ESC)

For looping audio, it's pretty straightforward.

Last I played with it, with 2 QLab workspaces using the same video output, whichever fires first will be behind it, and stay that way till the workspace is closed. So if you want something "panic proof" to be in the background, start that workspace first. If you want something "panic proof" to be in the foreground, start the other workspace first. For other cases, maybe there's some things to find out still with more experimenting.

Haven't played with lighting cues.

Then it may be a little annoying to alter any Applescripts to target specific workspaces instead of just the default workspace, but that would enable some looping scripts in one workspace to target the other workspace.

And then for network cues with duration, I haven't done that with Touch OSC or anything, but maybe there's something looping in the second workspace to periodically trigger the other workspace...? But that's a similar concept to the wall-clock triggers.

[micpool]

On Wednesday, March 24, 2021 at 9:49:37 PM UTC taylo...@gmail.com wrote:

Throwing in another trick that can work in some cases...

Opening a second QLab workspace on the same machine. This makes a "panic proof" workspace while focus is on a regular show workspace.

Yes, there are many methods involving a second application, but I think there is some virtue in the portability of QLab workspaces  that do not rely on a second application to function.

 For second application methods, people have used Max or Vuo patches, second  QLab workspaces, as you suggest, or even dedicated Arduinos to send the OSC.  The simplest is just to save an AppleScript as an application, and run a script to start it as a 'when workspace opens'  script cue in QLab with:

try

tell application "Don't Panic" to activate --change to your app name

tell application id "com.figure53.QLab.4" to activate

end try

If your app uses an  AppleScript , it should strictly speaking use an 'on idle loop', but for some reason, In Catalina anyway,  it seems to interpret idle rather loosely, and stops sending now and again and resumes a bit later. My version uses a repeat loop with a test to see if QLab is open, so the app will only run if QLab is open, will close automatically when QLab is closed, and can't be quit by any normal method. This is a bit irregular, but actually for this purpose works well.

Here's the script:

-- Don't Panic AppleScript edition

-- save as application from script editor with no check  boxes ticked

-- Will ONLY quit automatically when QLab is closed. 

if application "QLab" is not running then

display dialog "Don't Panic will only run when QLab is open" buttons {"Quit"}

return

end if

repeat

do shell script "echo " & "/cue/dontPanic/start" & " | nc -u -w 0 127.0.0.1 53535"

delay 0.5

if application "QLab" is not running then return

end repeat

quit

If you make the cue numbered "dontPanic" a timeline group cue  you can put anything you like in it and extend the execution interval  for individual cues in the group with  pre or  post waits e.g you could have a script cue for an auto save routine with a pre-wait of 5 minutes, so that would execute every 5 minutes even though the group is being triggered every 0.5s 

 Mic