OSC mixer control in C#

In some senses, this is a follow on from my post on VISCA camera control in C#. It's about another piece of hardware I've bought for my local church, and which I want to control via software. This time, it's an audio mixer.

Audio mixers: from hardware controls to software controls

The audio mixer we've got in the church building at the moment is a Mackie CFX 12. We've had it for a while, and it does the job really well. I have no complaints about its capabilities - but it's really intimidating for non-techie folks, with about 150 buttons/knobs/faders, most of which never need to be touched (and indeed shouldn't be touched).

I would like to get to a situation where the church stewards can use something incredibly simple that reflects the semantic change they want (we're singing a hymn", someone is reading a Bible passage", the preacher is starting the sermon" etc) and takes care of adjusting what's being projected onto the screen, what's happening with the sound, what the camera is pointing at, and what's being transmitted via Zoom.

I can't do that with the Mackie CFX 12 - I can't control it via software.

Enter the Behringer XR16 - a digital audio mixer. (There are plenty of other options available. This had good reviews, and at least signs of documentation.) Physically, this is just a bunch of inputs and outputs. The only controls on it are a headphone volume knob, and the power switch. Everything else is done via software. The X-Air application can control everything from a desktop, iOS or Android device, which is a good start... but that's still much too complicated. (Indeed, I find it rather intimidating myself.)

Open Sound Control

Fortunately, the XR16 (along with its siblings, the XR12 and XR18, and the product it was derived from, the X32) implement the Open Sound Control protocol, or OSC. They implement this over UDP, and once you've found some documentation, it's reasonably straightforward. Hat tip at this point to Patrick-Gilles Maillot for not only producing a mass of documentation and code for the X32, but also responding to an email asking whether he had any documentation for the X-Air series (XR-12/16/18)... the document he sent me was invaluable. (Behringer themselves responded to a tech support ticket with a brief but useful document too, which was encouraging.)

OSC consists of packets, each of which has an address such as /ch/01/mix/on" (the address for muting or unmuting the first input channel) and potentially parameters. For example, to find out whether channel 1 is currently muted, you send a packet consisting of just the address mentioned before. The mixer will respond with a packet with the same address, and a parameter value of 0 if the channel is muted, or 1 if it's not. If you want to change the value, you send a packet with the parameter. (This is a little like the Roland MIDI protocol for V-Drums - the same command is used to report state as to change state.)

You can also send a packet with an address of /xremote" to request that for the next 10 seconds, the mixer sends any data changes (e.g. made by other applications, or even the one sending it). Subscribing to volume meters is slightly trickier - there are indexer meter addresses (/meters/0", /meters/1" etc) which mean different things on different devices, and each response has a blob of data with multiple values in. (This is for efficiency: there are many, many meters to monitor, and you wouldn't want each of them sending a separate packet at 50ms intervals.)

OSC in .NET

The OscCore .NET package provided everything I needed in terms of parsing and formatting OSC packets, so it didn't take too long to write a prototype experimentation app in WPF.

The screenshot below shows effectively two halves of the UI: one for sending OSC packets manually and logging and packets received, and the other for putting together a crude user interface for more reasonable control. This shows just five inputs on the top, then six aux (mono) outputs and the main stereo output on the bottom.

This is the sort of thing a church steward would need, although the per aux output" volume control is probably unnecessary - along with the VU meters. I still need to work out exactly what the final application will need (bearing in mind that I'm hoping tweaks will be rare - most of the time the main" control aspect of the app will do everything), but it's easier to come up with designs when there's a working prototype.

One interesting aspect of this architecturally is that when a slider is changed in the app, the code currently just sends the command to change the value to the mixer. It doesn't update the in-memory value... it waits for the mixer to send back a this value has changed" packet, and that updates the in-memory value (which then updates the position of the slider on the screen). That obviously introduces a bit of lag - but the network and mixer latency is small enough that it isn't actually noticeable. I'm still not entirely sure it's the right decision, but it does give me more confidence that the change in value has actually made it to the mixer.

Conclusion

There's definitely more work to do in terms of design - I'd quite like to move all the Mixer and Channel model code into the core" library, and I'll probably do that before creating any production" applications... but for now, it's at least good enough to put on GitHub. So it's available in my democode repo. It's probably no use at all if you don't have an XR12/XR16/XR18 (although you could probably tweak it pretty easily for an X18).

But arguably the point of this post isn't to reach the one or two people who might find the code useful - it's to try to get across the joy of playing with a hobby project. So if you've got a fun project that you haven't made time for recently, why not dust it off and see what you want to do with it next?