Hi Steve, as always thanks a lot for your help. The point was, i wantet three octatracks to reply and send the right cc values to the midi fighters. i found out, me idiot…, that the octatrack has a send all midi funtion ( i think cc 61). so this was a solution without spending those valuable global variables.
i now try to programm the same thing for my qu32. but i am overwhelmed. i dont understand those sysex messages, that qu needs. its written down in the midi protocoll on page ten, but well i dont get it. i simply want to send an messages to the qu, to let it send all his midi values. do you have any experiences with the qu?
thanks a lot and you are the most competent customer carer i know 
1 Like
Thanks for the kind words!
I agree that the QU protocol manual is somewhat confusing.
Maybe send the below message to your mixer and lets look at the results in the log.
F0 00 00 1A 50 11 01 00 7F 10 00 F7
I suspect it will come back with Not only the BoxID but also with the MIDI channel number at which point, maybe we could figure out how to query parameters. Either that or perhaps we will get back a dump of NRPN messages with all available parameters followed by the End Sync response. Then we could look at the chart on page 13 to figure out how we can map these NRPN message back into the variables you want to capture.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Great Steve, thanks a lot. i will try as soon i switch on the studio. Best regards Tiberio
So i send the sysex message to qu 32 via usb midi and i got absolute no (zero) response from qu32. if i move any parameter, i can see the sysex and nrpn data incoming. so i have no idea. it was send via the sysex message with the help of a faderfox midi controller. mtp says the sysex message is right.
I’m not sure what to say as I do not have a QU mixer. I’m just looking on the instructions on page 10 of the Qu MIDI protocol manual. Maybe you don’t have the latest version of firmware? Maybe you should ask Allen & Heath?
Maybe if you can show some of the messages the QU is sending, we can figure it out? I limited in my ability based on the documentation I have.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Try sending this to see if you get any response?
F0 7E 7F 06 01 F7
Also try sending this. (Same as original message but V 1.9 instead of 1.0.
F0 00 00 1A 50 11 01 00 7F 10 09 F7
I’m splitting off this into a new thread more appropriate for the device type we are now working with.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi Steve, thanks again. What i think the problem is, it seems the qu does not receive any sysex data.
The way i try is:
creating a translator
input is a midi controller. this case cc from a faderfox
ouput is raw midi / system exclusive with specific port qu via usb
then sending all the sysex commands you gave me. happening nothing
mtp is receiving sysex from qu. for example muting a channel is:
90 35 7F
80 35 00
so i created a translator sending out those numbers and no reaction. my logic tells me, the specific channel should be mutet or unmutet now.
i wrote a email to allen heath support. but maybe i am doing something wrong programming those translators?
thanks for your help and have a good day. tiberio
Hi, could you open your project and the log window and check MIDI IN and MIDI OUT and then show an example of what you see in the log file?
Use the attached project file where computer keystroke Ctrl-Up will send a general MIDI query and Ctrl-Down will send a QU status query. (If you are on a Mac use Cmd in place of Ctrl.)
You will also need to set up your QU aliases to point to your QU32 mixer. For me I just assigned them virtual MIDI ports since I don’t have a mixer.
You can learn more about aliases from this tutorial.
QU-test-2023-10-02.bmtp (907 Bytes)
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi Steve. did use that bmtp file. send both request. qu does not respond to those messages. i attached the file. its really strange.
and the midi aliases are of course chosen right in my project. :). thanks again for your help
ok. now i was diggin deeper in some forums of allen and heath and well, keith of allen heath writing, that there are some midi messages only available via tcp/ip. including system state :0
so i have to manage this, never did it, but somehow it needs to be possible. new land for me:)
OKKKKKKK
i connected the qu to the bomebox via ethernet. inside the router i installed a allen heath connection where i manualy met the ip adress of the qu32. now sending the sysex data to the bomebox.net it make respond the mixer. a giant mass of sysex data. in my own project it overflows. i think because it is send via the usb port and the ethernet port.
in the project you send me there is no midi overflow.
OK so we are getting somewhere.
In MT Pro, make sure there is no MIDI Thru path (to avoid the application overflow), then capture the ton of data you are getting in the MT Pro log file. Then we can look at it and put translators together for the specific data you want to capture and either use that information to update global variables or to convert it to something else to pass along to another device (or both). There is probably a lot of information you really will not care about anyway.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Good Morning Steve (well here in Germany), due to the fact, that i became a new second mixer, the enjoy godfather, which can be used with midi, i needed the sends of the qu 32. so i programmed the last day:
i gave every send a global variable (about 400)
at the beginn of the session i send the vallue of zero to this globals, so every parameter on qu is zero.
now i work with preset changes and every preset change i send the colour of each rotary and the value of the global variable to the four midi fighter twister.
now i can build presets for the twister like a modular system.
it was a shit of work and about 20 hours of working, but it works.
sure using the sysex is the much cleaner way, but i simply dont understand any of those sysex messages. i have to learn it, its a job gets done this winter.
for example i have no idea how a channel and a special value is send via sysex 
i fly now to spain for a week and then i will restart the task. a lot of thanks again for always helping me.
cheers tiberio
1 Like
I don’t understand too much about Syssex and don’t understand if you need a simple map, but I managed to map my qupac with midifighter twister.
‘Pocket Midi’ is a nice tool to identify messages from QU and midi fighter and convert to a Raw Midi/System Exclusive message.
The incoming message from the Midi fighter, you only need the 3 last values and set a variable ‘pp’ (after you set the midi channel and CC message in Midifighter). From QU, you need all the 24 pair of values and set the variable to the 18/19 numbers.
All you need is set the Midi pocket to receive messages from QU or Midifighter an copy the values.
He wants to query the QU device for the values of it’s current parameters. He is not having any trouble setting them. In the documentation it states how to do this but I guess at this time he is going to live with setting them by his MFT and having them all default to zero at startup.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
MFT starts with values at zero at startup.
I didn’t find a way for QU send the initial values to MFT. 
That would be a great improvement.
Send the following message to your QUPAC and it should respond with a tone of NRPN messages indicating all of their parameter values. At least that is what the documentation says.
F0 00 00 1A 50 11 01 00 7F 10 00 F7
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
But, discovered now, if I recall a scene, and if MFT is receiving midi from QUpac, all the parameters in MFT changes to the values of Qupac.QUpac is sending the saved values. Something I didn’t know. 