Using Scripts from. Remote Instance

[Anthony Narciso]

Hello! I’ve found that in Qlab 5, my scripts have been rendered fairly useless when working from a remote instance. For example, if I have a script that creates a fade out cue, it does this for whatever the main computer has selected vs what I have selected in the remote. Is there a solution to having scripts target the “remote front workspace” instead of the primary machines’s front workspace? 

[Chris Ashworth]

Hi Anthony,

Thanks for this question!  We’re definitely tracking and thinking about how to make sure Scripts remain as useful as possible.

One thing I’m puzzled about: from your description, I would expect this to work the opposite way, where the selection should be what is selected on your machine in front of you, not what is on the primary machine that you are connected to.

Can you give an example of a script you use so we can try it directly?

Best,

Chris

[Anthony Narciso]

Sure! So if i use this script that I've come to love from Rich Walsh, it groups the cue currently selected on the primary computer (the playhead) instead of what I have selected in a remote instance (which is almost never the playhead now).

tell front workspace
   
    set selectedCues to (selected as list)
   
    if (count selectedCues) is not 0 then
       
        set selected to last item of selectedCues -- Protect against default behaviour
        make type "Group"
        set groupCue to last item of (selected as list)
        set groupCueIsIn to parent of groupCue
       
        set cueNumber to q number of first item of selectedCues
        set q number of first item of selectedCues to ""
        set q number of groupCue to cueNumber
       
        set cueNames to {}
        repeat with i from 1 to count selectedCues
            set eachName to q list name of item i of selectedCues
            if eachName is not "" then
                set end of cueNames to eachName
            end if
        end repeat
        set currentTIDs to AppleScript's text item delimiters
        set AppleScript's text item delimiters to " & "
        set q name of groupCue to cueNames as text
        set AppleScript's text item delimiters to currentTIDs
       
        set cueNotes to notes of first item of selectedCues
        set notes of first item of selectedCues to ""
        set notes of groupCue to cueNotes
       
        repeat with eachCue in selectedCues
            if contents of eachCue is not groupCueIsIn then -- Skip a Group Cue that contains the new Group Cue
                set eachCueID to uniqueID of eachCue
                try
                    move cue id eachCueID of parent of eachCue to end of groupCue
                end try
            end if
        end repeat
       
    end if
   
end tell"

[Rich Walsh]

I have to say that the behaviour is exactly what I’d expect: selected is a property of the workspace on the primary machine, so the script acts on that. From a very brief play, I can’t change the selection on the remote machine so it makes perfect sense that scripts will act on the selection I can actually make, ie: that on the primary.

To be very clear, I had two workspaces open on the remote and connected the primary to one of them, whilst also having a template running on the primary to give me access to the hotkey script. I had different cues selected on the primary and the remote. Running the script from primary, the cue selected on primary was grouped. Running the script on the remote (from a local hotkey there), the cue selected locally was grouped. The two background workspaces were reassuringly untouched.

However, it was not without bugs: I’ve attached screenshots of the state of the workspace as seen from primary and on the remote after grouping a couple of cues like this. On the primary, it looks correct with 7 cues – I started with 5 then ran the script on two of them. On the remote, the cues that have been moved have disappeared, so only 5 cues left… It is disconcerting to be supposedly looking at the same workspace from two computers simultaneously and have them show different contents…! Even worse, once saved and reopened the cues primary could see but remote could not were gone for good from the workspace…

It’s going to take me several weeks to retest and rewrite everything for v5; I suppose I’m going to have to test everything against remote workspaces too… Crikey.

Rich

[Rich Walsh]

I’ve got my terminology 100% wrong: by “primary” I meant the remote client, and by “remote” I meant, well, the remote workspace (on the primary…?). I connected to a “Remote Workspace” which is the primary to then interact with the remote workspace, even though I was sitting at the remote (with a purple header) and the workspace I was controlling was the primary. Maybe I should have read the manual first…

So, replace “primary” below with “client” and “remote” with “server” (a better word than primary in my mind, but maybe “serving” isn’t the right word for it any more?).

Rich

<Primary.png><Remote.png>

-- 
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/E872CAF8-D6D6-4D6F-A58E-20EEFF369016%40mac.com.

[Andy Leviss]

On Thu, Sep 8, 2022 at 5:59 PM Anthony Narciso <anthonynar...@gmail.com> wrote:

Hello! I’ve found that in Qlab 5, my scripts have been rendered fairly useless when working from a remote instance. For example, if I have a script that creates a fade out cue, it does this for whatever the main computer has selected vs what I have selected in the remote. Is there a solution to having scripts target the “remote front workspace” instead of the primary machines’s front workspace?

Are your scripts living on the primary, or the remote? I suspect the difference between your results and Rich’s (correcting for his nomenclature confusion) is that your scripts are living on the primary machine, while his are on the remote. 

My hunch, without being able to test it, is that the scripts act on the selection on the computer they are running on. So the answer may be that your macro scripts need to live locally on your remote computer. 

(I actually think that’s fantastic, as I always keep my macros in a secondary workspace, and this means not having to copy it to the show computer, or remember to delete it after we lock the show.)

-Andy

[Anthony Narciso]

Oh wow, that thought didn't even cross my mind Andy. My scripts were on the primary machine, so I will definitely try them out in a workspace on the machine running the remote workspace. It'll be a while before I'm back in a space running V5 but I will definitely experiment with that as soon as I can. Thanks for the help everyone!