MIDI control of external devices from Dlive surface

dLive dLive Troubleshooting
1

Hi. Trying to send custom midi commands from Dlive to Qlab to trigger backing tracks and sfx for theater shows. This works fine, using specific midi CC/Note on commands to trigger specific cues in Qlab. The problem is Qlab will randomly trigger other cues on top of the ones that are specified in custom midi. Using a midi sniffer I can tell that there are a lot of midi messages sent from the c3500 surface during rehearsals/shows and I am suspecting that this makes Qlab behave like this, even though it makes no sense, since Qlab and the cues are specifically set to listen to only note on, a specific note and with a specific velocity. I have been searching everywhere online, discussing with other Dlive users I know, and can not seem to find an answer to this. I can switch off sending MIDI all together, which is what I have had to do, and manually hit GO both on the surface and in Qlab. If I understand correctly there used to be a way to filter out what MIDI messages are sent from the console, but these options have disappeared in later FW versions? Is there still a way to shut off the horrific unusable spewing out of midi messages from every fader, encoder and parameter on the surface, to only let the custom midi messages from scene recalls out on the ethernet connection? I cant for the life of me find out how to separate out the custom midi commands to a midi channel that is not used for anything else, unless we can do this by inserting it into the HEX string itself, which is not detailed in the “TCP/IP MIDI document” (That only covers what you can control on the surface from external controllers as far as I can tell. Not the other way around)

I know there are a million ways to solve this, and to make Qlab trigger scenes on the Dlive and so on and back and forth, but that is not gonna work for us. We simply need to trigger cues in Qlab when we hit GO on the surface, without having anything else happen except that exact cue. (Using the same GO msg for every scene is also out of the question, as this could potentially trigger the wrong cue, again…)

Hope someone can help me here.

C3500 + CDM48, Qlab on Macbook Pro running MIDI Control app in “MIDI Through” mode, single IP connection between Mac and the surface. No other devices on the network.

We will send i.e “90,0A,01” for cue no1, “90,0A,02” for cue no2 etc. This works until you touch a fader or encoder, and stuff goes nuts. Or, triggering one scene will simply start 3 cues at the same time, simply by pressing GO (On a scene with a custom MIDI string). And its totally random, no system to it, so its different cues every time it happens.

If this ends up being a Qlab issue, i apologize in advance… I have thought about using OSC for this, to try to eliminate MIDI alltogether, but I did not have the time to redo all 300 cues for that before the premiere this weekend.

2

I guess you go directly via LAN into the QLab PC?

You could use a MIDI interface with a LAN port and filter out any messages, except the ones you need.

No way to filter out incoming messages in QLab? Have no experience with QLab at all.

What MIDI channel are you using in QLab?

Could you use Program Changes for QLab scenes? Every dLive scene sends a specific Program Change. Like that no CC/Note can screw up something.

Maybe a MIDI loop is causing stuff? Is MIDI receive enabled on the dLive? Is QLab sending stuff?

3

Thanks for replying. All good questions!

  • Dlive and macbook are connected directly via LAN, one 5 port switch but these are the only two devices connected
  • MIDI recieve on Dlive is OFF, Qlab is set to recieve only
  • Using ch.1 in Qlab, tested this - the only channel Qlab recieves anything on. It is at least not set to «Any»
  • You can set filters in Qlab, and you can use different MIDI messages to achieve what you want. So far I have not found anything that will block things in a way that does not also block what I really want to go through

I ended up disconnecting and running the shows manually by pushing GO both on the Dlive and the mac.

Edit: I guess the Bome box is a neat solution to filter out stuff, unfortunately I didnt have time to get one, but will look into that for sure.

Program change: As far as I understand that would be to trigger specific scenes in Dlive from Qlab? If I set Qlab to «listen mode» to pick up what is sent from Dlive on recall of a specific scene, it would still pick up the GO button or anything else active on the surface at that point.

A feature request from me would be a button to activate deactivate all midi sent from Dlive -except- if a custom midi hex string is put in the scene, and then only that string would be sent.

4

I have a “QLab GO” softkey programmed on my dLive, and have occasionally triggered specific cues from scenes as well. We also trigger QLab from lights (via a DMX-to-MIDI converter), and from switches built into sets (via a contact-closure-to-MIDI interface). Here are some thoughts:

The dLive uses five MIDI channels for its native MIDI messages (12-16 by default) plus potentially some other channels for UFX control. View/change these at Utility->Control->MIDI. Avoid using the dLive channels for custom MIDI to QLab and you should not have conflicts.

I am relatively new to QLab but as far as i can tell, it listens to all MIDI interfaces connected to the computer. It does not seem to have a patch concept for MIDI triggers like it does for audio and for MIDI outputs. If you have other MIDI devices connected to the computer running QLab you have to be careful about what messages those devices send. I choose a unique MIDI channel for each trigger source to help avoid conflicts.

5

How do you choose the channel? I have tried to change channels in the Utility-Control-MIDI page, but if I change that, Qlab recieves nothing unless I specify for Qlab to listen to the first channel in the group I can set it to. Unless there is something hidden on that menu page that I dont know about? I.e I can set it to «1-5», and have Qlab listen to ch 16, but Qlab wont recieve anything if I do that in my testing.

It is possible that I am missing something in the custom MIDI strings themselves, like if it is possible to define the channel in the string itself.

Thanks fo the input, I will try to set up a test using Director and a MIDI sniffer.

6

Recommended reading:

And the Allen and Heath Document “dLive-MIDI-Over-TCP-Protocol-V2.0”

My recommendation on MIDI channels is to use the default dLive settings (MIDI channels 12-16).

If you just need to trigger QLab with scene recall, then you can use the native dLive messages. The messages you are looking for depend on whether the A&H MIDI control driver on the Mac is connecting to the Mix Rack component or the Surface component:

The Mix Rack sends Program Change messages that are fixed to the scene number (1-500). Since Program Change messages can only specify 1-128, the dLive also sends a Bank Message with Bank=1 for scenes 1-128, etc. QLab can only listen for one type of message, so you will need to tell QLab to listen for the Program Change. Then Scene 1 will send the same Program Change value as Scene 129, etc. In many cases this will not be an issue.

The Surface behaves similarly, except that you can specify the recall ID for a cue list entry, and you can choose an ID for each scene. That is more flexible.

7

Re-reading your original post I am remembering that you want to use Custom MIDI to trigger QLab, not necessarily the native dLive messages.

In that case, note that dLive uses Note Messages for mutes, and CC Messages for lots of things. But, dLive will only send these on the specified channels. If you use the default 12-16 for dLive, then it will not send any message on, say, MIDI channel 1. Then if you choose MIDI channel 1 for your custom messages then you should not have conflicts.

For example, if you want a specific scene to send a Custom MIDI message, and the message you want to send is (Channel 1, Note On, Note #1, Velocity 127) then your Custom MIDI would be:

90 00 7F

The 9 in 90 is “Note On”; the 0 in 90 is “Channel 1”; the 00 is Note #1; the 7F is 127.

8

Yes, what you say here has been my assumptions all along. Thank you for verifying that this should be the case. I tested that exact scenario just using director and MIDIviewer last night, and it clearly shows that the custom command arrives on ch 1 and the PC messages from the GO-button arrives on ch 12.

I will have to test again on the actual surface and with Qlab to see if I can reproduce it.