I’m exploring redundancy options with two CQ-20B mixers and wanted to ask whether Allen & Heath would consider a firmware feature that allows mirrored control between two units.
Conceptually, the idea would be:
Two CQ-20B mixers connected to the same network
One designated as “Primary”
One designated as “Mirror” or Secondary / Standby Unit
All parameter changes on the primary (gain, faders, processing, routing, FX, etc.) replicated in real time to the secondary
In the event of hardware failure on the primary unit, the engineer could:
Switch outputs (or input splits)
Continue seamlessly on the mirrored mixer without reloading a scene or rebuilding the mix
I understand this is not currently supported and that the CQ control architecture likely treats each mixer as an independent host device. However, as compact digital mixers are increasingly used in semi-professional touring and mission-critical environments, a lightweight redundancy mode could be extremely valuable.
Even a simplified version… such as:
Real-time parameter sync without audio engine linking
Or periodic state replication between two CQ units
… would provide meaningful resilience for live applications.
Is this something that could be technically feasible within the CQ platform architecture, or is the current hardware/firmware design not structured to support mirrored state replication?
That’s an interesting suggestion… I wonder what the mean time between failures is for these mixers? Your proposal to have two CQ20Bs connected to the same network inevitably reduces the effectiveness of resilience measures. I appreciate the necessity if devices are to sync in real time but given the propensity of IP network connections to fail (albeit usually because of poor configuration), it might be a less resilient arrangement than hoped.
If you could connect an ipad to two mixers on the same network and control both at the same time . . .
I don’t believe that would work, as the CQ app establishes a direct session with a single mixer IP at a time rather than broadcasting control commands to multiple devices.
Even if two mixers were on the same network, the app would still treat them as independent hosts. My routers are configured identically so they’re hot-swappable from a network standpoint, but that wouldn’t duplicate the control layer between two CQ units.
That’s why I was wondering whether firmware-level mirroring between two mixers could ever be feasible.
That’s an interesting suggestion… I wonder what the mean time between failures is for these mixers? Your proposal to have two CQ20Bs connected to the same network inevitably reduces the effectiveness of resilience measures. I appreciate the necessity if devices are to sync in real time but given the propensity of IP network connections to fail (albeit usually because of poor configuration), it might be a less resilient arrangement than hoped.
That’s a fair point regarding shared network dependency. I agree that introducing a common control network can create a single failure domain if not designed carefully.
My thought process was more about mitigating mixer hardware failure than network instability. In this case, the routers are dedicated and interchangeable (same SSID/config), so network redundancy is handled separately.
The idea was simply to explore whether firmware-level parameter mirroring could allow two CQ-20Bs to stay synchronized in case one unit’s DSP or hardware failed… with audio input splitting handled independently (unless you had some sort of cleaver / elaborate set up with half-normalised patchbay splitting the connections).
I’m not necessarily suggesting a fully shared dependency model, just wondering whether mirrored state replication could be feasible within the CQ architecture.
The CQ series already sends most changes via MIDI, so a simple MIDI out from your primary to MIDI in to the secondary would accomplish a lot of this. You’d want to start both in a known state, presumably by loading a show and setting a common scene from a USB device.