OSC support for Behringer X-Air mixers

[mcallegari]

This is the continuation of a discussion started from here

Here's a Behringer wiki with the OSC usage and some unofficial documentation of the X32 OSC protocol
A command line software that supports the protocol and can be used in QLC+ via Script Functions.

@gmint
I've thought again about this and maybe there is hope to have something working with the current OSC implementation of QLC+.
Basically using feedbacks.
Now the X-Air allows a lot of commands and some of them are kind of complicated, but since you own one of those mixers, maybe you can tell us which ones could already be used out of the box.

First of all you should start with creating a new input profile. Set it to "OSC" type.
Begin the learning process and try to send some signals from the X-Air.
You should see the OSC paths in the name column, and a -weird- channel number in the channel column (that's basically a 16bit hash of the OSC path)

If this process works, then you can use those channel numbers and names to send feedbacks back to the X-Air.
Just set the OSC plugin to input & feedback and it will use the original OSC paths discovered in the input profile.

Please let me know how it goes.
If you are able to get something out of this, then supporting the X-Air "natively" will be just a matter of writing a rich input profile !

[gmint]

@mcallegari

OK, I read this and I thought to myself, "of course, that makes sense." Then I tried what you suggested and I quickly realized why it won't work this way (at least in my scenario).

If I would have been more clear in my video, it may have been apparent why this wouldn't work. There are actually a few different models of the X-Air mixers. There is an X-Air 32 which is a large mixer that looks very much like a standard mixer with hardware controls and such. However, the smaller siblings like the X-Air 18, 16, and 12 (I have the 18 and the 12) are much more akin to an audio interface with just inputs and outputs (no knobs or controls) where all of the control is handled via the X-Air software. This is PERFECT for my particular situation because I don't want most people to have any way to control the mixer, but what it means is that the X-Air software connects to the mixer and only sends OSC to the mixer. The software only connects when it finds the mixer so I can't (for example) point it at QLC+ and learn the commands that it's sending. If someone had an X-32, it might be possible to do what you're suggesting, but because of the way the software (both the X-Air software and the little X18_Command program that I'm using in conjunction with QLC+) negotiate a connection to the mixer before sending commands, I'm not sure how to get QLC+ in the middle of that communication.

Does that make sense?

[OddSocks]

Happy for you to tell me that I have no idea what I am talking about, but could you give QLC the same OSC address as the xair just to listen?

[mcallegari]

What OddSocks said
+
can you use the initialization sequence via Script and then start talking to the mixer as if QLC+ was the X-Air iPad app ?

[gmint]

What OddSocks said
+
can you use the initialization sequence via Script and then start talking to the mixer as if QLC+ was the X-Air iPad app ?

Isn't the "OSC address" really just the IP address? (I don't really have a great understanding of OSC) If so, having two devices on the same IP address really doesn't work (at least not for very long) in most environments. As far as using the script and such, the X-Air app really a two-way link (to provide live metering and such) and if the app loses connection to the device, it tries to reconnect or fails...

Just a side note regarding OSC. I really feel that the complexity of OSC has hampered the adoption of the protocol. It's very powerful, to be sure, but it's also quite a bit more complicated than MIDI and, given the choice, I'd almost always use MIDI for its simplicity. The only reason I'm really using OSC in this case instead of MIDI is that being connected to the network and the fact that I can send commands to the device from different computers is benefit in my particular situation. I mean, if you look at the protocol guide for the X-Air, it's CRAZY long and even with that, it takes some experimentation to get the commands exactly right. Unlike MIDI, the commands are so loosely defined (which is obviously what gives it the power) that it makes it much more challenging to work with.

[mcallegari]

George, can you please send me the project you used in the video ?
Either here or via email, as you prefer.
I'd like to have a look at your scripts and maybe come up with an input profile for you to test.

[gmint]

George, can you please send me the project you used in the video ?
Either here or via email, as you prefer.
I'd like to have a look at your scripts and maybe come up with an input profile for you to test.

Massimo, I'll be happy to do that just as long as you promise not to laugh at my rudimentary method of putting things together In all seriousness, in your email, you'll find a few things: 1) the QLC+ project file, 2) XAir-send.sh, and 3) a bunch of .txt files which are named with various commands. The only thing not in there which is required to make this work is the XR18_Command program, but you have the link to that. Just to give you a little bit of documentation, the way this works is that I call the XAir-send.sh with one of the .txt files as a parameter from QLC+. All of the .txt command files are really simple, just one or two lines most of the time that send a certain OSC command. I thought this would probably be a fairly straightforward (though perhaps not the most elegant) way of making this work.

Keep in mind that there's no OSC feedback right now so I have to kind of fake the way the toggle switches work but, by and large, it suits my needs and I think it's a pretty good starting point.

On another note, I have to tell you, I can't say that I really have a firm grasp on what functionality the Input Profiles provide. I'm sure I'll get a better handle on them as this discussion progresses, but I've never quite gotten why it would be preferable to setup an input profile as opposed to just using the generic mapping in most of the cases I've encountered.

[mcallegari]

And here's the profile !
I've added all 16 channels, either /.../mix/06 and /.../mix/fader. Also /rtn/aux is there.
Don't know what mix/06 means, but if you used it then I guess it's some sort of level control.

Please note that, at the moment, the QLC+ OSC plugin can only send float values, so there's no chance to have the integer mute/unmute commands that you sent me. I guess you can mute/unmute by setting a level to 0 or not 0.

Now, what are profiles useful for ?
In general, they help to quickly recognize a device and a channel, or the meaning of it.
It's easier to remember something like:
Input Universe - 1: KORG nanoKONTROL2
Input Channel - 2: Slider 2
than
Input Universe - 1: MIDI
Input Channel - 2: ?

Another example: if you use a 88 MIDI keyboard, you want to see "C#5" and not a meaningless number.
And again: the AKAI APC40 has 40 buttons and 16 knobs. I challenge you to remember the MIDI number of each one of them !

Also, input profile channel names can be customized, so for example one would want the names in their language or when using particular softwares, they might want to assign specific names to specific functionalities. I'm thinking about Ableton, Modul8, Traktor, etc..

In QLC+, all the input signals must be mapped to numbers to be represented as unique channels within a universe. If you look at the MIDI plugin documentation, the case has been solved by mapping the different signals (Notes, CC, PC, beats, etc) to a unique table of contiguous numbers.

OSC is a specific case. It has the concept of "path". A path is a string representing a "channel" or a widget (thinking about TouchOSC)
Paths can be anything you like, depending on how you design a OSC software or hardware.
In TouchOSC, the first part of the path represents the layout page, so you'll see paths like: /2/fader5 or /4/multifader1/4
As far as I can tell, the X-Air maps the mixer functions by name, with paths like /ch/01/mix/fader or /rtn/aux/mix/fader.

So, how did I resolved paths into QLC+ numbers ? By calculating a 16bit checksum of a string !
A purist might say this is a weak mechanism, cause you can "easily" run into collisions, but I think 65535 cases should be enough to avoid bad statistics.
When a OSC signal enters QLC+ the checksum is calculated, so you will see a number in the UI.
But the interesting thing is when a feedback goes out. Obviously OSC understand paths, not numbers, so I re-use the original OSC path !
This is absolutely not possible if you don't use an input profile (technically it would work only if the OSC path has entered QLC+ before cause it would be cached)

OK, I think I have written enough and your head is probably about to explode.

Long story short: use input profiles ! They're important and useful !

Please test the attached profile and let me know if it works.
Set the OSC plugin as input + feedback, with the X-Air IP address in the input line.
As I have written in the documentation:
Note: When patching a Input+Feedback line, the output IP/port you need to change are the ones in the 'Inputs' section. Just leave the 'Outputs' section as default.

In theory with a virtual console slider you should be able to control the level of one of the mixer's channels !
You will have to select the input channel of the VC slider manually, using my profile.

[gmint]

And here's the profile !
I've added all 16 channels, either /.../mix/06 and /.../mix/fader. Also /rtn/aux is there.
Don't know what mix/06 means, but if you used it then I guess it's some sort of level control.

The /rtn/aux is a mix bus. I use it to control whether a channel is sent to the booth monitor or not.

Please note that, at the moment, the QLC+ OSC plugin can only send float values, so there's no chance to have the integer mute/unmute commands that you sent me. I guess you can mute/unmute by setting a level to 0 or not 0.

Yes, that works as well. I actually switched to using the levels instead of the mute for the most part.

Now, what are profiles useful for ?
In general, they help to quickly recognize a device and a channel, or the meaning of it.
It's easier to remember something like:
Input Universe - 1: KORG nanoKONTROL2
Input Channel - 2: Slider 2
than
Input Universe - 1: MIDI
Input Channel - 2: ?

Another example: if you use a 88 MIDI keyboard, you want to see "C#5" and not a meaningless number.
And again: the AKAI APC40 has 40 buttons and 16 knobs. I challenge you to remember the MIDI number of each one of them !

Also, input profile channel names can be customized, so for example one would want the names in their language or when using particular softwares, they might want to assign specific names to specific functionalities. I'm thinking about Ableton, Modul8, Traktor, etc..

That would be consistent with my understanding. I guess it's just never seemed like it was worth the trouble to setup an input profile but that's probably because I generally try to map my hardware controllers in a way that is mirrored by the layout in QLC+. Also, it's probably because I generally just learn the commands instead of setting them from the QLC+ interface.

In QLC+, all the input signals must be mapped to numbers to be represented as unique channels within a universe. If you look at the MIDI plugin documentation, the case has been solved by mapping the different signals (Notes, CC, PC, beats, etc) to a unique table of contiguous numbers.

OSC is a specific case. It has the concept of "path". A path is a string representing a "channel" or a widget (thinking about TouchOSC)
Paths can be anything you like, depending on how you design a OSC software or hardware.
In TouchOSC, the first part of the path represents the layout page, so you'll see paths like: /2/fader5 or /4/multifader1/4
As far as I can tell, the X-Air maps the mixer functions by name, with paths like /ch/01/mix/fader or /rtn/aux/mix/fader.

So, how did I resolved paths into QLC+ numbers ? By calculating a 16bit checksum of a string !
A purist might say this is a weak mechanism, cause you can "easily" run into collisions, but I think 65535 cases should be enough to avoid bad statistics.
When a OSC signal enters QLC+ the checksum is calculated, so you will see a number in the UI.
But the interesting thing is when a feedback goes out. Obviously OSC understand paths, not numbers, so I re-use the original OSC path !
This is absolutely not possible if you don't use an input profile (technically it would work only if the OSC path has entered QLC+ before cause it would be cached)

OK, I think I have written enough and your head is probably about to explode.

Gotcah! I think that makes sense.

Please test the attached profile and let me know if it works.
Set the OSC plugin as input + feedback, with the X-Air IP address in the input line.
As I have written in the documentation:
Note: When patching a Input+Feedback line, the output IP/port you need to change are the ones in the 'Inputs' section. Just leave the 'Outputs' section as default.

In theory with a virtual console slider you should be able to control the level of one of the mixer's channels !
You will have to select the input channel of the VC slider manually, using my profile.

I tried it but I didn't have any luck. I've not set this up before so I'm probably doing something wrong so maybe you can walk me through a few things. As far as the inputs, it seems as if those are automatically filled with the IP address(es) of the machine that QLC+ is running on. Am I missing something? Because I'm only able to change the output IP address. I did try setting the output IP address to the IP address of the X-Air but still, I got nothing.

Also, just to make sure I'm doing this correctly, should I just be setting up a fader and selecting the correct output channel? It's not necessary to have anything set for the actual function of the fader, is it?

Finally, I did want to just make one comment which, I think I've made elsewhere, but it is probably more relevant here (but don't get me wrong, I think that if we can get this working it will be a great first step) but it seems to me that it would be really nice if QLC+ could send arbitrary OSC/MIDI/etc. commands in the same way as it sends DMX. I'm thinking like scenes but for MIDI/OSC. From what I understand this is somewhat possible now, but it seems that it's not as flexible as it could be. For example, I have this little Behringer CMD-DC1 Controller that I use with QLC+ and while it works fine, it requires that a specific value be fed back to the controller to get the buttons to blink or change color (to indicate an active state, for example). That's difficult, if not impossible, to do with QLC+ alone (I'm working on using MIDI Pipe or something like that to achieve that in the meantime). Just my $0.02.

In any case, let me know and I'll see if I can make it work.

[mcallegari]

I tried it but I didn't have any luck. I've not set this up before so I'm probably doing something wrong so maybe you can walk me through a few things. As far as the inputs, it seems as if those are automatically filled with the IP address(es) of the machine that QLC+ is running on. Am I missing something? Because I'm only able to change the output IP address. I did try setting the output IP address to the IP address of the X-Air but still, I got nothing.

Here's a screenshot of where you need to put the X-Air IP.
Also you need to know the port where the X-Air receives OSC data. [EDIT] The output port to set should be 10024
Obviously your computer must be in the same network of the X-Air

Also, just to make sure I'm doing this correctly, should I just be setting up a fader and selecting the correct output channel? It's not necessary to have anything set for the actual function of the fader, is it?

Yes. Here's another screenshot.
Create a slider, open the configuration dialog, click on "Choose" and select a X-Air channel. Leave all the rest to default.

[Phil Smith]

And here's the profile !
I've added all 16 channels, either /.../mix/06 and /.../mix/fader. Also /rtn/aux is there.
Don't know what mix/06 means, but if you used it then I guess it's some sort of level control.

Just had a read through again, Im not sure how you derived these particular commands. /ch/01/mix/06 wont do anything as its not the full command. The Xair has 10 mix busses available, 1-6 are busses that are normally assigned to the 6 XLR aux outs on the front (monitors), mix 7-10 are the mono sends for the fx buses.
The command /ch/01/mix/06/level would let you adjust the amount of channel 1 going to mix (monitor) 6.
/rtn/aux/mix/fader is used for the stereo channels 17-18, its not a mix bus. (Imagine it being called /ch/17/mix/fader)
Hope this helps.

[gmint]

@mcallegari

(I know this isn't probably the best place for this, so my apologies, but it's kind of an extension of our earlier conversation so I thought I would continue it here)

I've been testing 4.10 with the custom MIDI feedback and, as promised, it works great to drive my Behringer CMD DC-1 controllers. It's such a relief to finally have blue lights that flash orange instead of just solid orange lights That said, I'm wondering if the custom MIDI feedback might be a good fit for inclusion in the input profiles. Maybe it's just me, but it seems like this is the kind of thing that would naturally go in the input profiles, potentially save a lot of work for people, and make things function just a little nicer out-of-the-box so to speak. I understand that there could potentially be different desired settings for different controllers (like the AKAI) but even having one default configuration that enabled MIDI feedback in a useful way would probably be really nice for a lot of users.

Just my $0.02.

[janosvitok]

It's planned, but there was no time for it in this release.

[mcallegari]

It's planned, but there was no time for it in this release.

Well, actually no
It was your idea to have feedbacks per-button, so every button could have a different behaviour, and I liked the idea.
At this point, setting feedback values in the input profiles would break backward compatibility and I'm pretty sure our choice of values will not be OK for everyone.

I believe what we have right now is a very flexible solution, however it requires to customize each single feedback.
Perhaps what we can do is setting "base" values in the input profiles, and "override" them with the custom feedback selection. (and save into project)

[gmint]

I believe what we have right now is a very flexible solution, however it requires to customize each single feedback.
Perhaps what we can do is setting "base" values in the input profiles, and "override" them with the custom feedback selection. (and save into project)

That seems like it would be the best of both worlds. I'm not complaining, but it was definitely tedious to go through and setup feedback for every button. It wasn't too bad for the project I use with the CMD DC-1 but I'd hate to have to go through the process for the project that I use with my Maschine controller...

[mcallegari]

Back on the topic....you haven't updated us with news about what you're able to do with the X-Air now that we figured out about OSC messages !

Any exciting feature to share ?

[gmint]

Back on the topic....you haven't updated us with news about what you're able to do with the X-Air now that we figured out about OSC messages !

Any exciting feature to share ?

@macallegari

Unfortunately, I just haven't had the time to play with it. I purchased another small bar (quite unexpectedly) and I've been super busy with that. Also, I'm off to LDI tomorrow so I'll be out of town for the rest of the week! Soon though...

[mcallegari]

Also, I'm off to LDI tomorrow so I'll be out of town for the rest of the week! Soon though...

Don't forget to show QLC+ to everyone you meet there !

[gmint]

Also, I'm off to LDI tomorrow so I'll be out of town for the rest of the week! Soon though...

Don't forget to show QLC+ to everyone you meet there !

I definitely dropped your name a few times!

[Phil Smith]

Hi, I've stumbled across your site whilst googling for OSC things and the XR18. Ive never used your software before but Ive had a little play and got some things working.
I added a few commands to your profile, Im afraid I didnt understand the assigned checksum numbers bit, I just 1,2,3,4 and it worked. Ive attached a file with a virtual console that has channel 1 fader, pan and mute and also a DCA 1 fader. I also had trouble getting a button (mute) to work properly, the only way I managed it was to use the blackout style, Im sure this is just my ignorance of your software and you could adjust it to use a normal button.
Ive attached my modded profile and the file with my virtual console, I hope it helps someone on their way.

https://dl.dropboxusercontent.com/u/730 ... R18QLC.zip

I would imagine bidirectional communication is possible with some tweaking. If you are interested in this, you need to send this OSC command /xremotenfb to subscribe to updates from other clients. This command must be refreshed every ten seconds.