I’m somewhat puzzled by the midi messages I am seeing. I have midi control set to 1.
When I move a midi strip fader is see messages that appear to be channel 2 e.g. B1 00 16 which since midi channels are encoded as 1 = 0 2= 1 etc. Seems to be channel 2.
Doc says:-
MIDI channel number
N
MIDIchannel 1to16 = 0toF
I notice that the QU midi protocol doc says that daw control uses midi channel + 1 . So does the GLD also do this, although it is not documented?
My other puzzle is that I see messages on channel 1 such as
B0 00 03
C0 6E
B0 63 10
The latter appears to be sent fairly frequently, but apparently at random. What are they? They appear to be an NRPN MSB selecting Channel hex 10, but there is nothing following them, e.g. The expected LSB parameter etc. So what are these, and why are they being generated. I’m just ignoring them, but I’d like to know what they are for.
Is there an updated midi spec for gld v1.51 that might explain these. As far I can see nothing in that area is supposed to have changed since 1.4 which introduced the midi strips.
Puzzled!
I know it’s me but I still need help. I downloaded the drivers and installed them on my computer. I went to setup and set all sixteen channels of the custom layer to MIDI. I plugged the QU into the computer via the USB B. I started the A&H application and the window popped up. In the window it shows mixer as QU, MIDI channel 2, protocol Mackie, MIDI port has the dot, but…nothing is available for the input port and the only thing on the output port is blank or Windows.
I have uninstalled and reinstalled the DAW software; undone, powered off and redone the settings in the QU16, reconnected and tried again. And again. Can anyone shine a light one what I am doing wrong?
Thanks
Chuck
Hi Guys,
Since this week I’m the owner of a C3500/CDM48 setup, and its amazing! But there is one thing I can’t figure out.
Because I’m going to use the setup in theatre shows, I really need a good midi connection between the surface and Qlab. I know the basics in midi programming, but not the HEX part.
I already managed to program soft keys for Qlab triggers, so I can trigger a Que from the C3500 surface.
My problem is the other way around…I want to program a MidiQue in Qlab, witch recalls a specific scene in the DLive. I think it should be a SysEx message, but when I choose that option, my MidiQue immediately gets a red cross.
Who can help me out…I already looked in the GLD/DLive Midi protocol pages…but I really don’t know witch code I have to put on witch place…
Thanks in advance!
Roel
Thank you Andreas for the new version
It is with the Get System State Sysex message. I receive then tons of NRPN and 56h is one of them. (Maybe my parser error? I don’t think all is documented)
I am using .net and don’t know to program with c++ juce and multi platform…
So at last we will have a nice QU program for windows
While decoding this huge nrpn stream, I now understand a lot more my QU mixer and it is full of options 🙂
I only dream about having the AB168 extension for the QU-PAC so my program will really shine 🙂
With my app, it will be so much easy to mix but
Not sure if QU MIDI protocol can be as fast as the one used by the QUPAD app
Maybe the QUPAD app allow to have a better resolution than 0-127 for the faders?
So still have to find the 56h…
Well, latest version is here: Qu Mixer MIDI Protocol – Firmware V1.9+. NRPN ID 56h isn’t documented there either. When does this occur?
I guess there are several people very interested to have remote capability on a “regular” computer. If you’re right at a start I’d highly recommend to use some multi-platform environment like JUCE and not only focus on Windows.
A clever approach would include an offline version to, at least, name and pair channels with possibility to send that configuration to the desk later (when in reach).
Hi,
I’m new here, I’m having a bit of a hard time interpreting the data sent back from the Qu-16 model. The protocol is 1.82 and after looking at the pdf it mentions how the data is encoded/decoded. If I understand correctly:
-Every 8 bytes must be unpacked into 7 bytes.
-2 bytes (16 unsigned bits) are used to decode a single float (db).
My questions:
-The meter data is in dB, but the meter is in dBu’s, am I missing something here? db dBu conversions is impossible if I’m understood correctly
-The amount of data as you’ll see in the log varies everytime, why is this? If the transmission order is correct I don’t see how this would make any sense.
-How do I get the db for the meter? (picture attached)
I attached a more technical detailed log of what is happening. The audio is a sample of constant volume.
Here the technical log. (Mediafire) (4.25mb)
Any help is appreciated. Maybe I missed another forum topic regarding this…
The protocol I’m refering to: https://www.allen-heath.com/media/Qu-MIDI-Protocol-V1.82.pdf
Thanks,
Austin
Attachments:
You must be
logged in to view attached files.
Hi,
as already mentioned it does work with 1.9. But there are quite some things which are not supported
due to protocol limitations.
This is also the reason why there is no update recently. My plan for the future is to implement the iPad protocol which allows access to all parameters but
there is no documentation for it available so it takes quite some time to reverse engineer everything.
Also it seems like the iPad protocol has much less bugs than the midi protocol.
OT: Why the hell is the A&H forum still running on http and not https?
It’s 2017 and certs do not cost anything. Also wpengine (where this page is hosted) can integrate tls for free.
No, in this instance ‘3rd party controllers’ refers to Crestron, AMX or similar control systems that can send/receive custom messages over TCP/IP. One typical application is the integration with other equipment such as light, video etc.
The details of the TCP/IP protocol will be published with firmware V1.5 but for anyone interested, the GLD MIDI TCP protocol offers a good starting point for simple Scene recall or input level / mute control.
In short:
– Faders are not touch sensitive
– You receive MIDI through separate port for nearly any control which you may use for learning (check out MIDI Protocol). The strip controls still follow the channel selection of the Qu not selection of your DAW.
– The faders are not unaudible, doesn’t hurt at all in a live environment, if this is critical for you, its better to check at a dealer.
– Never saw crashes when plugging the Qu in or out.
Hi Lukree
I think the faders in the Custom layer are fixed via the Daw control app and do follow the midi data very well. They do send NRPN but i don’t know what it would do to the DAW Control if you mapped one fader separately, because it runs with Mackie and HUI protocol and its premapped as far as i know. The DAW Control works perfectly on my QU-32 in Ableton as do other mappad parameters for DAW Control on the mixer. I use Windows 7 and the latest version of Ableton. Maybe if you go to preferences in Ableton to MIDI/Sync menu and try something with the the DAW Control settings there? You could set the NRPN to send out a CC and it should run smoothly, but i don’t know why one fader wouldn’t follow the midi data. Is it always the same fader? Does the fader just stop following the midi data in the middle of the session in Ableton or it just twitches from time to time and then works again?
Anze
I guess selection is only sent from the custom layer (search for “strip keys” in Qu MIDI Protocol.
Hi Johannes,
Any Scene recall on dLive will trigger a MIDI Program Change message where the Program number is the number of the Scene (in hex). This is transmitted over TCP/IP. If you are using a Mac, you can download the A&H MIDI TCP driver, which will create a virtual MIDI port in OS X, and you can then learn / assign the Program Change message as required. We don’t have an equivalent utility for PC at the moment I’m afraid.
For details on the MIDI messages and their format you can download the GLD MIDI protocol, which is nearly identical.
Hi Anreas
Not all of us are Midi Savvy, And your telling me that basically you’ll repeat all this again….. Well I didn’t see anything above that you repeated about “The Qu mixers are fully controlable through well documented NRPN messages as documented in Qu Mixer MIDI Protocol, nothing secret.” Well Its News To Me! Anyway I do see some workarounds, Now/ someday when Ive time. I don’t recall seeing anything about “If the DAW isn’t flexible enough to learn/understand the Qu’s NRPN implementation, there’s still Bome’s MidiTranslator.” Must have missed that too.
Ok, just to repeat same statements already written here and in several other threads:
– The HUI/MackieControl protocol is pretty limited. Since this is sort of legacy “standard”, there is nothing A&H can do to circumvent it, since the DAW’s side of that implementation would not follow. In fact its the application which defines how the buttons and encoders of the MackieControl are mapped and uses the large LCD to visualize the current mapping to the user. The Qu does not provide dynamic labels per encoder so the user would never know what’s actually mapped.
– The Qu mixers are fully controlable through well documented NRPN messages as documented in Qu Mixer MIDI Protocol, nothing secret.
– If the DAW isn’t flexible enough to learn/understand the Qu’s NRPN implementation, there’s still Bome’s MidiTranslator.
