Get attributes of Script cue from AppleScript

174 views
Skip to first unread message

m...@stevensokulski.com

unread,
Sep 3, 2020, 10:36:42 AM9/3/20
to QLab
I'm working on a system where QLab can programmatically control a browser-based streaming platform. This works by using AppleScript to send Javascript to a Chrome tab.

I'm wondering if it's possible to collect information about a Script cue from the AppleScript of the cue itself. Things like the name or notes field would be helpful in making these cues easier to customize.

Right now I have to edit the Javascript of each cue. But if I could edit the name instead that'd be a little less prone to error.

micpool

unread,
Sep 3, 2020, 10:54:32 AM9/3/20
to QLab
If you want the cue to self reference, the currently playing script cue is 

set mycue to  last item of (cues whose running is true and q type is "Script")

you can then get any properties of mycue in this list

script source (text) : AppleScript source for the cue. The script will be recompiled when set.


uniqueID (text, r/o) : The unique ID of the cue.

parent (cue, r/o) : The parent cue of this cue.

parent list (cue, r/o) : The parent cue list (or cue cart) that contains this cue.

q type (text, r/o) : The name of this kind of cue, e.g. "Audio", "Video", "MIDI", etc.

q number (text) : The number of the cue. Unique if present.

q name (text) : The name of the cue. Not unique.

q list name (text, r/o) : The name of the cue as displayed in the cue list. (i.e. Might be a default name.)

q display name (text, r/o) : The name of the cue as displayed in the standby view. (i.e. Never empty.)

q default name (text, r/o) : The name QLab would give the cue by default, if any.

q color (text) : The name of the cue color, or 'none' if not set.

notes (text) : The notes for this cue.

cue target (cue) : The cue this cue targets, if any.

file target (file) : The file this cue targets, if any.

pre wait (real) : The time in seconds before the action is triggered.

duration (real) : The duration of the cue's action in seconds. Not editable for all cue types.

temp duration (real) : The temporary duration of the cue's action in seconds. Not all cues allow editing the duration. Setting the temporary duration does not mark the document as edited. Reset the cue to go back to the original duration.

current duration (real, r/o) : The current active duration of the cue's action in seconds. This property reflects the temporary duration, if it has been set. Otherwise it returns the cue's duration.

post wait (real) : The time in seconds until continuing on to the next cue.

continue mode (do_not_continue/‌auto_continue/‌auto_follow) : Continue mode of the cue.

flagged (boolean) : Is this cue flagged?

autoload (boolean) : Does this cue auto load?

armed (boolean) : Is this cue armed?

hotkey trigger (enabled/‌disabled) : State of the HotKey trigger.

midi trigger (enabled/‌disabled) : State of the MIDI trigger.

midi command (note_on/‌note_off/‌program_change/‌control_change/‌key_pressure/‌channel_pressure/‌pitch_bend) : Type of MIDI command that will trigger the cue. (NOTE: pitch_bend messages are NOT accepted as remote MIDI triggers.)

midi byte one (integer) : Byte 1 of the MIDI trigger.

midi byte two (integer) : Byte 2 of the MIDI trigger.

midi byte one string (text) : Display String of Byte 1 of the MIDI trigger.

midi byte two string (text) : Display String of Byte 2 of the MIDI trigger.

timecode trigger (enabled/‌disabled) : State of the timecode trigger.

timecode show as timecode (boolean) : True if timecode trigger is shown as Timecode, false if shown as Real Time.

timecode hours (integer) : Hours field of the timecode trigger.

timecode minutes (integer) : Minutes field of the timecode trigger.

timecode seconds (integer) : Seconds field of the timecode trigger.

timecode frames (integer) : Frames field of the timecode trigger.

timecode bits (integer) : Bits field of the timecode trigger.

wall clock trigger (enabled/‌disabled) : State of the wall clock trigger.

wall clock hours (integer) : Hours field of the wall clock trigger.

wall clock minutes (integer) : Minutes field of the wall clock trigger.

wall clock seconds (integer) : Seconds field of the wall clock trigger.

loaded (boolean, r/o) : Is this cue loaded?

running (boolean, r/o) : Is this cue running?

paused (boolean, r/o) : Is this cue paused?

broken (boolean, r/o) : Is this cue broken?

pre wait elapsed (real, r/o) : The time in seconds that have elapsed on the pre wait.

action elapsed (real, r/o) : The time in seconds that have elapsed in the action of the cue.

post wait elapsed (real, r/o) : The time in seconds that have elapsed on the post wait.

percent pre wait elapsed (real, r/o) : The percent of the pre wait that has elapsed.

percent action elapsed (real, r/o) : The percent of the cue's action that has elapsed.

percent post wait elapsed (real, r/o) : The percent of the post wait that has elapsed.


Mic

Steven Sokulski

unread,
Sep 4, 2020, 3:26:23 PM9/4/20
to ql...@googlegroups.com
Thanks Mic. That worked great.

-- 
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/D3wkNd5BcSs/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/40408ed0-ab00-4dd9-8254-f482ea03215co%40googlegroups.com.

m...@stevensokulski.com

unread,
Oct 19, 2020, 3:15:04 PM10/19/20
to QLab
I've found a fringe case where this works a little less ideally.

If I fire multiple Script cues at the same time (via a Group cue, for example) then each cue gets the details of the most recently fired cue.

So far I've worked around this with a slight pre-wait on any subsequent group cues. It works, but isn't quite as clean to maintain.

micpool

unread,
Oct 20, 2020, 4:08:30 AM10/20/20
to QLab
Hmmm

I think what you are saying is that Applescripts run far slower than  the QLab main program, which is to be expected. 

In any computer programming you frequently have to force events to happen in a given order, hence some form of  delay or wait in most computer languages.

Other examples in QLab would include looping a timeline group with a start cue within the group, without a delay, the start cue often hasn't completed when the timeline group fires and therefore the next loop iteration doesn't happen


Regardless of the inconvenience of having to slow down QLab with pre-waits to give Applescript time to execute, as far as I know this has been the only method we have found in the last five years for a script to be aware of the cue that contains it, so I think you probably have to live with that limitation.

Mic

Rich Walsh

unread,
Oct 20, 2020, 6:33:14 AM10/20/20
to ql...@googlegroups.com
This is the only method we've found for a Script Cue to identify itself dynamically. If, however, you can give the Script Cue a Cue Number ("X") then it is uniquely identifiable by AppleScript as cue "X", no matter what order things are processed in.

I can't actually remember why I've ever needed to do this dynamically now… I did find the same question back in 2011: https://groups.google.com/g/qlab/c/SQPRzXQOb8Q/discussion!

Rich

On 20 Oct 2020, at 09:08, micpool <m...@micpool.com> wrote:

as far as I know this has been the only method we have found in the last five years for a script to be aware of the cue that contains it

<snip>

Steven Sokulski

unread,
Oct 20, 2020, 12:46:18 PM10/20/20
to ql...@googlegroups.com
That makes sense. My reasoning was that I’m making a set of AppleScriots available to other users of a particular livestream tool. Being able to parse the title would make editing the functionality of a particular cue easier in this case. But it’s probably not worth the added complexity with regard to adding waits to insure the scripts execute in the right order.

Sent from my iPhone

On Oct 20, 2020, at 3:33 AM, 'Rich Walsh' via QLab <ql...@googlegroups.com> wrote:


--
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/D3wkNd5BcSs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.

Steven Sokulski

unread,
Oct 20, 2020, 12:51:03 PM10/20/20
to ql...@googlegroups.com
Fair enough. It’s a small limitation all things considered.

If I were king of the world, there would be some sort of context that the script cue runs it with information about itself and its own status. Something akin to the “this” keyword in JavaScript functions. But admittedly the use case is small.

Sent from my iPhone

On Oct 20, 2020, at 1:08 AM, micpool <m...@micpool.com> wrote:

Hmmm
Reply all
Reply to author
Forward
0 new messages