Quirk when targeting "cue <i>" in Applescript

85 views
Skip to first unread message

MattM

unread,
Mar 18, 2018, 4:47:47 PM3/18/18
to QLab
Wondering whether this is an Applescript thing or a QLab thing...

I was running a little test to see how long it takes QLab to iterate through a previously-identified set of cues with identical q names, and I came across something odd.

In the attached workspace, I have five Note Cues in the one and only cue list.  The cue list's name is the default "Main Cue List".  The five Note Cues are each named "This Is A Cue."  In the Script Cue (with q number 6) ("RUN ME"), there's the following Applescript:

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

      set theCues to ((every cue whose q name begins with "This Is A Cue"))

        set numberOfCues to (count of items in theCues)

        repeat with i from 1 to numberOfCues

           

               set the q name of cue i to "I am Cue Number " & i

             

        end repeat


end tell


Now, what I had intended to do was to re-name all five Note Cues to "I am Cue Number" [1-5].  If you run the script, though, you'll see that I messed up.  

In the "repeat" statement, I forgot to tell QLab that I wanted it to iterate through the items previously identified when {theCues} was created in the first line of the tell block.  So rather than setting the q names of (items 1 - 5) in my list, {theCues}, the script is trying to set the q names of cues 1 - 5 in the workspace.  That is, saying

 set the q name of cue i to "I am Cue Number " & i

is valid Applescript, even thought it's not clear from the script (and again, I messed up) what "cue i" refers to.  Is that cue number i, or some other designation?

Here's where it gets weird.  If you run the script in Cue 6, you'll see that QLab changes the names of "cues 1 to 5" to "I Am Cue Number <x>."  But instead of renumbering the five cues with q numbers 1-5 (the five Note Cues in the workspace), QLab renumbers the "Main Cue List" as "I Am Cue Number 1," and the first four Note Cues (that is, Note Cues with q numbers 1-4) as 2-5.  

It appears that using "cue i" syntax gets you a flat list of the cues in the workspace, with the Main Cue List being cue 1, and the "child cues" of the Main List being numbered 2 to xxx.  True?  Using "cue i" is clearly not targeting by q number.

I don't know that I'd intentionally use this way of addressing cues, but I was surprised to see that this was possible.  It's a very Applescript way of iterating through a list of items, but it's somewhat foreign to the concepts we use in QLab -- not a q name, apparently not a q number or a unique ID.

Demo Workspace.qlab4

Chris Ashworth

unread,
Mar 18, 2018, 7:16:23 PM3/18/18
to ql...@googlegroups.com
Without digging in to it, this (or something like it) sounds likely. 

Which is to say, this sounds like just the sort of thing that drives me crazy about AppleScript: in an effort to be friendly it’s instead ambiguous, which turns friendly into “crazy-making"

micpool

unread,
Mar 18, 2018, 7:28:57 PM3/18/18
to QLab
Cue i could be anything


set the q name of cue (i as string) to "I am Cue Number " & i


would refer to the cues numbered 1 to 6


Mic

MattM

unread,
Mar 18, 2018, 9:36:18 PM3/18/18
to QLab
weird...as Mic suggests, when it's (i as string) and not (i as number) it's parsed differently -- as if you're trying to target by q number.  

If the cues are q numbered 1-5, and you replace the line in my script with the one Mic mentions above (set the q name of cue (i as string) to "I am Cue Number " & i), it correctly hits the five cues named "I Am a Cue."  The name of the Cue List is untouched.

Now try changing the third cue's q number from "3" to some non-sequential number -- say, "15".   When you run the script, it breaks after renaming the first two cues, saying it can't renumber cue "3" (because it doesn't exist).

Undo everything in the script, and now renumber the third cue as #15, and the fifth cue as #3.  The script will renumber the four cues with q numbers between 1 and 5, and break when #15 doesn't work.

Chris -- > without having any idea personally what's going on under the hood in Applescript, I guess I can't really appreciate that aspect of it.  But thanks for fighting the good fight. ;)  QLab's Applescript capabilities make it such a deeper program.

Cheers,
M2
Message has been deleted

micpool

unread,
Mar 19, 2018, 4:01:41 AM3/19/18
to QLab
It’s not weird at all really. Cue 1 is meaningless. Generally it will be the earliest  cue created, currently in the workspace. Once you have a few cue lists and have created more cues and moved them around you will have no idea what cue 1 is or any other cue referred to by a number, which is why we never use it in scripts and refer to cues  by their q number string or id. 

Obviously a q number string has to exist for the  script not to break. 

In your case what you wanted to do was :

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

set theCues to ((every cue whose q name begins with "This Is A Cue"))

repeat with mycue in theCues

set the q name of mycue to "I am Cue Number " & q number of mycue

end repeat

end tell



Mic

micpool

unread,
Mar 19, 2018, 4:39:52 AM3/19/18
to QLab
On Monday, March 19, 2018 at 8:01:41 AM UTC, micpool wrote:
Cue 1 is meaningless. Generally it will be the earliest  cue created, currently in the workspace. 

Sorry that wan't entirely correct. cue 1 (as opposed to cue "1")  is just a positional index within the workspace. For practical purposes it is unusable and best avoided.

Mic

Rich Walsh

unread,
Mar 19, 2018, 7:09:18 AM3/19/18
to ql...@googlegroups.com
I think the key thing is to understand that QLab has optionally implemented a unique name reference form for each cue, which it has identified as the “q number” property – see the AppleScript Language Guide.

If you compile this:

cue whose name is "1"

It becomes:

cue whose q number is "1"

If you find it confusing that cue 1 is always the first cue list, while cue “1” is the cue named “1” (that may or may not exist) then perhaps using the verbose form would be easier:

cue named "1"

It is entirely consistent across all scriptable applications and not remotely quirky: using an integer specifies a position in a list (eg: document 1 of application id "com.figure53.QLab.4"), whilst using a string invokes the name reference and attempts to specify an object by name (document "Don't Panic!" of application id "com.figure53.QLab.4").

If you don’t follow why the first cue list is cue 1 then look at QLab’s AppleScript Dictionary:

cue listn [inh. group cue > cue] : A cue list.
elements
contained by workspaces.
properties
playback position (cue) : The playback position of this cue list is the cue that will fire at the next GO.
playhead (cue) : The playhead (playback position) of this cue list is the cue that will fire at the next GO.
sync to timecode (enabled/‌disabled) : Sync the cues in this cue list to incoming timecode.
sync mode (mtc/‌ltc) : Which kind of incoming timecode this cue list listens for.
smpte format (fps_24/‌fps_25/‌fps_30_drop/‌fps_30_non_drop) : SMPTE format of the incoming timecode.
mtc sync source name (text) : Name of the MIDI device which feeds us MTC timecode.
ltc sync channel (integer) : Audio channel that carries the LTC signal.
inherited from group cue
properties
responds to
expandcollapse.

You can see from its inheritance that a cue list is just a special form of Group Cue.

If you want a truly unique identifier for every cue that it _must_ have, use “unique id”. It used to be an integer, but is now a UUID.

I strongly recommend reading the AppleScript Language Guide and QLab’s AppleScript Dictionary before doing any serious work with AS in QLab.

Rich
Reply all
Reply to author
Forward
0 new messages