Receiving OSC from XR18

[Matt]

Hi all,

Has anyone got an example of how to receive OSC from an XR18 (or any other behringer X series mixer)?

I’m able to send a message to the mixer, no issue, but having trouble with getting the callback event to fire when the mixer sends a response

e.g. If I send “/-prefs/name” to the mixer, I receive a a response with the name of the mixer

However the OSC callback event does not fire

On OSCMessageReceived(m : OSCMessage) Matching “/-prefs/name”
Print(“osc!”)
End

Is this the right syntax for the callback?

[David-san]

There are lots of software tolls to monitor OSC here:

Network tool for OSC monitoring

Gig Performer has OSC support and that’s very nice! Starting to work with OSC often necessitates to monitor OSC messages like Gig Performer can do it for MIDI messages using its builtin MIDI monitor. Reading the GP forum, different software for OSC monitoring can be identified, among them: Protokol (for Windows, Mac, Linux, iOS & Android): Protokol | hexler.net (by the TouchOSC team) OSC Data Monitor (for Windows & Mac): OSC Data Monitor ⋆ Kasper Kamperman (see also the nice OSC video introdu…

I would suggest you to check what the XR18 is sending to you to make sure you are waiting for the right OSC address.

[dhj]

@Matt

Is this the right syntax for the callback?

Our OSC handler will not recognize the ‘-’ character — it only accepts letters (upper or lower) and numbers

[David-san]

@David-san

I would suggest you to check what the XR18 is sending to you

I just figured out that your screenshot probably already comes from a network analysis tool…

[Matt]

Ahh… that seems like a problem. Any reason for this, and can it be changed?

There are many resources that include the ‘-’ character in the OSC implementation for the X series mixers:

https://behringer.world/wiki/doku.php?id=x-air_osc

[Matt]

So I dug a little deeper, seems something strange is going on with the port numbers when sending OSC messages

I sent the same message four times from GP to the XR18 (192.168.0.31 port 10024):

You can see that the source port is changing each time a message is sent - very strange!

For Bi-Directional communication, the XR18 will send a message back to the Src Port where the OSC message originated from. If the Source port keeps changing every time the message is sent, then each response from the XR18 will arrive on a different port. GP only listens on one port, so the responses can never be received

[dhj]

@Matt

You can see that the source port is changing each time a message is sent - very strange!

It is really necessary to have a deep level of understanding of the protocols to use a low level tool like wireshark. I would encourage you to use one of the monitoring tools designed specifically to display incoming OSC messages without all the low-level information.

There is nothing whatsoever strange about the source port changing each time a message is sent out. That’s how the protocol works. It has nothing to do with the destination port to which the message is sent.

Edit: upon reading up on the Behringer system, it turns out they are defining source ports explicitly to allow explicit “Send/Response” messages. Normally UDP messages are one way, they don’t EXPECT a response and even if they do, the other end (e.g, Lemur, TouchOSC, etc) would define the required port.

[dhj]

@Matt

that seems like a problem. Any reason for this, and can it be changed?

We’ll have to see if this can be allowed for the next release

[Matt]

@dhj

@Matt

You can see that the source port is changing each time a message is sent - very strange!

It is really necessary to have a deep level of understanding of the protocols to use a low level tool like wireshark. I would encourage you to use one of the monitoring tools designed specifically to display incoming OSC messages without all the low-level information.

There is nothing whatsoever strange about the source port changing each time a message is sent out. That’s how the protocol works. It has nothing to do with the destination port to which the message is sent.

Well I’m not an expert, obvs, but I can try and explain more why this is an issue - and why it excludes all Behringer digital mixers from having bi-directional comms with GP.

A OSC message is sent to the mixer, in this case 192.168.0.30, port 10024

The mixer is listening on port 10024, receives the message , acts on it, and then responds to the message with another OSC message. How can the mixer know where to send the response message? The answer is that it sends the response message back to IP and Source Port defined in the original OSC message.

Now can you see why it’s an issue if the source port continually changes for each OSC message sent out by GP? GP can never act on the responses from the mixer because it’s listening on a specific port - and the response messages from the mixer are being sent to a continually changing port because the messages from GP are being sent with a continually changing Source Port in the UDP message.

Hope that helps explain more clearly what I think the issue is.

[Matt]

@dhj

We’ll have to see if this can be allowed for the next release

Great, thanks!

[dhj]

@Matt

and why it excludes all Behringer digital mixers from having bi-directional comms with GP

Well, I just did a quick search online to see what Behringer did and it turns out that the X32 did their own hack and because of it, they can’t interact with most OSC applications out there (sigh), not just GP.

UDP packets are generally one-way. There is no assumption of a response.

So most UDP (OSC is implemented with UDP) applications will use a random source port and an explicit destination port. If you look at applications like Lemur, Touch OSC, etc — they all define on what port they RECEIVE incoming messages.

GP could probably be modified to define an explicit source port and I’ll put this idea in our tracking system.

[Matt]

@dhj

GP could probably be modified to define an explicit source port and I’ll put this idea in our tracking system.

That would be great! The Behringer mixers are pretty popular with the ‘Weekend Warrior’ set, so being able to configure the send port would hopefully be an easy win - and maybe give GP a USP of being compatible out the box.

@dhj

Well, I just did a quick search online to see what Behringer did and it turns out that the X32 did their own hack and because of it, they can’t interact with most OSC applications out there (sigh), not just GP.

UDP packets are generally one-way. There is no assumption of a response.

Yes, Behringer’s approach was a bit ‘off piste’, but is actually a pretty neat way of keeping multiple clients in sync with the mixer state. Having a pub / sub type mechanism means any changes from one client are pushed out to the other clients, rather than each client continually polling the mixer for the current state - which I can’t imagine working very well.