Macro cues when using workspace collaboration

[Dan Steele]

I have a whole bunch of macro cues, such as level bump cues etc, that are essential to my workflow.  When collaborating from on a remote workspace in Qlab 5 they only work on the cue that is selected in the main workspace, not the cue that is selected in my remote workspace.  Has anyone found a workaround for this.  I keep adjusting levels and such in cues that the operator has selected and not the cue I'm viewing.  For now I'm going to go back to screen sharing.

Any tips to work around this?

[Sam Kusnetz]

Hi Dan

The reason this doesn’t work right now is that the script, which actually runs on the primary even if it’s triggered from a remote, has no way to know which cue or cues you have selected on your remote.

We certainly understand this workflow and we hope to have a good answer sometime soon. Right now, though, scripts and OSC messages are only able to “know” about the selection on the collaboration primary.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

On Mar 28, 2023 at 8:02:03 AM, Dan Steele <d...@unlimitedheadroom.com> wrote:

I have a whole bunch of macro cues, such as level bump cues etc, that are essential to my workflow.  When collaborating from on a remote workspace in Qlab 5 they only work on the cue that is selected in the main workspace, not the cue that is selected in my remote workspace.  Has anyone found a workaround for this.  I keep adjusting levels and such in cues that the operator has selected and not the cue I'm viewing.  For now I'm going to go back to screen sharing.

Any tips to work around this?

--
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/50b87aa2-f631-4e11-af07-d4d105416574n%40googlegroups.com.

[Rich Walsh]

In the absence of a secondary “collabaration selected” property of a workspace, the workaround is as here: https://groups.google.com/g/qlab/c/0R6Pdxswy00/m/w96DR9cSBQAJ.

Instead of keeping your (AppleScript) editing macros in the workspace you are editing, keep them in a background workspace on the computer you are using to do the editing. Things like “selected of front workspace" then become what’s selected in your local workspace, not what’s selected on the primary machine.

I can't see a way of getting OSC to work like this though as the "remote workspace" doesn’t seem to exist in an addressable way – in fact, you can’t even turn on “Allow OSC connections” for it…

From an AppleScript point of view, I guess we’d eventually be looking for something like this?

tell application id "com.figure53.QLab.5" to tell front workspace

if collaboration status is primary then

set selectedCue to last item of (collaboration selected as list)

else

set selectedCue to last item of (selected as list)

end if

end tell

Need a couple more properties of the workspace class for that though… Mind you, I can see the massive problem here as there are at least four variations to consider:

1. Script is triggered directly on the primary machine and should act on its selection
2. Script is triggered directly on the primary machine and should act on the remote selection
3. Script is triggered by the remote machine and should act on the primary selection
4. Script is triggered by the remote machine and should act on the remote selection

Maybe just easier to keep scripts local?

Hmm, tricky…

Rich

[Dan Steele]

OK, I get you.   Thanks for the tip. But it's not a fully workable solution as you say, as it doesn't help for OSC cues.  I guess we need for the remote collaboration workspace to be able to accept OSC cues like the main workspace can, but that they act on the cues it has selected.  And for a few more script properties like you suggest, then keep all macros hosted locally in a background workspace, and trigger them from that to act on the front workspace.  I often have them in a separate workspace anyway once we get to start running dress cues.  It's simpler than disabling, and enabling all my programming Cue Lists to just host them separately.  

For now I'm just not going to use workspace collaboration, it's just not useful to me yet.  I can't work at a fraction of the speed I'm used to if I have to start using my mouse to control things that I do with the macros, some of which do some fairly complex sequences in a flash, and having a kluge of Apple script and OSC macros being inconsistent isn't helpful.  

Back to the KVM or screen share solutions as we've done up until now.  Hopefully this feature can be improved to enable working like this efficiently as it's potentially a brilliant feature, I think it's just not there yet.

Thanks all for your input!

Dan

[Richard Williamson]

Would be great to follow what Eos does - where each macro (or in this case network or script cue) has an option to set a user number, and each user who logs in specifies a user to log in as. 

In Eos this means that two people can be logged in as the same user and they share a cursor and command line

One of the issues that is stopping me from using collaboration mode much so far is that I can’t find a way for the remote workspace to “follow along” with the main workspace, making it really annoying to actually use during a show. This may be my own error so if there is a solution it would be great to know!

Thanks

Richard

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

--
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/1ace88d7-c16d-41c2-8e18-b7b6f6a6631cn%40googlegroups.com.