Search Results for 'qu midi protocol'

[AndreasModerator]

If you need more control, you’re free to not use the HUI/MackieControl emulation but communicate with the Qu directly (using MIDI protocol). The HUI/MackieControl protocol is a very limited standard and only allows to control faders and pan. And since we do not have a Pan per channel but only a pan in channel strip, we can’t even use pan with that emulation.
Sorry, there is nothing A&H can do to circumvent these limits through “DAW Control”.

[Anonymous]

I had a lot of problems as well trying to get my new qu32 setup for DAW control.

The main thing is that you need to set the following:

Protocol Input Port | Output Port
——————————————
MackieControl – DAWControl1, DAWControl1
MackieExtender – DAWControl2, DAWControl2

etc… for how many fader groups of 8 you have.
—————————————–

The “QU” labeled Midi port is the “n”, the DAW control is the “+1”.
So in default the standard MIDI control is channel 1, where channel 2 is the DAW control.

If the Ports come up Offline, usually this is because they have been active in a DAW, the DAW is closed and they haven’t released.
Exiting the A&H DAW application and restarting, seems to remedy this.

Now if more Mackie Implementation was done, like Pan, and a bunch of other soft key programming…this limited control was a little disappointing.

Hope this helps others setup, where I had a difficult time.
A&H should take this as feedback and update their DAW manual for more clear and precise setup.

-sephult

[AndreasModerator]

Glad you got it get working!
Just realized that I did a mistake with channel numbers, they’re actually starting at 32 resp. 20h. I’ll correct that in my post above. To address channel 7 message must B0h 63h 27h not B0h 63h 07h.
You’re totally right that the native MIDI implementation is way more powerful that the HUI emulation offered in the DAW driver. This is ok for DAWs which can’t be configured but obviously is limited to the possibilities of the HUI protocol.
For the reasonable request to let the Qu selection follow the DAW the Qu MIDI implementation actually misses some “Select physical Channel” command which could be send from the DAW. Maybe PAFL Select could be used for that porpose.

[AndreasModerator]

Maybe some more explanations, but I’m not in reach of my desk so I can’t test.
As you already know there are four MIDI events to be sent to control a fader. Each such an event is constructed from three bytes containing data.
The first byte contains the so called MIDI Status Byte, defining the meaning and number of the following bytes. The Status Byte itself contains two informations. The upper four bits define the command type (like Note ON, Note OFF or, in this case, Continuous Controller or CC) and the lower four bits specify the MIDI Channel on which both partners commununicate. There are 16 MIDI channels available so 16 Devices could communicate through the same physical MIDI cable (well, we’re on USB, slightly different but the protocol still has this information). The MIDI channel is encoded in the bottom four Bits. This is the N of BN. The B specifies a CC message and encoded in the high four bits of the first byte. So valid values will be in hex B0h … BFh or 176..191 in decimal. I’ll denote hex numbers with a lowercase h. So 176 actually means B0h, a CC message on MIDI Channel 0. Should be OK.
The second byte of CC events specify which “controller” should be controlled. Regular MIDI controllers are Volume (7) or Hold pedal (64 resp. 40h). There are also some special “controllers” which effectively extend the range of possible 127 controllers to some 16.000, this is done using Registered and Non-Registered Parameter Numbers or RPN resp. NRPN. To address such an “extended” parameter two CC messages need to be sent first, the 99 and 98 (63h and 62h) CC messages. The meaning of this NRPN numbers are totally vendor specific, the Qu uses the coarse number (63h resp. 99) to specify a channel and the fine number (62h resp. 98) as a Parameter ID of that channel. Parameter ID can be a Fader (17h resp. 23), Pan (16h resp. 22) or PEQ ON/OFF (11h resp. 17) etc.
There is a table at the end of the Qu Mixer MIDI Protocol Document for these parameter numbers, physical channels, for example, start at 32 (or 20h).

So:
176 99 1 -> B0h 63h 01h
176 98 17 -> B0h 62h 11h
would control PEQ ON/OFF on FX Send 2, to address the fader you probably want to use:
176 99 32 -> B0h 63h 20h
176 98 23 -> B0h 62h 17h

After sending the NRPN address (Fader on Channel 1 in this case), the new value needs to be send using another special CC, the Data Coarse CC 6:
176 6 0 -> B0h 06h 00h : OFF
or
176 6 107 -> B0h 06h 6Bh : 0dB
looks OK.

The last Event, which uses the Data Fine CC (38 resp. 26h), does not send the lower bits of that parameter, but specifies some sort of sub-target for that parameter. In case of a fader this will control whether you’re addressing the LR fader or send to a mix for example. This is named the VX value in the spec. To address the LR fader, you need to send a 07h:
176 38 7 -> B0h 26h 07h

To control the Send to a particular mix you’ll need to use ID 20h (or 32 decimal) and specify the target as the VX parameter. So, controlling Channel 7 on Mix 4 should be something like:
176 99 38 -> B0h 63h 26h: CH=38/26h, Channel 7
176 98 32 -> B0h 62h 20h: ID=20h, Addressing SEND
176 6 107 -> B0h 06h 6Bh: Value=6Bh, 0dB
176 38 3 -> B0h 26h 04h: VX=3, Mix 4

Hope this helps to clarify things.

Edit: Fixed Channel Numbering

[Nicola A&HKeymaster]

Hi,

Qu uses CC messages for the MIDI strips. Most other faders and parameters use NRPN messages. Again, the protocol is your guide.
To change Scenes you normally use Program Change messages, not CC, and yes, Qu accepts Program Change messages.

[Lumu12Participant]

Thanks for the link! The only thing I’m afraid of, is whether the midi-protocol used by the Qu16 (appears to be NRPN) accepts regular CC-midi-messages, from older devices like an MPC 2000. is it possible to set the qu16 up for receiving midi-CC?

[AndreasModerator]

Just check out the Qu Mixer MIDI Protocol and search for “Scene Recall”.

[AndreasModerator]

At least QuDrive control is not documented in the current Qu Mixer MIDI Protocol documentation. I’d suggest to add a feature request, since this already works for the Apps, which use a different control channel.

Hey folks,

My name is Dwight and I own Good Sounds. We are an AVL integrator just outside of Pittsbugh and an Allen and Heath dealer. We also do a tremendous amount of theatrical sound production. One program we use extensively is called Palladium and it allows us to build and run a theatrical production with a cue based system. I just recently picked up a QU32 for our inventory and am familiar with its operation. We use several other consoles for our shows as well but they operate with Palladium over OSC protocol. However, I am not a MIDI programmer and that is what the QU32 uses to talk with Palladium.

One thing we do is program the sound FX to be cued with Palladium on the board’s USB player. My question is: can the QU-Drive transport keys be controlled with MIDI commands? I am able to run a show on the QU32 and control mutes, faders, EQ and most other functions that are necessary. But I haven’t figured out if the QU-Drive can be controlled.

Any assistance with this issue would be greatly appreciated.

Greetings list!

I have tried unsuccessfully to get the A&H TCP MIDI Driver to connect to the QU-32. It’s difficult to find any documentation on this little app, and it is also only in its 1.0.0. version.

Has anyone been successful with using this driver? I try to connect but it never confirms a connection — just hangs on “connecting…”

Following this, I made various attempts to connect to the mixer using the documented sysex messages using python or node.js, and ran various packet sniffers in the terminal & processing in case I could catch any transmitted data, yet there is no indication of a response from the mixer.

Here’s what I tried:

I wrote basic TCP client scripts in Python and node.js. I confirmed that these work, using the localhost, then edited them to use the mixer’s IP address and Port (192.168.1.60 and 51325). I ran many versions of these from the command line. For the most part, the hex I’m attempting to send is the “Get System State” message on page 9 of the QU-MIDI-Protocol document

https://www.allen-heath.com/media/Qu-MIDI-Protocol-V1.82.pdf

Each time, the client timed out.

I’ve attempted each change in code by running on different machines — Mac Pro, Mac Mini (El Capitan), and MacBook Pro (Yosemite) — and using the wireless router connected to the network and also by going straight from the mixer’s “network” port to the computers’ ethernet port.

I’m also wondering if it has anything to do with the “Active Sensing” byte as mentioned on page 9 — HUI protocol has a similar message, a ping sent to the DAW and back. I’ve sent the sysex message (start, header, active sensing byte, end byte) to no avail.

Any suggestions or thoughts addressing this would be very helpful. Thanks!

[AndreasModerator]

All required information should be found in Qu Mixer MIDI Protocol document.

[AndreasModerator]

If you don’t want to hear that the Qu uses NRPN to control most functions, you probably won’t get an answer at all… 😉
Since you obviously connect your Qu to some PC/Mac, there’s Bome’s MIDI Translater which should be able to translate between Qu protocol and whatever is needed from your controller.

[AndreasModerator]

RTA readings any many remote control functions are available using the Qu Mixer MIDI Protocol – Firmware V1.82+.
RTA numbers (and GEQ) are way too coarse to properly identify problematic frequencies, though.

[AndreasModerator]

Softkeys can be assigned to MMC and DAW Bank Control, the messages sent are described here: Qu MIDI Protocol V1.82+

[AndreasModerator]

just to repeat myself: DAW Control isn’t necessary at all to use the Qu as a control surface, as long the DAW allows control surface customization. I’m not a Sonar user, but it seems that Sonar has everything you need to get this running without DAW Control:
Setting Up a MIDI Device as a Control Surface in SONAR
Sure, it takes some time, but you are able to customize everything to your needs and you’re not limited to the restrictions of that legacy HUI protocol.
keeping shut again.