Remote collaborator script cue execution scope

[sam.sc...@gmail.com]

With collaboration in QLab 5, using script cues as custom hotkeys has a new twist to it. Triggering script cues with keyboard hotkeys, from a Remote workspace, executes the script on the Primary workspace. This means that what the script cue interprets as "selected" is based on the selection in the Primary workspace, regardless of which collaborator triggered it.

I'm sure I'm not the first person to encounter this, so I would love to hear what strategies other users are pursuing to "scope" their scripts.

It seems that if I open a script in the Script Editor app on a remote machine, and run it from there, it interprets the selection from the perspective of the Remote machine (which makes sense). Is the best practice to store your hotkey scripts outside of the workspace entirely, and trigger them by reference somehow?

Looking forward to hearing what folks are doing!

Cheers,

Sam

[Sam Kusnetz]

Hi Sam

This is something we’re aware of and have no immediate solution for. When you run a cue in a remote workspace, the cue is actually running in the primary workspace, so when a script refers to the selection, it necessarily gets the selection on the primary.

I think the long term way forward is for us to add script hooks for getting and setting remote selection, but I don’t have a timeline to share on that.

Best

Sam

 

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/3a5fa0cb-4021-44a7-ac81-99ddcd225343n%40googlegroups.com.

[sam.sc...@gmail.com]

I'm thinking I'll probably find a way to make an isolated setup on the remote machine and trigger it from a dedicated device like a StreamDeck. That probably means a background/minimized workspace in which the scripts still reference the frontmost workspace. I think that will easily be sufficient and I imagine will mostly work out of the box! I might even start doing this as standard practice regardless of whether I am Remote or Primary.

In terms of a longer-term built-in solution to this:

I wonder if it's technical achievable to have a checkbox in the script cue itself (much like the "Run in separate process" checkbox) which could say "Run in user context". This would send instructions back to the Remote workspace to execute the script locally.

[FL K]

On Thursday, 20 April 2023 at 03:08:35 UTC+10 sam.sc wrote:

I'm thinking I'll probably find a way to make an isolated setup on the remote machine and trigger it from a dedicated device like a StreamDeck. That probably means a background/minimized workspace in which the scripts still reference the frontmost workspace. I think that will easily be sufficient and I imagine will mostly work out of the box! I might even start doing this as standard practice regardless of whether I am Remote or Primary.

Interesting, but would you not need to still somehow communicate/track from the remote machine to the primary machine which cue you have selected on the remote machine - and, would that even be possible in the current state of affairs? 

In terms of a longer-term built-in solution to this:

I wonder if it's technical achievable to have a checkbox in the script cue itself (much like the "Run in separate process" checkbox) which could say "Run in user context". This would send instructions back to the Remote workspace to execute the script locally.

Love that idea - so if implemented well, that could than be called by a user from the primary machine and it would use their selection, and from a user from the remote machine and it would use their selection... hopefully achievable :)!

Cheers,

Freddy 

[sam.sc...@gmail.com]

I'm thinking I'll probably find a way to make an isolated setup on the remote machine and trigger it from a dedicated device like a StreamDeck. That probably means a background/minimized workspace in which the scripts still reference the frontmost workspace. I think that will easily be sufficient and I imagine will mostly work out of the box! I might even start doing this as standard practice regardless of whether I am Remote or Primary.

Interesting, but would you not need to still somehow communicate/track from the remote machine to the primary machine which cue you have selected on the remote machine - and, would that even be possible in the current state of affairs? 

There would be no need for either machine to know the selection of the other. The script would run locally on the remote machine. It would only be aware of the selection on the remote machine, and the selection on the Primary would be irrelevant.

To be clear, the Scripts workspace would be a Primary workspace, which was minimized in the background on the same machine that was connecting to the Show workspace as a Remote.

The scripts would be written to "tell front workspace," so they would act upon the Show workspace but in the context of the Remote collaborator. Therefore "selected" would refer to the selection on the Remote; awareness of the selection on the Primary machine would not be needed (or available).

Will report back on how it goes!

 

[Sam Kusnetz]

On Apr 19, 2023 at 8:44:58 PM, sam.sc...@gmail.com <sam.sc...@gmail.com> wrote:

I'm thinking I'll probably find a way to make an isolated setup on the remote machine and trigger it from a dedicated device like a StreamDeck. That probably means a background/minimized workspace in which the scripts still reference the frontmost workspace. I think that will easily be sufficient and I imagine will mostly work out of the box! I might even start doing this as standard practice regardless of whether I am Remote or Primary.

I can confirm that this approach works nicely. Here’s my setup:

My show workspace is running on the primary Mac. In that workspace, my set of scripts are disarmed.

On the remote Mac, I’m connected to the primary and I also have a separate workspace, running locally, which contains all my scripts. This second workspace is minimized, but of course it still catches hotkeys.

It works for me because the person sitting at the primary doesn’t need to run scripts, but I do. If they also needed to run scripts, we’d need some other solution.

Nice thinking, other Sam!

[micpool]

On Thursday, April 20, 2023 at 8:52:35 PM UTC+1 sam kusnetz wrote:

It works for me because the person sitting at the primary doesn’t need to run scripts, but I do. If they also needed to run scripts, we’d need some other solution.

Although there may be a neater solution to this that can be incorporated in later versions, isn't all that is required  at the moment just to use different hotkeys in the primary machine and in the minimised cue list on the mac that is also running the Collaboration window?. (Or no hotkeys at all on the minimised cue list and just trigger from MIDI,  OSC, or Streamdeck)  e.g  Hotkey 1 in the Workspace on the primary sets the level of the main fader of the selected cue (on the primary) to -15, Hotkey shift 1 on the collaborative mac, triggers a cue in  the minimised workspace which sets the level of the cue selected in the collaboration window on the collaborative Mac to -15. This way  both macs can make changes to their own selected cues  using the same scripts. 

Mic

[Taylor Glad]

In terms of a longer-term built-in solution to this:

I wonder if it's technical achievable to have a checkbox in the script cue itself (much like the "Run in separate process" checkbox) which could say "Run in user context". This would send instructions back to the Remote workspace to execute the script locally.

+1 to that. With the workaround method of separate minimized workspaces, that requires a license on the remote Mac, while the 3rd "edit" seat of the licenses has been replaced with the single full-feature collaborator without a license. So other Sam's suggestion would remove the need to have a license on the remote computer just to run scripts.

Apple's Shortcuts app can run AppleScripts and assign them to hotkeys (and you can even color code them or give them icons) but it doesn't work unless Shortcuts is in focus, so you'd have to keep clicking between QLab and Shortcuts. And it you can't trigger them with Companion so to use a Stream Deck you'd have to rebuild using the Stream Deck app and a plugin to run AppleScripts.

But if there were something out there cheaper than $500 (1 QLab license) that ran AppleScripts triggered by hot keys or Companion, then that would be all you really need.

[micpool]

Osculator will do that for 20€

[micpool]

Hi Sam

Just found another gotcha on remote collaboration scripts

In the attached screen recording Left to right QLab running on Main Computer, Screenshare from Collaborating computer showing collaboration window and a QLab5 workspace with triggered scripts as described in your setup.

The script run is 

--put a single selected cue into a timeline group

tell application id "com.figure53.QLab.5" to tell front workspace
set theCue to last item of (selected as list)
set theCueID to uniqueID of theCue
set theQnumber to q number of theCue
set theQname to q list name of theCue
set the q number of theCue to ""
make type "group"
set theGroup to last item of (selected as list)
set the q number of theGroup to theQnumber
set the q name of theGroup to theQname
move cue id theCueID of parent of theCue to end of theGroup
end tell

The collaboration machine shows the correct result i.e the selected cue is put inside a timeline group.

In the main workspace the selected cue is completely lost from the cue list

Best Mic

On Thursday, April 20, 2023 at 8:52:35 PM UTC+1 sam kusnetz wrote:

[Sam Schloegel]

I have recently found a similar issue, with cues completely disappearing from the cue list on the Primary. Haven't had a chance yet to reach out to support about it.

--

Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---

You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/t42yH2et8Yw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/958ee529-ccc0-4182-a0cf-72ed9bd85e9dn%40googlegroups.com.

[Ethan Eldred]

Been trying this. Confirming this should only work with Script cues, and not OSC as of 5.2?

Thanks!

Ethan

[Maik Waschfeld]

Hi Taylor,

But if there were something out there cheaper than $500 (1 QLab license) that ran AppleScripts triggered by hot keys or Companion, then that would be all you really need.

„FastScripts“ <https://redsweater.com/fastscripts/> can assign hotkeys / keyboard shortcuts to AppleScripts.

With kindest regards…
…Maik Waschfeld

(sent from my MBPro16,2)
also at <mailto:Maik.Wa...@Staatstheater-Stuttgart.de>

--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/3858197a-ef15-4fe3-8f4f-8ac26d0fe5a5n%40googlegroups.com.

[Liam Shaffer]

I am in a similar situation trying to a qlab cookbook scrip to automatically select the last cue played

https://qlab.app/cookbook/waveform-focus/

when I run the script in a separate workspace with the remote workspace in front, I get the no valid cue error built into the script. Is there something about the running parameter that can't identify cues running through a remote workspace?

I am new to apple script, so any insight is welcome

Thank you

~Liam

[Sam Kusnetz]

Hi folks

It is not currently possible to run Script cues locally on the remote Mac.

We totally understand and agree with the need for this feature.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

Follow QLab on Threads: https://threads.net/@QLabApp

User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qlab/faf76ce3-7ab6-4e37-b041-17c8af97c314n%40googlegroups.com.