Alternative interfaces are best when they actually leverage the power of being alternative.
The opinions expressed are mine only. These opinions do not necessarily reflect anybody else’s opinions. I do not own, operate, manage, or represent any band, venue, or company that I talk about, unless explicitly noted.
Even if you don’t use X32-Edit, the remote/ offline software for Behringer’s X32 series of consoles, I think you should keep reading. I say this because the point of this article is not to “dig deep” into the feature set of X32-Edit. Rather, I want to speak in (fairly) general terms about what console-remote software can get right, and not so right.
I’m a publicly avowed fan of Behringer’s X18. I’m especially a fan of the control software, which I feel absolutely nailed what console control software should be. The ironic thing was that I felt the X18 application was markedly BETTER than the remote control/ offline editor for the X32 – and the X32 is the higher-tier product!
But why would that be?
Well, rather like the gentlemen of “Car Talk,” I have a theory – or, more correctly, a hypothesis. My guess is that the X18 software was better because it was free, from the very beginning, to act purely as a virtualized interface. The X32 series is solidly founded on consoles which have a real control surface, the only true exception being the X32 Core model. An X18 and its cousins, on the other hand, are built on the idea of having almost no physical controls at all.
With the X32, then, it was very easy for the software designers to choose to closely emulate the look and feel of the physical control surface. In the case of the X18, there was never any surface to copy – and the control implementation benefited greatly as a result. The software was always meant to be a connection to something abstract; DSP and digital console commands have no physical form that they are required to take. With this being the case, the presentation of the controls could be built to fully embrace the nature of a display device fundamentally decoupled from the console. The control layout can be rearranged to best leverage whatever screen size and geometry is available. Actions can be streamlined, contextualized, and made more powerful with the recognition that a user can apply multiple control gestures (click, long-click, double click, right-click, etc) on a single element. You can easily have a console overview that provides a ton of information, yet remains interactive.
The X18 software took great advantage of the above, which meant that I immediately recognized it as the way that X32-Edit SHOULD have worked. To be both clear and fair, the previous iterations of X32-Edit weren’t poor or unusable. What they were was “conflicted.” They sort of took advantage of what a large, decoupled view device could do for console usage, but they also often limited their behavior based on the limitations of the physical control surface’s display. Why make something less capable than it can be? In my mind, yes, there is a point in having familiarity – but getting powerful usage out of a console is more about understanding the concept of what you want to do than memorizing the button presses to do it.
Also, the old X32 remote implementation never showed as much overview as it could have with all the screen real-estate that was available, and it couldn’t really “flow” itself into different screen shapes and resolutions either. It had a basically fixed size and aspect-ratio, and if that didn’t take advantage of what was there…tough.
Thus, I am very, very happy with the new X32-Edit. It acts like a beefed-up version of the X18 application, taking all kinds of advantage of being a virtual window into the mixer. Everything seems to be more immediately accessible, and the display offers real customization in terms of what you’re looking at. The software isn’t trying to be a copy of the control surface; It’s trying to be a replacement for it.
And that has made X32-Edit into the software that it always should have been.