Disarm a video AND the postwait

[Patrick Spadrille]

I have a series of videos that are played one after another in auto continue. Sometimes i need that one of those videos is not read. Of course i can move it on another place but i'm looking for a better way to do this that doesn't include some drag and drop that can be a little tricky at times. I really would like to just arm the video when i need it and disarm it when i don't. But when i disarm a video, the problem is that the postwait still does it's job. So instead of a one minute video i have a one minute black which is not what i'm looking for. Is there any setting or way to program the cues so that i just have to disarm a cue to exclude one video from my video list to be played?

[micpool]

Not easily,

This is a work around

Insert a script cue with this script before each block of disarmed cues and they will be skipped.

set theflag to false

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

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

repeat while theflag is false

set mycue to cue after mycue

if armed of mycue is true then

set theflag to true

end if

end repeat

set the playhead of front cue list to mycue

start front cue list

end tell

[Patrick Spadrille]

Thank you for your help. I tried your script but it doesn't seem to work in my project. It just stop when it comes to the script cue. Am i doing something wrong?

[micpool]

Hi Patrick

I can't see any difference between your screenshots and my version (which I have tested on 2 computers)

Does the attached workspace work?

Mic

[Harry Halliday]

Here's another method that might be interesting:
If the arming/disarming process is always totally manual, we could replace that process with one that stores the intended post-wait or continue mode of a cue in its notes:

tell application "QLab" to tell front workspace

set theCue to last item of (selected as list)

set armed of theCue to not armed of theCue

if armed of theCue is false and continue mode of theCue is auto_follow then

set notes of theCue to "af"

set continue mode of theCue to auto_continue

set post wait of theCue to 0

else if armed of theCue is false and continue mode of theCue is not auto_follow then

set notes of theCue to post wait of theCue as text

set post wait of theCue to 0

else if armed of theCue is true and notes of theCue is equal to "af" then

set continue mode of theCue to auto_follow

else if armed of theCue is true then

set post wait of theCue to notes of theCue as real

end if

end tell

Give this script a hotkey trigger (e.g. Shift+A) and arm/disarm individual cues using Shift+A (obviously won’t work with multiple cues at once in this iteration, but it could) - this will store the post wait in their notes and restore it when re-arming the cue. This obviously requires that you’re not already using the notes field of the cue.

This runs much more quickly when not running as a separate process. 

I think Mic’s solution is better as a more general concept because it allows programmatically disarmed cues to still be skipped, but thought I’d share some thoughts regardless.

Harry

[Patrick Spadrille]

Hi Mic,

I tried your Qlab project and the skip cue works fine in it. Then i have tried to copy all your cues into an empty list in my Qlab project and there it does'nt work. As soon as it hits the script cue, it just stop. What could it be?

[micpool]

On Friday, July 23, 2021 at 10:43:16 AM UTC+1 patrick....@gmail.com wrote:

Hi Mic,

I tried your Qlab project and the skip cue works fine in it. Then i have tried to copy all your cues into an empty list in my Qlab project and there it does'nt work. As soon as it hits the script cue, it just stop. What could it be?

That's very odd. Sometimes these things are a localisation issue, I assume you are using a Belgium Localisation. What Language are you using?  

I did try to replicate by changing the localisation settings on my computer but couldn't break it.

Try changing the line 

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

to

set mycue to last item of (active cues as list)

If that doesn't work  re-bundle your  workspace with my cues  cut and pasted, and attach to a post, with details of QLab version and OS you are using.

[Patrick Spadrille]

I tried modify the script line as you propose but i have the same issue, it just stop.

I use Mac OS in french. and I'm on Mac OS 10.15.7 and Qlab 4.6.9.

I have find something very interesting. If i delete all my other cue lists, the test works fine. But as soon as i have just one other list, even empty, it stops working. 

I hope this helps.

[Patrick Spadrille]

I tried to upload the Qlab bile on this forum but it doesn't work. So, her is the same file downlobable with wetransfer. https://wetransfer.com/downloads/14a46bee28b742db7e7543cf3d2b6cf120210724054143/bc895e8667d6d86fdca3ba9f6386685c20210724054200/2f8721

[micpool]

I'm still trying to work out why it doesn't work with multiple cue lists on your system (it does on mine), but this is a much better version of the script anyway. As well as finding the calling script cue dynamically, it also finds the cue list the script cue is in and acts on that list explicitly.

set theflag to false

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

set mycue to last item of (active cues as list)

set mylist to parent list of mycue

repeat while theflag is false

set mycue to cue after mycue

if armed of mycue is true then

set theflag to true

end if

end repeat

set the playhead of mylist to mycue

start mylist

end tell

Does this work for you?

Mic

[micpool]

Sorry, my fault, it's now obvious why it wasn't working for you.

Front cue list isn't a good way of referencing the cue list, as it means the first cue list in the cue lists pane, so only works if the cue list containing the script cue is the first list

Current Cue List, would have worked if the cue list containing the script was the list in the main QLab window, but would fail if the script cue was triggered in a different list.

So the proper way of programming this is  explicitly finding the parent list  of the script cue dynamically with:

set mylist to parent list of mycue

Restoring the original, more thorough, method of finding the script cue dynamically ,the script to use is this one, (which will run much faster if  'run in separate process' is not checked):

set theflag to false

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

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

set mylist to parent list of mycue

repeat while theflag is false

set mycue to cue after mycue

if armed of mycue is true then

set theflag to true

end if

end repeat

set the playhead of mylist to mycue

start mylist

end tell

Mic

[micpool]

For completeness, it's probably worth posting here a related method for skipping over disarmed cues in the CURRENT cue list, after any GO.  (you can combine this with the method in the previous post to also skip disarmed cues in auto continue sequences)

First, in settings/keymap and settings/MIDI controls,  disable the normal GO triggers (Space and Musical MIDI if used)

Make a script cue and set its triggers to the normal GO triggers (Space and Musical MIDI if used) 

set skip to true

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

go

repeat until skip is false

set thecue to last item of (selected as list)

if the armed of thecue is false then

moveSelectionDown

else

set skip to false

end if

end repeat

end tell

Mic

[Patrick Spadrille]

Yes, that works ! Thanks a lot, Mic ! I can see that you have put quite some work in it and i am very grateful about it. This Qlab community is the best EVER ! 

[Will]

Hi Mic I've been using your script for a while in QLab 5 to skip disarmed cues and it's a huge timesaver, thanks! 

It recently stopped working, I'm assuming because of an update to QLab. Eventually I got it working again by changing all mentions of "skip" to "theSkip" but now I'd like to add the ability to complete auto-continue/follow sequences if the last armed cue is set to auto-continue or auto-follow, and I'm having a lot of trouble.

This is the last working version of the script:

set theSkip to true

tell application id "com.figure53.QLab.5" to tell front workspace
if always audition is true then
audition go
else
go
end if
repeat until theSkip is false

set thecue to last item of (selected as list)
if the armed of thecue is false then

moveSelectionDown
else
set theSkip to false

end if
end repeat
end tell

All my attempts to add in the ability to complete auto-continue/follow sequences have failed, including by trying to add in parts of scripts from earlier in this thread, and I feel like I've hit a wall. Any suggestions for what I should try next?

Thanks in advance!

[micpool]

skip can't be a variable in QLab 5 because it is now a constant for the options in timecode start.

I can't think of a  sensible way to "add the ability to complete auto-continue/follow sequences if the last armed cue is set to auto-continue or auto-follow". 

Auto-continues and auto-follows play the next cue. if you try to override this behaviour to play the playhead cue instead of the next cue when the post wait of the last cue played is elapsed then you really have no way of knowing where the playhead might be by then.

And it doesn't seem to make much sense to try to make your workspace behave like this.  If you had a lighting cue auto continuing from a sound cue, and the next cue was another audio cue, would you really want the second audio cue to play with the first audio cue if you disarmed the lighting cue to try the sequence without it?

Mic

[Will Wade-Pentel]

That makes sense about skip, thanks.

Auto-continues and auto-follows play the next cue. if you try to override this behaviour to play the playhead cue instead of the next cue when the post wait of the last cue played is elapsed then you really have no way of knowing where the playhead might be by then.

Also makes sense. It seems that unless this feature is built into qlab, there isn't a good way to script it. 

Usually I want disarmed cues to behave exactly like they do. However, in certain situations I wish we had an option to skip a disarmed cue (individually per cue, not globally) so it can be a placeholder, essentially act like a deleted cue but with the advantage of easily being able to quickly restore it in a sequence. It would be amazing when designing a show and experimenting with different cues. Or in tech when a director is thinking about replacing an audio or video clip in the middle of a complex sequence and wants to go back and forth between options. Imagine if you had an option to disarm a cue and also skip it, you could place the alternative cue next to the old one and then just go back and forth disarming/arming the new and old cue each time you play the sequence.

Another scenario I've come across is when a director wants to replace an audio or video clip in the middle of a complex sequence "but isn't sure and we might change it back later" and then 3 days later decides actually they do want to use the original clip... Instead of deleting/moving the cue in the director's crosshair, it would be a huge timesaver when the director changes their mind and all you have to do is re-arm it. Once that sequence is locked in you can delete any cues you had marked as skipped.

And it doesn't seem to make much sense to try to make your workspace behave like this.  If you had a lighting cue auto continuing from a sound cue, and the next cue was another audio cue, would you really want the second audio cue to play with the first audio cue if you disarmed the lighting cue to try the sequence without it?

I had the same thought at first, but it's the same if you deleted or moved the lighting cue. So the more I thought about it, if there were a way to skip a disarmed cue (and it was clear in the UI it will be skipped), the less of an issue I think this point would be. Just like when deleting or moving a cue, the designer has to be conscious of how the cues before it are programmed.

I'm going to submit a feature request to figure 53 to see if adding an option to skip a disarmed cue (individually per cue, not globally) is possible.

--
Contact support anytime: sup...@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 a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/25qRYe8VxHg/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/e352726f-6d49-46a3-bf83-1f32b1e8f800n%40googlegroups.com.

[micpool]

On Wednesday, December 13, 2023 at 4:08:46 PM UTC Will wrote:

 Imagine if you had an option to disarm a cue and also skip it, you could place the alternative cue next to the old one and then just go back and forth disarming/arming the new and old cue each time you play the sequence.

Another scenario I've come across is when a director wants to replace an audio or video clip in the middle of a complex sequence "but isn't sure and we might change it back later" and then 3 days later decides actually they do want to use the original clip... Instead of deleting/moving the cue in the director's crosshair, it would be a huge timesaver when the director changes their mind and all you have to do is re-arm it. Once that sequence is locked in you can delete any cues you had marked as skipped.

The way I put alternative versions of cues in a workspace is to use a fire first (and go to next) group with all the cues in it. Then all you need to do is move the cue you want to play up to the top of the group, no arming or disarming necessary,  Any timing you do on the group.

Mic

[Will]

That's really clever. "Start first" (and do not enter) groups I probably use the least out of all the group modes, I really should explore it's possibilities more. Start first groups wouldn't achieve everything I want a skipped cue to do, but it's a nice workaround for that scenario. Thanks!