[QLab] script that blocks cue execution

[Michele Cremaschi]

Hi folks,

who's able to write a script that does this:

- if the cue that's running is not armed, just stop execution, reload it, fire it.

My aim is to put this as first step of every cue. Cues are disarmed by default. And they are armed by the previous cue, just from the moment they can really run. This would cancel the possibility that a cue run when it's not yet its time to run, for the technician error. 

I know that if the technician run an unarmed cue, he can still stop it and manually reload, and fire it again. But, with my script idea. this would be done automatically. If this works, i could even command QLab via a WII remote from the stage - i can't see the screen, but i can be sure that if i press errouneusly the "go" button on WII remote, cue doesn't start. 

Do you think could be a good idea?

bye

mic

[Rich Walsh]

On 9 Nov 2009, at 15:43, Michele Cremaschi wrote:

> Hi folks,
>
> who's able to write a script that does this:
> - if the cue that's running is not armed, just stop execution,
> reload it, fire it.

If a cue isn't armed it doesn't run, so it won't need to be stopped.
This will check the previous cue, and if it isn't armed, arm it & fire
it:

tell front workspace
set playPosition to playback position of current cue list
set previousCue to cue before playPosition
if armed of previousCue is false then
set armed of previousCue to true
load previousCue
start previousCue
end if
end tell

Is this what you meant? I'm not quite sure how you would integrate
that...

Rich
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

[Michele Cremaschi]

Hi Rich,

thanks but it's not exactly what i meant.

I attach an image to explain better.

As you can see, all my cues are organized in cues (i didn't mention that, my fault).

Cue group one is running. It will arm cue group due with cue 1.2

What i want is that, if cue 2 is fired now, script 3 check that the group it is inside is not armed, stop group cue 2 from running, reload it and put playback position again to 2.

I realize now that being script cue not armed, it is impossibile it can run and check what i did.... so, we need another solution to do what i meant... ideas?

[*]

Chris,

Just thinking out loud here but consider this...

Qlab users already have the ability to set a lockout time of X in
perferences to avoid double triggering. Taking that concept one step
further,

is it possible to make an actual "disable cue" cue type that can be
dragged above a cue that would basically default to the length of the
previous cue but be adjustable. A disarm with wait...

For example

Cue 1 (5:00 long)
disable cue 2 (for 5:00 by default or able to adjust the wait time)
Cue 2 (2:00 long)
disable cue 3 (for 2:00)
etc...

I realize that in complex cue-ing situations, this might open up a can of
worms but in a cue list where Qlab is used more like a glorified CD
player,
it would make sure that only one cue can be running at a time outside of
the small window when a cue trigger is accepted.

I've had a operator accidentally lean on the space bar & fire off a second
cue. Best solution is to NOT lean on the space bar but shy of that...

Obviously not a useful tool for every one or every situation but maybe
useful for those of us who basically play cues in order that may or may
not overlap a bit.

Ignore if you like.

*

[Christopher Ashworth]

You could use a Goto Cue and a Target Cue to achieve the same effect.

The idea would be that the Goto Cue would loop back on itself until a
Target Cue changed it. Therefore there would be a period of time
where pressing GO would do nothing (not even advance the playback
position). After that time pressing GO would fire the next cue.

Best,
Chris

[Luka Mustafa]

Hello,

I think this would be a nice option, to disarm the go command for the
next cue.

I have just completed my first bigger show with QLab and am now
training the operator, I was thinking about disarming all the cues or
cue groups in the workspace.

My idea is to have such a configuration:

Audio cue 1(or a group cue) running
Arm cue - 2seconds (or x seconds) before the end of above cue arm the
next cue
Audio cue 2 (or a group cue)

My idea would be to add an option like: auto arm five seconds before
previous cue ends or auto arm before the "target" cue ends.

Best regards,

Luka Mustafa
so...@druga.org

[*]

I'm forced to revisit this whole concept again.

Tonight (while I wasn't at the theater anymore) & during the show, my
operator triggered an audio cue as called. Since he's in a booth but there
are no booth speakers we have been using my Galaxy Hotspot for that
purpose (which is not ideal).

Apparently he couldn't hear the cue playing so he thought he must had
pressed the wrong button on the JLCooper MSC transport (most of them do
nothing) & so he pushed the GO button again. (bad choice on his part but
proactive!!!)

Of course you can already guess, the first cue WAS playing (it's the
softest cue in the show) but now the next cue was playing on top of it. He
ended up fading it out & having to restart the dance piece in front of
2000 people on a Friday night.

This is the EXACT situation where an easy to add (one cue at a time
button) would be very handy.

As it has been explained, there are various ways / script options to do
something like this but nothing is a simple as making it where one can
click on something that makes all cues have to wait until the previous cue
is almost complete. Autofollows could be ignored.

Sure we I can blame the operator but he's been doing it for a week now
without a single cueing mistake. Proof that it happens to the best of us.

I doubt it will ever happen again to him but for the moment, I think I'll
make it where the GO is locked out for the shortest cue time. About 1
minute.

If somewhere in the preferences options of a future version of Q2, there
was a button to click on (itchy finger op mode) that would keep the next
cue from working until the previous cue was 96 percent complete, I think a
certain faction of QLab users would be better off for it:)

Ultimately it should be wicked simple to add to a cue list globally
without actually adding anything to the cue list. Just like the current
BLOCK second GO for X number of seconds but smarter. Workspace
Preferences, SMART GO BLOCK, done.

Thoughts?

*

[Stephen Pruitt]

I have to agree here... The solution to a problem, even though this
is a mailing list about Qlab, is not always a new feature. Sometimes
it's simply using what is already there correctly.

In my mind, the first solution in this case is that the booth needs a
monitoring system that allows the operator to hear the results of what
they are doing. To not be able to listen for trouble, seems to me, to
be asking for it. Short of that, the operator needs to be familiar
enough with the show, and with Qlab, to trust what they are seeing on
the screen. Not only did this operator not realize that the cue that
was running was a very quiet one, but they apparently were not
familiar enough with the program to look at the monitor and see what
was happening, or to go back up and try to stop and restart the proper
cue, instead of running the next one on the list.

We've all run into these situations... there usually isn't enough time
to familiarize an operator with Qlab if they've never seen it before.
In that case, we hope for the best, but deal with the problems when
they arise. I'm with sk... not trying to be snarky... just objective.

Stephen

> Tonight (while I wasn't at the theater anymore) & during the show, my
> operator triggered an audio cue as called. Since he's in a booth but
> there
> are no booth speakers we have been using my Galaxy Hotspot for that
> purpose (which is not ideal).
>
> Apparently he couldn't hear the cue playing so he thought he must had
> pressed the wrong button on the JLCooper MSC transport (most of them
> do
> nothing) & so he pushed the GO button again. (bad choice on his part
> but
> proactive!!!)

i'm not trying to be snarky here, but shouldn't your operator have
looked at the screen to see if the cue was playing? qlab gives a bunch
of good visual feedback, such as the play indicators on the left side
of the cue list, the active cues display, and perhaps most important
the "on deck" indicator, which should have showed that qlab was
standing by for the next cue.

i am quite in favor of discussing this, and any other scenario, to see
if we as a community can come up with good solutions to frequent
problems. but in this particular case, it seems to me that the problem
was the operator not making use of available information.

i am also very much in favor of limiting feature bloat, and there have
been several elegant cueing solutions to the lockout-while-a-cue-is-
playing question. so i guess i'm not sure what your proposed feature
does except duplicate a functionality that is already available for
the purpose of covering for an operator who isn't paying close enough
attention.

again, not trying to be a smart-ass.

sk

[*]

But note that I'm not the one who first asked for something like this.
Instead someone else did & then I had a perfect example of where it would
be useful.

This means that there are at least 2 people who see the value of a feature
that isn't a easy to implement feature.

In using the existing programming options, how do I implement it but make
it not fight me in rehearsals (where we jump around)?

How to do I finish the final dress rehearsal without having to add,
delete, change a huge amount of stuff after the fact, knowing that I will
not see the operator use the new cue list until an audience in in their
seats?

As it is, I test the cue list myself every time I change something
relevant. Picture the op walking in & there are 45 new cues he can just
ignore in the cue list. Some are fine with this kind of last minute stuff
& others start looking for the CD player the want to be using.

I'm going to learn how to do what I want with existing features but stand
by the fact that any user who is running qlab like a CD player with an
inexperience op at the helm would benefit from a smart double go protector
box.

How to make the operator more experienced is another matter. Again, how do
I tell them everything not to do? Easier just to say..."HIT GO when the SM
calls for it." & not have explain the grey zone.

The true solution to this whole issue is for my company to pay me to be
the op & let the IA house sound guy sit & check his email. The roles are
reversed at the moment:)

*

On Fri, December 4, 2009 3:38 pm, Stephen Pruitt wrote:
> I have to agree here... The solution to a problem, even though this
> is a mailing list about Qlab, is not always a new feature. Sometimes
> it's simply using what is already there correctly.

[Lorenzo Baronchelli]

here the cue list file, I have problems in attaching it.

https://dl.dropbox.com/u/279362/GO%20disabilitato.cues

Il giorno martedì 1 gennaio 2013 18:21:05 UTC+1, Lorenzo Baronchelli ha scritto:

hi,

maybe I have found an easy solution to this problem with only 3 cues, please give a look to the cue list attached and let me know if it does work for you. be careful, not tested yet in a live show! by the way, happy new year!

lorenzo

[Rasmus Kreiner]

Hi Lorennzo,

Try to look at this. It's not tested during show, so test it before use in a show environment.

It's basically a applescript the freezes everything until it is released also, unfortunately, cues that is operated after this. I've made two scenarios for you to take a look at. 

Hope this helps.

Best,

Rasmus

[Rich Walsh]

I've fiddled with this on and off since the original thread 3 years ago. v4 might work. I've just created v5, which requires _no scripting at all_!

Never actually needed to do this on a show though…

Rich

[ra byn taylor]

Thanks Rich!

I use Qlab for two types of shows (in general).

A workspace where I am always playing one cue at a time for dance type stuff & then the more typical workspace of complicated overlapping cues for live theater.

Most sound designers don't see the "CD player" type gigs because most times they wouldn't be needed. I would guess that high end sound designers will never need the "CD player" mode. It's the elementary teacher, middle school teacher, high school teacher, local theater, local dance company, professional dance company, etc... that will benefit from this sort of thing.
 
Best regards,

ra byn (robin)