[QLab] Device Mute/Unmute

[DANIEL L BARSKY]

Hello!

I have built an external control box for a project, which ultimately sends midi messages to Qlab. I have a show audio on/off switch, which I'd like to use to mute/unmute all of the show's audio. Group cues aren't cutting it, and I'm wondering if I can control the device (motu 828mk3) in the "edit device" section directly ...possibly via script?... *If I had a digital console, I'd trigger a mute group -Unfortunately, I do not.

Any suggestions welcome -THANKS!

Daniel

________________________________________________________
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

[Christopher Ashworth]

Hi Daniel,

The global device settings can't be adjusted programmatically, only manually.

The best bet may be to try to fade out a group (or a whole cue list), as a mute. If you need to then unmute it, be sure NOT to bring the volume down all the way to -INF, as it will not be possible to bring the volume back up again to 0 db without stopping and restarting the cues.

-C

On May 21, 2011, at 12:05 AM, DANIEL L BARSKY wrote:
>
> I have built an external control box for a project, which ultimately sends midi messages to Qlab. I have a show audio on/off switch, which I'd like to use to mute/unmute all of the show's audio. Group cues aren't cutting it, and I'm wondering if I can control the device (motu 828mk3) in the "edit device" section directly ...possibly via script?... *If I had a digital console, I'd trigger a mute group -Unfortunately, I do not.
>
> Any suggestions welcome -THANKS!

________________________________________________________

[DANIEL L BARSKY]

The best bet may be to try to fade out a group (or a whole cue list), as a mute.

That is exactly what I tried. However, it is only affecting cues which have already triggered. Newly triggered cues don't seem to care, and start at their regular level -Therefore, if I then "unmute," I drastically raise the volume of newly triggered cues. Yikes! This is why I was hoping for some AppleScript that could change the device level in workspace preferences...

Any other thoughts? -Thank you Chris

Daniel

[Eric Lott]

Not quite a Mute/Unmute but seems to have a similar effect. Trying building second cue list with a just a disarm and arm cues targeting your main cue list. I would put those on a couple of hot keys or depending on your external control box maybe on one of it. If you are already using multiple cue list just do a group cue with multiple arm or disarm cues.

Eric Lott

[Rich Walsh]

You could get into some seriously scary (and potentially unreliable) UI scripting along the lines of this: http://wiki.figure53.com/QLab+Scripts+and+Macros#x-General%20tips-UI%20element%20scripting... (See below.)

Isn't there anything clever you can do using the MOTU's CueMix (?) software? I don't use their interfaces myself but I believe they are HUI-controllable, so maybe there's a MIDI command you can send the unit that mutes everything?

Alternatively, building on something that came up around the time we discussed globally disarming MSC (http://lists.figure53.com/htdig.cgi/qlab-figure53.com/2010-August/011647.html - although I can't find the actual post I'm thinking of to attribute credit properly), use a Script Cue to repatch all the cues to an output that isn't connected to anything:

set userThisCueMutes to true -- Change this to "false" for your unmute cue
set userUnmuteOutputPatch to 1 -- Pick your normal device
set userMuteOutputPatch to 2 -- Pick an unassigned output

-- Declarations

set mutableTypes to {"Audio", "Video"} -- These are the only cue types that can output audio

-- Mute or unmute every cue

tell front workspace
repeat with eachType in mutableTypes
repeat with eachCue in (cues whose q type is eachType)
if userThisCueMutes is false then
set patch of eachCue to userUnmuteOutputPatch
else
set patch of eachCue to userMuteOutputPatch
end if
end repeat
end repeat
end tell

Modify the first line and this will do both mute and unmute. The only problem is, it does of course break all your cues so it doesn't really do much more than hitting "ESC". Even if you connect your mute output patch to some silent output (like Soundflower) all the running cues will stop.

Hmm, tricky. There's a lot to be said for using a mixing desk (I won't leave home without one, as it were).

Rich

--

A note about QLab and UI scripting...

You'd think this might work:

set userThisCueMutes to true -- Change this to "false" for your unmute cue
set userDeviceMasterMuteLevel to "-120" -- Set the level for mute
set userDeviceMasterUnmuteLevel to "0" -- Set the normal level

tell application "System Events"
if UI elements enabled then
-- Without the "ignoring" command, the script won't run in QLab
-- as the Script Cue locks up the application and prevents QLab responding.
ignoring application responses
tell application "QLab"
activate
end tell
keystroke "," using {command down}
delay 1 -- Let the Preferences window open
tell application process "QLab"
tell front window
set selected of row 5 of table 1 of scroll area 1 to true
click button 1 of group "Audio Device Assignment" of group 1
end tell
end tell
delay 1 -- Let the Edit Device window open
if userThisCueMutes is true then
repeat with eachCharacter in userDeviceMasterMuteLevel
keystroke eachCharacter
end repeat
else
repeat with eachCharacter in userDeviceMasterUnmuteLevel
keystroke eachCharacter
end repeat
end if
keystroke return
delay 1 -- This gives you a chance to see what happened
keystroke "w" using {command down}
keystroke "," using {command down}
end ignoring
else
tell application "System Preferences"
activate
set current pane to pane "com.apple.preference.universalaccess"
display dialog "UI element scripting is not enabled. Check \"Enable access for assistive devices\"."
end tell
end if
end tell

And it does, from within AppleScript Editor. It absolutely _refuses_ to work from within QLab, even if saved as an application and told to run. Somehow, when QLab becomes the parent of the scripting the keystrokes arrive in the wrong order. I've run into this before and given up...

Now, you can bodge it even further by having QLab ask AppleScript Editor to run the script - save the script on your desktop and use this Script Cue:

ignoring application responses
tell application "AppleScript Editor"
open POSIX path of (path to desktop folder) & "Mute.scpt"
execute document "Mute"
end tell
end ignoring

That works, but if you then try to get it to quit AppleScript Editor it all breaks down again!

Scary and potentially unreliable.

[Rich Walsh]

On 21 May 2011, at 18:13, Eric Lott wrote:

> Not quite a Mute/Unmute but seems to have a similar effect. Trying building second cue list with a just a disarm and arm cues targeting your main cue list. I would put those on a couple of hot keys or depending on your external control box maybe on one of it. If you are already using multiple cue list just do a group cue with multiple arm or disarm cues.

Disarming a running cue does not mute it (for me)... Also, disarming the cue list will stop it advancing with each GO I think.

Rich

[DANIEL L BARSKY]

Eric, I have the same results are Rich suggested regarding your arm/disarm method.

Rich, I'll have to try your suggestions when I have more time (later in the weekend), but thank you for the ideas to try.

Daniel

[Morgan Calma]

> Isn't there anything clever you can do using the MOTU's CueMix (?)
> software? I don't use their interfaces myself but I believe they are HUI-
> controllable, so maybe there's a MIDI command you can send the unit that
> mutes everything?

The mutes are controllable by midi though HUI. I use a BCF2000 to control cuemix. It's not great but it works. I have not tried sending midi to the BCF2000 or cuemix directly from QLab. From what I have played with so fare cuemix must see a compatible HUI or it ignores it all midi. I will play with it and see.

[DANIEL L BARSKY]

Solution!

After playing with Applescript, Automator, and Cuemix FX, I created a simple Max/Msp patch...

Qlab sends its audio to Soundflower. Inside Max, it passes through some midi-controlled gain sliders, and then is output to the Motu828. Aside from some easy to fix (and no-longer reoccurring) word-clock issues, everything is working like a charm. Thanks to all who suggested various solutions to my (no-longer!) problem.

Daniel