What it does
Most desks have no automixer, and the usual ways of adding one cost you something. Insert it on every channel and it eats an insert slot per channel, sitting wherever the desk's insert point happens to be, which is usually pre-fader. Run each mic through two channel strips instead and your channel count doubles.
MixerReturn makes a third way possible. The automixer runs on the channel direct outs, set to follow the fader, with one SuperRack rack per channel. A second rack per channel picks the automixed signal back up over a loopback pair, and MixerReturn sums those down to a single stereo pair that comes back into the desk as a group's external input. You keep mixing on ordinary channel strips, the automixer sits post-fader without any insert point being moved, and the insert slots stay free for the plugins that would normally live there. You can't skip the second rack: SuperRack's Dugan is part of a rack's output stage, after all eight plugin slots, so nothing inside a rack can sit after it.
The summing is the one bit neither the desk nor the host gives you. SuperRack's patcher allows only one rack per output I/O, so you can't patch twenty-four rack outputs onto one output to mix them, and the desk can only sum them by spending twenty-four input channels on it. SuperRack Performer got third-party VST3 hosting in v14, which is the only reason a plugin can fill that gap at all.
- Eight independent summing buses, shared across every instance in the host
- Sending and receiving are independent per instance — a sender, a receiver, or both
- Per-instance send trim and mute, over the same -inf to +10 dB range the SQ's own direct out trim uses, so the two read alike
- Output modes: pass the rack's own input through, replace it with the bus sum, or both
- One block of delay on the sum, identical for every sender whatever order the host processes instances in
- Live member count and latency readout, so a rack that never joined the bus is visible rather than merely quiet
- Nothing in the audio path takes a lock or allocates — bus and slot are packed into a single atomic the audio thread reads
Where it stands
Released at v0.4.2, with prebuilt plugins for macOS, Windows and Linux. v0.4.1 changed nothing but the Windows installer, which no longer touches the system PATH (the earlier one could overwrite it). v0.4.2 ramps send trim, output trim and mute across the block instead of stepping them once per block, which was a zipper on a fader ridden live and a full-scale click on mute. It also lets the barrier converge on the instances actually being processed, and refuses a shared-memory region that's too short. The summing bus is checked numerically against the shipped processor class: a one-block delay with the summing instance processed both first and last, 24 senders with the host's processing order shuffled on every block, and 400 blocks with 17 instances racing on their own threads. It's clean under ThreadSanitizer, and pluginval passes at strictness 8 on VST3 and on AU with one harmless wrapper warning. It's also been run with real audio inside Waves SuperRack Performer, over a loopback virtual device: pass-through is bit-exact and adds no delay, the sum equals the sum of its senders delayed by exactly one block with 0 of 143744 samples wrong, -6 dB of send trim comes back as -6.00 dB, a muted send comes back as zero, and a bypassed instance contributes zero without wedging the barrier. That testing found two things worth the trouble. The first is the topology: a MixerReturn sharing a rack with the Dugan taps the signal from before the automixer, so the return carries a plain sum with no automixing in it (measured at +0.02 dB against rack outputs automixed to -4.39 dB, with the last of the eight slots no better than the first). It takes two racks and a loopback pair per mic. The second was a latency report eight times too high. A host's prepared block size is a maximum, and SuperRack prepares 2048 and then processes 256, so reporting the prepared value claimed 42.7 ms for a bus that delays 5.3 ms, and the host believed it. It's still never been run against a real console or used on a show, and every claim about console behaviour comes from the Allen & Heath SQ reference guide rather than from hardware. The concurrent test paid for itself straight away: it found a bug every sequential test had sailed past. The audio path took a process-wide try-lock and skipped the block when it lost, which you'd never see on one thread (a single thread always wins an uncontended try-lock), and which drops instances out of the sum without a word once a host spreads racks across several. So a try-lock doesn't make a shared structure real-time safe; it just turns contention into dropped work. The target host is SuperRack Performer. SuperRack SoundGrid takes its I/O from SoundGrid hardware rather than a CoreAudio or ASIO device, so it isn't a target.