Playing with an X-Touch Mini controller using C#

Background

As I wrote in my earlier blog post about using OSC to control a Behringer XR16, I'm working on code to make our A/V system at church much easier to work with. From an audio side, I've effectively accomplished two goals already:

• Remove the intimidating hardware mixer with about 150 physical knobs/buttons
• Allow software to control both audio and visual aspects at the same time (for example, switching from displaying the preacher with their microphone on" to displaying hymn words with all microphones muted")

I have a third goal, however, to accommodate those who are willing to work the A/V system but would really prefer to hardly touch a computer. The requires bringing hardware back into the system. Having removed a mixer, I want to introduce something a bit like a mixer again, but keeping it much simpler (and still with the ability for software to do most of the heavy lifting). While I haven't blogged about it (yet), I'm expecting most of the work" during a service to be performed via a Stream Deck XL. The technical aspects of that aren't terribly interesting, thanks to the highly competent StreamDeckSharp library. But there are plenty of interesting UI design decisions - some of which may be simple to those who know about UI design, but which I find challenging due to a lack of existing UI skills.

The Stream Deck only provides press buttons though - there's no form of analog control, which is typically what you want to adjust an audio level. Also, I'm not expecting the Stream Deck to be used in every situation. If someone is hosting a meeting with a speaker who needs a microphone, but the meeting isn't being shared on Zoom, and there are no slides (or just one slide deck for the whole meeting), then there's little benefit in going for the full experience. You just want a simple way of controlling the audio system.

For those who are happy using a computer, I'm providing a very simple audio mixer app written in WPF for this - a slider and a checkbox per channel, basically. I've been looking for the best way to provide a similar experience for those would prefer to use something physical, but without adding significant complexity or financial cost.

Physical control surfaces

I've been looking at all kinds of control surfaces for this purpose, and my previous expectation was that I'd use a Loupedeck Live. I'm currently somewhat blocked by the lack of an SDK for it (which will hopefully go public in the summer) but I'm now not sure I'll use it in the church building anyway. (I'm sure I'll find fun uses for it at home though. I don't regret purchasing one.) My other investigations for control surfaces found the Monogram modular system which looks amazing, but which is extremely expensive. In an ideal world, I would like a control surface which has the following properties, in roughly descending order of priority:

1. Easy to interact with from software (e.g. an SDK, network protocol, MIDI or similar - with plenty of documentation)
2. Provides analog, fine-grained control so that levels can be adjusted easily
3. Provides visual output for the state of the system
4. Modular (so I can have just the controls we need, to keep it simple and unintimidating) or at least available with roughly the set of controls we need and not much more"
5. Has small displays (like the Stream Deck) so channel labels (etc) could be updated dynamically in software

Point 3 is an interesting one, and is where most options fall down. The two physical form factors that are common for adjust levels are rotary knobs, and faders (aka sliders). Faders are frankly a little easier to use than knobs, but both are acceptable. The simple version for both of these assumes that it has complete control over the value being adjusted. A fader's value is simply the vertical position. Simple knobs often have line or other indications of the current value, and hard stops at the end of the range (i.e. if you turn them to the maximum or minimum value, you can't physically turn them any further). Likewise, simple buttons used for muting are usually pressed or not, on a toggle basis.

All of these simple controls are inappropriate for the system I want to build, because changes from other parts of the system (e.g. my audio mixer app, or the full service presentation app, or the X-Air application that comes with XR mixers) couldn't be shown on the physical control surface: anyone looking at the control surface would get the wrong impression of the current state.

However, there are more flexible versions of each control:

• There are knobs which physically allow you to keep turning them forever, but which have software-controlled rings of lights around them to show the current logical position.
• There are motorized faders, whose position can be adjusted by software
• There are buttons that always come back up (like keys on a keyboard) but which have lights to indicate whether they're logically on" or off".

If I had unlimited budget, I'd probably go with motorized faders (although it's possible that they'd be a bit disconcerting at first, moving around on their own). They tend to be only available on expensive control surfaces though - often on systems which do far more than I actually want them to, with rather more controls than I want. The X-Touch Compact is probably the closest I've found, but it's overkill in terms of the number of controls, and costs more than I want to spent on this part of the system.

Just to be clear: I have nothing against control surfaces which don't meet my criteria. What I'm building is absolutely not the typical use case. I'm sure all the products I've looked at are highly suitable for their target audiences. I suspect that most people using audio mixers either as a hobby or professionally are tech savvy and don't mind ignoring controls they don't happen to need right now. If you're already using a DAW (Digital Audio Workstation), the hardware complexity we're talking about is no big deal. But the target audience for my system is very, very different.

Enter the X-Touch Mini

Last week, I found the X-Touch Mini - also by Behringer, but I want to stress that this is pretty much coincidental. (I could use the X-Touch Mini to control non-Behringer mixers, or a non-Behringer controller for the XR16/XR18.) It's not quite perfect for our needs, but it's very close.

It consists of the following controls:

• 8 knobs without hard stops, and with light ring displays. These can also be pressed/released.
• A top row of 8 unlabeled buttons
• A bottom row of labeled buttons (MC, rewind, fast forward, loop, stop, play and record)
• One unmotorized fader
• Two layer" buttons

My intention is to use these as follows:

• Knobs will control the level of each individual channel, with the level being indicated by the light ring
• Unlabeled buttons will control muting, with the buttons for active (unmuted) channels lit
• The fader will control the main output volume (which should usually be at 0 dB)

That leaves the following aspects unused:

• The bottom row of buttons
• Pressing/releasing knobs
• The layer buttons

The fact that the fader isn't motorized is a minor inconvenience, but the fact that it won't represent the state of the system (unless the fader was the last thing to change it) is relatively insignificant compared with the state of the channels. We tend to tweak individual channels much more than the main volume... and if anyone does set the main volume from the X-Touch Mini, it's likely that they'll do so consistently for the whole event, so any jump" in volume would only happen once.

So, that's the physical nature of the device... how do we control it?

Standard mode and Mackie Control mode

One of the recurring themes I've found with audio equipment is that there are some really useful protocols that are woefully under-documented. That's often because different physical devices will interpret the protocol in slightly different ways to account for their control layout etc. I completely understand why it's tricky (and that writing documentation isn't particularly fun - I'm as guilty as anyone else of putting it off) but it's still frustrating. This also goes back to me not being a typical user, of course. I suspect that the vast majority of users can plug the X-Touch Mini into their computers, fire up their DAW and get straight to work with it, potentially configuring it within the DAW itself.

Still, between the user manual (which is generally okay) and useful pages scattered around the web (particularly this Stack Overflow answer) I've worked things out a lot more. The interface is entirely through MIDI messages (over USB). Fortunately, I already have a fair amount of experience in working with MIDI from C#, via my V-Drum Explorer project. The controller acts as both a MIDI output (for button presses etc) and a MIDI input (to receive light control messages and the like).

The X-Touch Mini has two different modes: standard" mode, and Mackie Control mode. That's what the MC on the bottom row of buttons means; that button is used to switch modes while it's starting up, but can be used for other things once it's running. The Mackie Control protocol (also known as Mackie Control Universal or MCU) is one of the somewhat-undocumented protocols in the audio world. (It may well be documented exhaustively across the web, but it's not like there's one obviously-authoritative source with all the details you might like which comes up with a simple search.)

In standard mode, the X-Touch Mini expects to be primarily in charge of the display" aspect of things. While you can change the button and knob lights through software, next time you do anything with that control it will reset itself. That's probably great for simple integrations, but makes it harder to use as a blank canvas" in the way that I want to. Standard mode is also where the layer buttons have meaning: there are two layers (layer A and layer B), effectively doubling the number of knobs/buttons, so you could handle 16 channels, channels 1-8 on layer A and channels 9-16 on layer B.

In Mackie Control mode, the software controls everything. The hardware doesn't even keep a notional track of the position of a knob - the messages are things like knob 1 moved clockwise with speed 5" etc. Very slightly annoyingly, although there are 13 lights in the light ring around each knob, only 11 are accessible within Mackie Control Mode - due to limitations of the protocol, as I understand it. But other than that, it's pretty much exactly what I want: direct control of everything, without the X-Touch Mini getting in the way by thinking it knows what I want it to do.

I've created a library which allows you to use the X-Touch Mini in both modes, in a reasonably straight-forward way. It doesn't try to abstract away the differences between the two modes, beyond the fact that both allow you to observe button presses, knob presses, and knob turns as events. There's potentially a little more I could do to push commonality up the stack a bit, but I suspect it would rarely be useful - I'd expect most apps to work in one mode or the other, but not both.

Interfacing with the XR16/XR18

This part was the easy bit. The audio mixer WPF app has a model of a channel" which allows you to send an update request, and provides information about the channel name, fader position, mute state, and even current audio level. All I had to do was translate MIDI output from the X-Touch Mini into changes to the channel model, and translate property changes on the channel model into changes to the light rings and button lights. The code for this, admittedly without any tests and very few comments, is under 200 lines in total (including using directives etc).

It's not always easy to imagine what this looks like in reality, so I've recorded a short demo video on YouTube. It shows the X-Touch Mini, along with X-Air and the WPF audio mixer app, all synchronized and working together beautifully. (I don't actually demonstrate the main volume fader on the video, but I promise it works... admittedly the values on the physical fader don't all align perfectly with the values on the mixer, but they're not far off... and the important 0 dB level does line up.)

One thing I show in the demo is how channels 3 and 4 form a stereo pair in the mixer. The X-Touch Mini code doesn't have any configuration telling it that at all, and yet the lights all work as you'd want them to. This is a pleasant quirk of the way that the lighting code is hooked up purely to the information provided by the mixer. When you press a button to unmute a channel, for example, that code sends a request to the mixer, but does not light the button. The light only comes on because the mixer then notifies everything that the channel has been unmuted. When you do anything with channels 3 or 4, the mixer notifies all listening applications about changes to both 3 and 4, and the X-Touch Mini just reacts accordingly to update the light ring or button. It makes things a lot simpler than having to try to keep an independent model of what the X-Touch Mini thinks" the mixer state is.

I was slightly concerned to start with that this aspect of the design would make it unresponsive when turning a knob: several MIDI events are generated, and if the latency between send request to mixer" and mixer notifies apps of change" was longer than the gap between the MIDI events, that would cause problems. Fortunately, that doesn't seem to be the case - the mixer responds very quickly, before the follow-up MIDI requests from the X-Touch for continued knob turning are sent.

Show me the code!

All the code for this is in my GitHub DemoCode repo, in the XTouchMini directory.

Unless you happen to have an X-Touch Mini, it probably won't be much use to you... but you may want to have a look at it anyway. I don't in any way promise that it's rock-solid, or particularly elegant... but it's a reasonable start, I think.

That's all for now... but I'm having so much fun with hardware integration projects that I wouldn't be surprised to find I'm writing more posts like this over the summer.