[QLab] Conditional cue
Wilf - KlankOntwerp
I can imagine something like this is not directly built in QLab as it can work counter-intuitive ("Why is the *&#$ cue not firing???") but for me it could be helpful in a very complex show in which I use QLab to play audio files, control a 01V96 and a Compulite Photon (both devices via MIDI). The Photon only accepts "Go" and only goes to the next lighting cue when a previous lighting cue has finished fading. This means that when I hit the Go-button in QLab when there is a lighting cue active the rest of the show goes out of sync.
Is there a way to do this with AppleScript maybe? One thing to add: I only give the lightinc cues numbers because they then correspond to the lighting cue I see on my lighting desk.
On a side-note: It would be great if QLab could have the option for some sort of big clock. A clock that one can set to real time, or time progressed after firing the first cue, or time progressed after firing a certain cue (the cue that starts the show for example - the cues before that are for the people walking in and sitting down in the venue), or time left (a timer set after a certain cue that counts down).
Kind regards,
Wilf
*
Ideally I picture it as a new column to the right of the auto continue /
auto follow option.
Cue 1 2:00.00 (gate 2:00.50)
Cue 2 (4:00.00 (gate 4:00.50)
etc...
& so you can't trigger the next cue before the last one is complete plus
or minus whatever you've set the gate to.
It would be great if by clicking in such box, it automatically set the
gate time to the same time as the cue but could be changed.
Maybe first click sets to length of cue, second click opens a box to click
in to set type.
In the meantime, some of our programmers on the list offered up some
scripts to emulate the task.
I think Rich provided something too but if so, it didn't make it on the wiki.
*
> ________________________________________________________
> WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
> Change your preferences or unsubscribe here:
> http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
> Follow Figure 53 on Twitter here: http://twitter.com/Figure53
>
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Follow Figure 53 on Twitter here: http://twitter.com/Figure53
Charles Coes
www.charlescoes.com
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." - Buckminster Fuller
Rich Walsh
We discussed this at some length back in December 2009, eg: http://lists.figure53.com/pipermail/qlab-figure53.com/2009-December/009042.html. I never developed a fully-tested version of any of my ideas, so that's why they aren't on the wiki. I've attached two workspaces I made at the time in case they're useful.
The problem is coming up with a way that if you do press GO, that GO is completely ignored unless a certain time has passed. This will require disarming the actual GO mechanism itself, as any other cues you may disarm will fire anyway and move the playback position: they just won't do anything else.
You might be able to develop something out of this: give all your MIDI Cues that fire the lighting desk a Post Wait equal to the duration of the lighting cue and have your GO trigger this Script Cue:
tell front workspace
if (count (cues whose running is true and q type is "MIDI")) is 0 then
go
end if
end tell
If that gets a bit unwieldy with larger workspaces (the first line effectively interrogates every cue I think), this might be better:
tell front workspace
set goWorkspace to true
set activeCues to active cues
repeat with eachCue in activeCues
if q type of eachCue is "MIDI" then
set goWorkspace to false
exit repeat
end if
end repeat
if goWorkspace then go
end tell
They both lock out the GO whilst any MIDI Cues are running. They both need proper testing!
I don't like the column idea myself: I'd rather have a "branching and looping cue" type that can do things like "ignore GOs for this cue's duration" and "if condition X is true then move playback position to cue Y" - which would give you a way of solving the challenge in this thread: http://groups.google.com/group/qlab/browse_thread/thread/cfd718896a662dbc.
Sean has recently given us the big clock: http://groups.google.com/group/qlab/browse_thread/thread/8e16225b7c1221. You just need to add MTC Cues to do what you describe. A bit of scripting would sort out setting the MTC start time to current real time if you can't do that automatically - not sure myself:
set start time offset of selectedCue to time of (current date) -- Only accurate to ±1s though, sadly...
Rich
*
Maybe there could be two avenues for doing this sort of thing.
1a "gate cue" - drag it under the cue you want to gate, set the gate time
& no midi or local GO does anything until the gate time runs out.
1b "gate column" - What I don't like about the gate cue concept is that it
doubles the cue number required & clutters up the cue list.
This is why I lean toward the column concept. Where every cue has the
option of having a gate or not. Default is not. If you want it, just click
on the gate (like you do to turn on auto continue / auto follow) & set the
gate time. Done. Simple & easy for things that follow a linear order but
need some fudge factor for overlapping cues.
The gate column could even be something you have to turn on in preferences
or else it doesn't exist.
If that's too difficult, the gate column could simply do nothing when
empty but if you enter a time, it's gated for that amount of time. Then a
way of setting the gate to the length of the cue (maybe shift & click or
something).
2. "branching & looping cue" I trust we need one since you mention it but
if you have to be as script smart as you are to use it, I would need a
simpler option as well. So would most of the students I work with.
*
On Sun, April 3, 2011 12:04 pm, Rich Walsh wrote:
> I don't like the column idea myself: I'd rather have a "branching and
> looping cue" type that can do things like "ignore GOs for this cue's
> duration" and "if condition X is true then move playback position to cue
> Y" - which would give you a way of solving the challenge in this thread:
> http://groups.google.com/group/qlab/browse_thread/thread/cfd718896a662dbc.
Jeremy Lee
Is there a sensible way to make a cue conditional? I would like to fire a specific cue but only when a cue before it has finished playing.