GLD MIDI Trigger Cues

[Christian Ekren]

Hello,

I am trying to set up cues to be triggered from my Allen and Heath GLD-112 with scene recalls. Every time a scene is recalled on the GLD system, it sends out a midi command with the following:

Scene SS 1 to 128 = 00 to 7F (refer to table)

Select bank     Recall Scene

BN, 00, 00,     CN, SS

Where each scene sends a Program Change message 0 to 128, with several banks of to differentiate between the 500 scenes the board can have (i.e. Bank 0 = Scenes 1 through 128, Bank 1 = 129 through 256, etc.)

The problem I have is that Qlab only recognizes the Program Change value, which means that both Scene 1 and Scene 129 (and Scene 257, etc.) are all seen as the same trigger by Qlab, and thus will cause the cue to fire. Is there any way to have Qlab differentiate between banks of scenes? For reference, here is a link to the GLD's MIDI protocol:

http://www.allen-heath.com/media/GLD-MIDI-and-TCPIP-Protocol-V1.4_2.pdf

Thanks!

- Christian

[Rich Walsh]

QLab accepts a single MIDI message as a trigger: bank select followed by program change is 2 messages. It will be fiddly to parse that.

You could probably use Midipipe to map the double messages from your desk to single messages in QLab, eg: map bank to note number and program to velocity.

Failing that you might be able to do something whereby a script (or OSC message with clever wildcard) is triggered by the bank message and disarms the MIDI triggers for all the cues that are not in that bank. So, CC00 @ 1 runs a script which enables MIDI triggering for QLab cues 129 thru 256, and disables it for all others. It’d have to be fast though, so the PC value that immediately follows is handled correctly.

I don’t think there’s an OSC method for MIDI trigger, so you’d need to use targeted Start Cues and arm/disarm them en masse. I can fill in the gaps later if you need.

Rich

--
Contact support anytime: sup...@figure53.com
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/e167043f-d206-4561-a889-976862439e19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Ekren]

Thanks for the reply! Would the Scene recall message structure be two independent Program Change messages? Or how would I go about parsing through Midipipe - I've not used the tool before, but I've been messing with it for a few minutes now and it appears I'd want to use a chain with something like the following?

MIDI IN (A&H MIDI) -> Message Factory (Program Change trigger, ??? message)-> MIDI OUT (Qlab)

I'm not seeing a note number or velocity option in the "message" tab of Message Factory.

Or would just using message converter work for Program Change to Note On, twice?

I'm sure that probably doesn't make any sense.

If this is something Midipipe can take care of I'd love to just use that, but if not I've not used Arm/Disarm cues before, would you be able to elaborate on the process of using OSC or Applescript to parse and trigger?

[Rich Walsh]

I can’t see a way of combining data from two MIDI messages into one within Midipipe – only converting / filtering / processing them one at a time; so I guess that was a red herring. I was hoping you’d be able to take the second data byte from the CC00 message and combine it with the data byte from the PC message to make a new Note On message with its note number be the bank and its velocity be the program change.

Attached uses Start Cues to fire your “cue” (15 Wait Cues in this case). They are triggered by Program Change. OSC Cues – triggered by CC00 – arm the Start Cues for the correct bank and disarm those for the other banks. The 3 cues at the top of the Main Cue List demonstrate how CC00/PC combinations can fire specific cues, based on the combination of the two.

Frankly though I think you’d be better off having QLab fire the desk.

Rich

[Christian Ekren]

I see. Thank you for the sample show file! You're not kidding - that's a pretty involved setup. I think you're right - cueing the console from Qlab seems to be the better option...

[Steve Devino]

Just food for thought, But I usually only send a Go Trigger to QLAB from the board then have QLAB send the Program Change message back to the board.   This puts all the scene and SFX queue editing in QLAB and lets the operator use a user defined key for GO on the board. 

[Andy Lang]

On Fri, Feb 17, 2017 at 12:55 PM Steve Devino <sde...@gmail.com> wrote:

Just food for thought, But I usually only send a Go Trigger to QLAB from the board then have QLAB send the Program Change message back to the board.   This puts all the scene and SFX queue editing in QLAB and lets the operator use a user defined key for GO on the board. 

That's definitely a viable, and sometimes simpler, approach. I've done both, at different times. There are a few reasons some mixers prefer to have the console scene trigger QLab, rather than vice versa:

1) There are usually on a musical more console scenes than QLab scenes, so it's simply less programming to do.  

2) Some mixers find it faster to navigate scenes in the console than have to reach for the mouse and navigate the cue list in QLab when jumping around in rehearsal. This way, no matter where you are in the console, you always are automatically triggering the right cues in QLab. This matters less during the run of the show, but can be a nice efficiency thing in rehearsals/production. Where the difference really shows up is when repeating a sequence a number of times in a row in rehearsal. You can just back the console up those few scenes, and when you hit the point that QLab needs to be triggered again, it triggers. No need to navigate the QLab cue list to move the playhead. 

It's one set of small tradeoffs for another, and it may be that, in the case of this particular console, having QLab be the one driving all recalls is a lot simpler. 

-Andy

--

Andy Lang

[@SoundGuyAndy](http://twitter.com/SoundGuyAndy)

sup...@figure53.com