Hi Sengstake,
The External Control in AHM-64 was designed for simple commands to trigger projectors or video switchers, not as a substitute to dedicated control systems like Crestron or similar. There isn’t a way to pass on variables like fader position to a specific IP address / TCP port. My recommendation here would be to adopt a third party control system.
Alternatively, you could use the AHM-64 own TCP port to ‘read’ the level of a spare input channel, and program a piece of software to translate this NRPN message (detailed in the TCP protocol document) to a MIDI / OSC message you can send to the CueCore. For example, a computer running A&H MIDI Control (to expose the AHM messages on a virtual MIDI port) and something like Bome’s MIDI Translator can be set up this way, but will require some knowledge of MIDI and programming efforts.
Hello Hive Mind,
before writing a ticket and consulting my local distributor in the night about this issue I wanted to ask this place for some advice
First off I tried the search term ahm 64 with a smacking 15 results. my hopes are higher than that number.
we have some presets already set up in the Manage tab of the AHM System Manager 1.02. Now for external control I use TCP to pass some commands to a CueCore2 light controller
triggering Playbacks and Cues on that device to align the audio presets with the lighting scenes works fine.
my question is how do i manage to pass a fader or channel value to the CueCore2 (that has a TCP API already, code is pretty easy: core-pb-1-intensity=<channel value as float>)
for our contractor I want to build a GUI in the iOS App where the lights should be dimmed with a virtual fader same as audio levels.
In the Manage/Presets tab I am not able to see a solution to pass a variable via UDP/TCP
Sure is, a Preset is recalled and UDP/TCP code gets send via network and received by CueCore2, this works fine already! But it’s only sent once.
But how to control non static more dynamic funtions of any 3rd party UDP/TCP devices ???
The CueCore2 also supports MIDI and OSC protocols, so not necessarily UDP/TCP is needed. Is there another way to solve this issue
I really don´t want to sell my contractor something like this
Audio Preset 1 with 100% light intensity
Audio Preset 1 with 50% light intensity
Audio Preset 1 with 25% light intensity
Audio Preset 2 with 100% light intensity
Audio Preset 2 with 50% light intensity
Audio Preset ...
nor do i want to program this as presets.
So…how do I get a fader value transmitted via network in. real. time.?
@nottooloud
The 3rd party control drivers (Crestron, AMX, Extron, Neets) all make use of MIDI as this is our only public protocol.
Proprietary network control protocols are not public however and also often change with major firmware revisions (hence why the app and firmware versions must match).
SQ MIDI’s protocol includes Level, Pan and Assignment for around 2000 parameter numbers (addresses), so about 6000 controls with high resolution control of levels (16384 steps). In addition, there is complete Mute, Soft Key and Scene control. There is also toggle options for switches, relative control options (e.g. ±1dB) and get methods to return the current value.
Worth noting here is that the inclusion of Soft Key control in the protocol is to enable remote/automatic ‘by-proxy’ control of many more parameters.
Please put any requests for other MIDI control in the ‘feature suggestions’ area though so they can be discussed and considered for future updates.
(I personally really hoped for MIDI Clock -> Global Tap but as it was not possible directly, I just use virtual Soft Key taps instead)
Cheers,
Keith.
@keithjah
I’d love to see someone write a Companion module. I’ve gotten a lot of use out of the X32 module.
A&H website says:
Documentation for the mixing systems, including specifications of the TCP/IP protocols can be found here:
but that SQ link just wraps back to the SQ product page.
3rd Party Control page
Are the control protocols available?
The available MIDI controls are quite limited.
@alex,
Have you created a spreadsheet for the SQ like the one you did for the QU?
Dear all,
I did get the immpression that it is possible to record track is Garageband from inststrument/mic’s that are connected to a QU16 (in my case). However, for me it doesn’t seem to work. I think I have the correct setup and setting but still no go. This is what I have:
-QU16 (latest software build available)
-Global USB B Streaming is set
-The USB cable is connecte to my MAC (El Capitan)
-CH2 patched to USB
-I/O Patch untouched so 2 = CH2
On the MAC I have installed the DAW controller
-Mixer QU Series
-MidiChannel2
-Protocol: Mackie Control
-Midi Ports radio button selected
-Input Port: QU-16 Midi Out
-Output Port: QU-16 Midi In
When I move a fader on the QU, the square box in the lower right corner of the DAW control start turning black so I now the connection is establisht.
When looking into the MAC’s Midi Setup I can see the QU-16 and all the in- and output channels. QU-16 is selected and the sample freqency is set to 48Khz. CLock source is QU-16 Audio
In Garageband then, I add a new Audio track and select input 2 and Listing to QU-16
When all this is completed, I would assume that talking into the mic on channel 2 that is unmuted would result in some kind of signal. But nothing happens. On the QU I can not even see an input signal. When I swith from USB to normal, I do have sound and input level volume. Back to USB…all is mute.
Can someone please help……
Hi @uselessoldman,
There is no way for the DAW to ‘see’ the mixing functions (or FX as you suggest) and no way for the Qu to ‘see’ the DAW.
But to explain further, the MIDI capabilities of the Qu can be split into two parts:
-
MIDI control to and from the mixing core which mostly uses NRPN messaging (as detailed in the MIDI Protocol – https://www.allen-heath.com/media/Qu_MIDI_Protocol_V1.9.pdf). This is intended for control of the mixer or recording of automation for control of the mixer. Something to be clear with here is that the messaging goes to and from the core, so it works in parallel to the surface controls i.e. moving a rotary would send a message to the change a parameter in the core which would then send a MIDI message, so the message would not be being sent from the rotary itself.
-
MIDI channel strips and SoftKey options. These do send messages from the physical controls on the surface and are not linked to the audio mixing core.
Use of the Qu as a DAW Control Surface uses MIDI channels strips and SoftKeys, taking standard MIDI CC and note on/off messages and converting them to emulate either HUI or MCU protocols.
The Mute, Sel and PAFL keys for each strip work as Mute, Select and Solo for each DAW channel, and the physical fader will control DAW channel level.
Alongside this, there are SoftKey options for bank up/down and MMC control.
This is all bidirectional too, so the motorised faders will follow your DAW, as will the LED’s showing selected channel, mute and solos.
All of this is just MIDI though, so of course it can be used however you want.
We often recommend a MIDI translator (such as Bomes MIDI Translator) if you want to convert one set of messages to another for particular applications.
Hope this helps!
Keith.
MY current setup is a rack system, Sapphire Liquid 56 Audio Interface, ADAT expander, 8 channel DI-Pro Samson SCom patch panel and a 8 channel splitter. I needed this setuyp to mix in 7.1 so I need 8 output channels. I run this into a dedicated WIndows 10 computer and mainly use Studio one. Instrument wise I have a few guitars (Les Paul RG570) and a couple of keyboards (Native s49 and a Nektar 88+). Previous to this I used a Yamaha 01x, I still have it but it has serious windows 10×64 issues, in that it will only run properly when windows is in development mode (test mode). Now down to my question, current issue/situation. I want and miss my motorised faders and DAW control interface. My keyboards are both (usb) midi controllers and have limited DAW control but there not motorised, and really a pain more than useful for DAW control except they are useful for vst plug in control.
So I have been looking at the market options for what DAW controllers were available when I happened to come across the AH QU-16. My original short list included the Mackie Pro (£1000) the Behringer x32 (£1100) but the Mackie is only a DAW controller not an audio interface and the other is a Behringer but is a DAW controller and audio interface combined. My first or top priority is DAW control with motorised faders like my Yamaha 01x, a built in audio interface would be nice, flexibility. My rack is mobile/portable but me thinks a desk mixer with an audio interface would be a mice to have alternative option. Price wise I originally had wanted to keep it to the 1k mark but I realise for a few extra quid I can also have a complete unit with the audio interface. I originally went rack mounted simply cos if something breaks I don’t loose everything I just have to replace one unit and why the Behringer x32 is not an option, especially at £1100. Yes the QU16 is £1400 but really its only £400 more than the Mackie and being AH I am sure quality is not an issue. As for the 48kHz not an issue since my plug ins oversample and I have the Sapphire if needs be.
SO my question is about the QU range and DAW/VST plug in integration, which comes down to HUI MCC protocols. I assume from the downloads available one has to use the generic mackie control for DAW (as I do with the Yamaha) but what will this give me DAW side wise with the features of the QU16? Will a DAW see any effects used on the QU16 or just see the input channel as generic? and can I control a vst from the QU16 which I can using my keyboards. If I change effects on the DAW/computer will the QU16 see this and make the required changes? ie 2 way synchronization between the DAW and QU16? there again can the QU16 talk to my keyboards? I guess through those old midi cables I have somewhere, people still use them oh yes I do for my Yammi DG1000 when if I ever use it, which is almost never now.
So thanks for reading my essay and any user experience advice or further questions would be appreciated.
@Skyatnight,
Not sure about that controller in particular, but it is possible to control a Qu remotely via its MIDI protocol (https://www.allen-heath.com/media/Qu_MIDI_Protocol_V1.9.pdf).
So it would depend on whether the controller can be programmed to send and respond to NRPN messages.
The other thing you could run into is that the Qu uses an active connection to know whether there is something connected remotely. If this is causing problems, you could either use a computer in between the two running our DAW Control Driver (https://www.allen-heath.com/daw-control/), or add in a BomeBox (https://www.bome.com/products/bomebox) which would manage the connection and could also be programmed to carry out translation.
Cheers,
Keith.
Hi all
New to the QU-24 having just upgraded from a ZED-R16 that has gone to the great gig in the sky. Loving it so far, a lot to get my head around moving from a lifetime of analogue to a digital mixer for the first time.
One thing that I am really missing and doesn’t seem possible as far as I can tell from the manual and the latest MIDI protocol document is the ability to use the soft keys for MIDI control of my DAW. For example the equivalent buttons on my ZED-R16 were assigned to DAW functions that I use most often, such as zeroing peak meters, turning on MIDI sync, turning on click tracks, etc. etc.
On the QU-24 though it seems that the only MIDI use for the soft keys is either MMC or Bank up and Bank down messages. The ability to send 10 different MIDI messages that I can then assign to various DAW commands would be great. In fact I can’t believe that it’s not possible as it seems such an obvious use so perhaps it is and I just need to RTFM again.
If it isn’t possible please consider this a request for a future firmware. If it is please point me to where in the manual it explains how and I’ll go read it again.
Thanks.
Hi,
I have a qu-sb mixer.
I was wondering if it’s possible to use a fader midi controller with my ipad so i can sometimes have more physical feeling.
My guess is that an ipad will be able to connect to a midi controller just like a mouse or a keybord (Although different protocols are used), but i’m not sure if qu-pad app will response to it.
Anybody tried it before?
Thanks,
Yarden Karny
Oooo live techno with an SQ, that sounds fun! 🙂
You do not need to use the DAW Control Driver for direct MIDI control, though it makes things a lot easier if you need to communicate using MIDI over TCP/IP, enables you to switch between USB or TCP/IP connection easily and gives you access to the control surface emulations for DAW control. It sits between the DAW and the console too, meaning you can leave your DAW virtually connected without problems when you take away the console or requiring the MIDI connections in the DAW to be rebuilt every time you want to do something slightly different.
So I would suggest using it, and as long as you are not making use of the control surface emulations (MCU/HUI) for control of a DAW from the console, the best setup in your case would be to use the ‘MIDI Thru’ Protocol option.
Then connect to the console using the USB or TCP/IP option to find your unit, and patch the computer MIDI I/O to the virtual MIDI port created by the driver.
After this, it’s simply a case of sending messages from the MIDI protocol document to control things.
The USB and network MIDI messages are the same, so you’re just choosing how to get them to/from the console.
I should note that there is no real link between network MIDI and a connected expander though – just in case you were thinking about combining the two somehow.
If you need more help with your specific setup that might not be useful to other members of the community here, please feel free to get in contact using support.allen-heath.com and we can go into more detail.
Cheers,
Keith.
Hi all,
Your comments are very much noted – this is something we’ve been discussing for a while and working out the best way to implement. As pointed out here, there are quite a few different options.
Just making the newest version compatible with a previous one is not possible, as the messaging (both internal and remote) changes with every firmware revision.
Along with the addition of control for newer features, this is often to improve stability and performance.
Without knowing exactly what’s coming next then, the only way to make all versions compatible would be by never changing the existing messaging and missing out on these improvements.
Having different versions of the app on the stores would mean settings and stored shows would not be carried to the newer version, it also takes some time to get an app up in the first place, which is developer time for every release that could be better used elsewhere.
Providing/hosting older versions for sideloading is not possible either.
Of course the problem here is derived from an issue related to firmware which nobody would expect. However, as in the examples given and others where an engineer or musician may show up to an event or hire a console where an older firmware is running, there are multiple reasons for this backward compatibility.
So yes, we are looking at it.
@lightingman117 – Unlike the other messaging, the MIDI protocol will remain the same, so this is an option too.
Thanks,
Keith.
Ah totally forgot:
Mixing Station Pc/Osx can act as a protocol converter between OSC/REST and the mixer. This allows other software which only can communicate with OSC to work with any supported mixer.
An example use case would be theater automation with palladium or QLab. While it’s true that you could just use the TCP Midi driver provided by A&H the API provided by mixing station is cross mixer compatible. This means if you have your QLab show configured with mixing station you can change to any other supported mixer and most of the commands will still work.
Currently the documentation for this is quite rough so if you are an advanced user and interested check it out here: https://dev-core.org/ms-docs/integrations/apis/
Don’t worry, I plan to make this documentation easier to understand.
