Qu MIDI specs

Forums Forums Qu Forums Qu DAW integration Qu MIDI specs

This topic contains 16 replies, has 7 voices, and was last updated by Profile photo of Alex A&H Alex A&H 2 days, 14 hours ago.

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #35766
    Profile photo of Nicola A&H
    Nicola A&H
    Keymaster

    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.

    #65229
    Profile photo of Mark
    Mark
    Participant

    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!

    #69153
    Profile photo of Ando_Shy
    Ando_Shy
    Participant

    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.

    #83418
    Profile photo of tim4742
    tim4742
    Participant

    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.

    #84287
    Profile photo of mishu123
    mishu123
    Participant

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

    #84784
    Profile photo of tim4742
    tim4742
    Participant

    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

    #85829
    Profile photo of Mike
    Mike
    Participant

    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?

    #85834
    Profile photo of Alex A&H
    Alex A&H
    Keymaster

    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

    #85839
    Profile photo of Mike
    Mike
    Participant

    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.

    #85840
    Profile photo of Alex A&H
    Alex A&H
    Keymaster

    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

    #85841
    Profile photo of Mike
    Mike
    Participant

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

    #85842
    Profile photo of Alex A&H
    Alex A&H
    Keymaster

    No problem at all!

    If you have any trouble let me know

    Alex

    #85851
    Profile photo of Mike
    Mike
    Participant

    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!

    #85908
    Profile photo of Mike
    Mike
    Participant

    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 :-).

    #85912
    Profile photo of Alex A&H
    Alex A&H
    Keymaster

    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

Viewing 15 posts - 1 through 15 (of 17 total)

You must be logged in to reply to this topic.