M7CL and QLAB

[kostis Pavlopoulos]

Hello,

Could anyone help me about how am I going to use M7CL to trigger QLab cues via midi while QLab in turn ,effect scene changes or on the M7CL again via midi.

[kostis Pavlopoulos]

Thanks in Advance

[Joey Buddenberg]

Hi Kostis,

If I remember correct the user defined keys can also be set to a midi setting. Set it to some control change. In the workspace settings of qlab you can set control by MIDI.

For scene changes look in the M7CL manual for corresponding MIDI table.

Regards Joey

[Kevin Faulhaber]

Unfortunately, the M7 does not include midi messages as an option for the user defined keys.

You can work around this by mapping an unused control that sends a midi message to one of the user defined keys.

[Kevin Faulhaber]

Unfortunately, the M7 does not include midi messages as an option for the user defined keys.

You can work around this by mapping an unused control that sends a midi message to one of the user defined keys.

Kevin

On May 13, 2013, at 10:05 PM, Joey Buddenberg <joey.bu...@gmail.com> wrote:

[Rusty Wandall]

In order to do this, I often will use the mute masters, or effect bypass buttons as I don't need 8 mute groups and 8 effects sends in my theatrical work.  I usually just go into the midi set up window and set one of the midi control change values as the effect bypass or mute group master.  Then in Qlab, you set the GO to be the corresponding control change value, BUT with a velocity of 128, which ignores whether you are turning the bypass or master on or off.  I've done this solutions for years with great success.  Please contact me if you have any further questions.

Rusty

[Ken White]

I am somewhat late coming up to speed on Qlab 3, so if this question has already been addressed, please be gentle - I searched previous messages and did not find a one on point. Now to the question:

In Qlab 2, in the active que area, there was a progress "dot" that the operator could use to alter the playback position "on the fly" while a que was running. I note in Qlab 3 the progress bar in the active que area, but I do not seem to be able to jump around. How is this functionality achieved in Qlab 3?

Thanks,
Ken White

[Christopher Ashworth]

Hi Ken,

Nice to hear from you. It's indeed true that the progress bar has been removed from the active cues in v3.

Based on your and other feedback, we will be looking at ways to bring this functionality back, although not necessarily in exactly the same form as in v2, as that interface had some distinct disadvantages.

Best,
Chris

[Ken White]

Thanks for your quick response, and I am glad to hear that the functionality's demise may be short lived.

Can I nominate an option click in the progress bar of the active cue list.

> --
> --
> Change your preferences or unsubscribe here:
> http://groups.google.com/group/qlab
>
> Follow Figure 53 on Twitter: http://twitter.com/Figure53
>
> ---
> You received this message because you are subscribed to the Google Groups "QLab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Erin Sullivan]

Has any progress been made on this? IT would be great to have some option to quickly jump to different points in a cue, especially during rehearsals. I work at an educational institution, and the lack of a progress bar has been causing problems. 

Thank you!

[Rich Walsh]

In theory, Figure 53 have quietly added some AppleScript hooks that might help with this… This script is works fine in AppleScript Editor, but refuses to work as a Hotkey:

set userDelta to 10

tell front workspace

repeat with eachCue in (selected as list)

try

if running of eachCue is true then

pause eachCue

set currentTime to action elapsed of eachCue

set desiredTime to currentTime + userDelta

load eachCue time desiredTime

start eachCue

end if

end try

end repeat

end tell

Indeed, simply pausing and starting is being unpredictable for me – and adding any kind of logging to interrogate what exactly is failing makes it even worse. I'm stumped – and I haven't even started on trying to figure out what pre wait elapsed vs action elapsed vs post wait elapsed means yet…

Hmm.

Rich

[Sam Kusnetz]

Rich (and all)

Your script doesn't work for me either as a hotkey, but this script
seems to work:

set userDelta to 10

tell front workspace
repeat with eachCue in (selected as list)

pause eachCue
set currentTime to action elapsed of eachCue
set desiredTime to currentTime + userDelta
load eachCue time desiredTime
start eachCue

end repeat
end tell

Running that script on a running cue will pause it, and then running it
again will jump ahead ten seconds and then un-pause it.

Is that useful to folks?

Cheerio
Sam
--
Sam Kusnetz
QLab Field Operative
s...@figure53.com

[Rich Walsh]

On 18 Nov 2013, at 00:33, Sam Kusnetz <s...@figure53.com> wrote:

Rich (and all)

Your script doesn't work for me either as a hotkey, but this script seems to work:

set userDelta to 10

tell front workspace
   repeat with eachCue in (selected as list)
       pause eachCue
       set currentTime to action elapsed of eachCue
       set desiredTime to currentTime + userDelta
       load eachCue time desiredTime
       start eachCue
   end repeat
end tell

Running that script on a running cue will pause it, and then running it again will jump ahead ten seconds and then un-pause it.

That's not what it should do if the code was working properly though: you shouldn't have to run it twice. What's more, the Hotkey behaviour shouldn't be inconsistent with what happens when you run something in AppleScript Editor.

The events are not being processed in the correct order, as you can see if you run this:

set userDelta to 10

tell front workspace

repeat with eachCue in (selected as list)

if q type of eachCue is not "Script" then

try

if running of eachCue is true then

pause eachCue

set currentTime to action elapsed of eachCue

set desiredTime to currentTime + userDelta

delay 5

load eachCue time desiredTime

delay 5

start eachCue

end if

end try

end if

end repeat

end tell

(All the surrounding code is important, and isn't why the script doesn't work: you need to protect the Script Cue from running on itself (causes stack overflow), and you need a try block as an error will permanently break the cue.)

If you watch what it does you will see that the cue doesn't actually pause until 10s in, at which point the start either fails or has already run – can't tell which.

If this actually worked I would add some lines to also get it to skip paused cues ahead without restarting them.

Even something as innocuous as this reveals that something underlying is fundamentally broken at the moment:

tell front workspace

set selectedCue to last item of (selected as list)

pause selectedCue

delay 5

start selectedCue

end tell

Rich

[Vinny Osborne]

Set mute group on a user key.
Go to midi settings and set mute 8 to send a midi msg.
Open Qlab settings and tell it to listen out for the command. Set the second parameter to ANY to accept a button on or off command.