Qu MIDI specs

[Nicola A&HKeymaster]

Hi all,

We have published the Qu MIDI Protocol specs on the product page.

‘Qu transmits MIDI messages when its controls are operated. It also responds to parameter changes it receives via MIDI, for example from a computer, Qu-Pad or an external MIDI controller.’

Hope this helps.

[MarkParticipant]

First, thank you for posting this. I was able to figure out how to midi control my QU-SB because this document exists.

So, please don’t take it personally when I say – could you have at least gone to the trouble of converting the hex values? This is one of the most unfriendly midi spec sheets I’ve come across in ages!

[Ando_ShyParticipant]

The MIDI protocol specs are essential and effectively was the deciding factor on picking up a QU-SB mixer for me. I was originally on the fence as it seems risky to me to invest in a system that can only be controlled via iPad. You never know how long a company will continue app support and development, especially with pro audio gear as the amount of support largely depends on adoption rates. However, I am also a software developer and open sourcing control protocols means I can always develop my own control software should the app be abandoned.
With all that said I have basically been able to get everything working via the provided MIDI protocols. However, I have run into difficulty with the Sysex protocol. So my question is does the QU-SB send meter data over USB MIDI or only with network (TCP) MIDI? Because I’ve tried polling for the meter data and running the Sysex All Call over USB MIDI and I receive no reply from the console. All the other controls and buttons return MIDI messages as expected.

[tim4742Participant]

In my opinion it is a very friendly midi spec sheet. Using the hexadecimal system is quite commen and very pleasant when working with byte values.

[mishu123Participant]

Hi,
Can you post a direct link please? Can’t find this anywhere. Thanks.

[tim4742Participant]

Hi,
To find the document select one mixer and look under the “documents” tab.
https://www.allen-heath.com/key-series/qu-series/

The direct link to the currently latest document is:
https://www.allen-heath.com/media/Qu_MIDI_Protocol_V1.9.pdf

[MikeParticipant]

I have a Qu-SB with 1.94 firmware that I’ve been able to successfully connect to via TCP. Once connected, I receive a stream of active sense 0xFE bytes from the mixer, as expected. I’ve also sent the sysex all-call message to receive a stream of NRPNs, which I am also receiving.

However, the TCP connection is always dropped by the mixer after 12 seconds. According to the v1.9 PDF documentation (which by the way is missing info about the Qu-SB):

Qu also responds to Active Sense If it receives an Active Sense byte it will expect to receive
regular MIDI data from that point onwards (either valid control data, or more Active Sense bytes
during any period of inactivity). If it does not receive any data for 12 seconds, it will close the
Ethernet connection

So it appears that all I have to do is send *something* back – an activeSense command, anything. So I send an activeSense, and the connection is closed after 12 seconds anyway. So I send one activeSense per second, and the connection is closed after 12 seconds. No matter how I respond, the connection is closed after 12 seconds.

How do I keep the connection alive?

[Alex A&HKeymaster]

Hi Mike,

I’ve had a play with this myself and found that if you set the iPad flag to 00 rather than 01, this stops the requirement for an Active Sense Byte response.

If you would like to keep the active sensing, you will need to send an Active Sense Byte every 300ms.

I hope this helps!

Alex

[MikeParticipant]

Hey Alex,

Thanks so much for the response. I’m curious about the iPad flag byte: you wrote “00 rather than 01”, but the PDF shows 10 instead of 01:

REQUEST: Sysex Header (All Call), 10 <iPadFlag>, F7

So that line can be read a couple different ways:
– 10 **is** the iPad flag, make it 00 to disable it
– 10 is the byte **precedeing** the iPad flag (though there’s no comma)
– 10 OR’d with the iPad flag makes it 11 if you want the iPad flag enabled

So I’ve tried sending ‘sysex-header, 10, F7’ and I get the NRPN messages (which I desire, btw), and that’s when the connection is dropped after 12 seconds. I’ve tried sending ‘sysex-header, 00, F7’, which I think is what you’re suggesting, but I no longer get the NRPN messages (that I want). So unfortunately, I think I must have the iPad flag enabled, otherwise I’ll never get the NRPN responses.

Do you see any errors in my data/logic? Thanks.

[Alex A&HKeymaster]

Hi Mike,

It looks like there may be a comma missing there.

Here’s what it should be:

REQUEST: Sysex Header (All Call), 10[,] iPadFlag, F7

So the version flagging that it is an iPad connection would look like:

F0, 00, 00, 1A, 50, 11, 01, 00, 7F, 10, 01, F7

The version flagging that it is not an iPad:

F0, 00, 00, 1A, 50, 11, 01, 00, 7F, 10, 00, F7

The second one should keep the connection without sending any response.

Thanks! Alex

[MikeParticipant]

Wow, thanks man! I’ll give that a try this evening. For now: day job 🙂

[Alex A&HKeymaster]

No problem at all!

If you have any trouble let me know

Alex

[MikeParticipant]

Alex,

What a difference one little byte makes. I added 0x00 between the 0x10 and 0xF7 and viola – I got all the NRPN data and the comm link stayed up. Lifesaver!

[MikeParticipant]

Alex,

So I’m parsing the bulk SysEx and NRPN data coming back, and I’ve run into an obstacle that I’d like some confirmation. Here is a snippet of the data stream that comes back after the sysex all-call request (newlines added by me for clarity):

0xb0 0x63 0x39 0xb0 0x62 0x65 0xb0 0x6 0x57 0xb0 0x26 0x0
0xb0 0x63 0x39 0xb0 0x62 0x66 0xb0 0x6 0x5b 0xb0 0x26 0x0
0xb0 0x63 0x39 0xb0 0x62 0x67 0xb0 0x6 0x0 0xb0 0x26 0x0
0xb0 0x63 0x39 0xb0 0x62 0x68 0xb0 0x6 0x0 0xb0 0x26 0x0
0xb0 0x63 0x3a 0xb0 0x62 0x61 0xb0 0x6 0x1 0xb0 0x26 0x0
0xb0 0x63 0x3a <– Split NRPN message, Part 1 of 2
0xf0 0x0 0x0 0x1a 0x50 0x11 0x1 0x0 0x0 0x2 0x21 0x4e 0x6f 0x72 0x64 0x20 0x52 0x0 0xf7 <– SysEx Channel 2 Name
0xfe
0xb0 0x62 0x62 0xb0 0x6 0x32 0xb0 0x26 0x0 <– Split NRPN message, Part 2 of 2
0xb0 0x63 0x3a 0xb0 0x62 0x63 0xb0 0x6 0x11 0xb0 0x26 0x0
0xb0 0x63 0x3a 0xb0 0x62 0x64 0xb0 0x6 0x0 0xb0 0x26 0x0
0xb0 0x63 0x3a 0xb0 0x62 0x65 0xb0 0x6 0x57 0xb0 0x26 0x0
0xb0 0x63 0x3a 0xb0 0x62 0x66 0xb0 0x6 0x5b 0xb0 0x26 0x0

As the NRPN and sysex packets started streaming in, I also started receiving interleaved NRPN and sysex messages, no big deal. But the big deal is the sysex packet would often arrive in the middle of an incomplete NRPN packet, then the remainder of the NRPN packet would arrive (and sometimes with activesense in there too, as shown).

I can learn how to deal with this, but I wanted to confirm that this is normal behavior and not some “hey, upgrade to the latest fw to fix it” kind of thing. Being lazy, updating firmware is easier than compensating for separated packets :-).

[Alex A&HKeymaster]

Hi Mike,

I would recommend running the latest firmware as I’ve not come across this issue before.

If this doesn’t solve it, please start a ticket at support.allen-heath.com and I can look into this for you.

Thanks! Alex

[Author]

Posts