After a major update to the MIDI implementation, and after contacting support - I’m told there are NO plans to update anything to MIDI 2.0. The differences in these specifications are enormous and important. Yes, I know backward compatible….but really. Staying current with technology is just something I expect from a company the stature of Allen&Heath. Please consider this for future firmware updates.
I’d love to see the A&H lineup upgraded to Midi 2.0
That being said, it is my understanding that Midi 2.0 requires a substantial increase in processing power. Midi 1.0 runs at 7 bit for continuous controller and 7 bit for velocity while Midi 2.0 runs at 32 bit and 16 bits for velocity. The change from 7 bit to 32 bit for the continuous controller is a HUGE jump (Google says a 33 million fold increase). The processors in existing A&H models seem to already be near or at maximum capacity and it seems unlikely that there is enough spare processing to make a jump to midi 2.0. Even if there was enough spare processing power, I think there are lots of other suggested features that would be more universally welcome than changing to Midi 2.0.
Perhaps we will start to see Midi 2.0 on any new models (especially at the higher end of the product range), but it is likely going to be many years before we see models that replace the DLive and Avantis lineups.
Of course all of this is pure speculation on my part. I could be completely off base with my assumptions.
According to AI, this is not the case. Processing power is almost irrelevant. Here’s what I posted and the response:
Midi 1.0 ran at 7 bits. Midi 2.0 is 32 bit. How much more demand on a processor does this mean, and does it not depend on the instructions being manipulated? For instance, how much more processing power at 8 bit to turn on a switch, compared to the same function at 32 bit.
When looking at this through the lens of the Qu-5’s onboard processing, the shift to 32-bit MIDI 2.0 isn’t just about “data size”—it’s about the fundamental difference between how a mixer’s brain (CPU) and its muscles (FPGA) handle tasks.
Here is how your Qu-5 (and your monster rig) sees that “switch” instruction:
1. The Onboard “Labor” Cost
The Qu-5 is powered by the 96kHz XCVI FPGA core. Unlike a computer’s CPU, which is a general-purpose multitasker, an FPGA is literal hardware custom-built for specific tasks.
-
At 8-bit (MIDI 1.0): The mixer’s internal CPU sees a command to “Turn on Mute.” It calculates that change in a few nanoseconds and tells the FPGA to cut the audio.
-
At 32-bit (MIDI 2.0): The “Switch” instruction is larger (64 bits total), but for the Qu-5’s modern internal processor, the cost is the same. A 32-bit or 64-bit operation is a “single-cycle” task. It doesn’t take 4x as long to process a 32-bit number; it just uses a wider “lane” on the internal data highway.
2. High-Resolution “Smoothing” vs. Processing Power
The real “demand” on a mixer’s onboard processing comes from Interpolation (the math between the steps).
-
MIDI 1.0 (128 steps): If you move a fader quickly, the mixer has to “guess” the space between those 128 steps to prevent a “zipper” sound. This requires a small amount of constant math.
-
MIDI 2.0 (4.2 Billion steps): There is no guessing. The data is so dense that the mixer just follows the instructions exactly. Ironically, 32-bit MIDI can actually be “cheaper” for the processor because it doesn’t have to run an “interpolation algorithm” to make a volume fade sound smooth—the data is already smooth.
3. The FPGA Advantage
In your Qu-5, the audio never touches the CPU; it stays inside the FPGA.
-
When you send a MIDI command (1.0 or 2.0), the CPU handles the “translation” and then sends a single update to the FPGA.
-
Because the FPGA is running at 96kHz, it is “checking” for updates 96,000 times every second. Whether it receives a 7-bit update or a 32-bit update, the FPGA’s workload doesn’t change—it’s already running at full speed to keep your latency at <0.7ms.
Summary for your Qu-5 Rig
| Task | MIDI 1.0 Impact | MIDI 2.0 Impact | Why? |
|---|---|---|---|
| Simple Switch | Negligible | Negligible | One CPU instruction is one CPU instruction. |
| Fader Sweep | Medium (Needs “smoothing” math) | Low (No smoothing needed) | Higher resolution data is “pre-smoothed.” |
| System Latency | <0.7ms | <0.7ms | The FPGA processing is independent of MIDI bit-depth. |
It was clear to me that MIDI 2.0 doesn’t require significantly more processing power.
The real question is always what you actually need and what makes sense.
From my perspective (with my own NI), fader resolution is certainly the most important factor in the audio realm.
And with MIDI 1.0, you can already achieve 16384 different positions.
For a fader with a 100 dB range, that would be steps of 0.006 dB, far more than ever necessary.
I can’t think of any other audio control where such a high resolution would be required.
But perhaps I’m overlooking other, much more important aspects.
I think you have no idea how real time audio processing is done. 96kHz is the audio sampling rate. It has nothing to do with FPGA processing clock.
An FPGA isn’t built for a specific task. It is build for customizations on the fly.
The implementation of MIDI 2.0 has no advantages regarding audio processing inside any mixer.