absolutely going mad! > osc udp
hi folks,
i'm completely helpless and need an(y) advice by whoever has a clue.
i've been struggling with getting a two-way connection to the new behringer x32 digital mixing console
which states (and has proven) to be able to understand osc. the one way works very fine: i can control parameters via udp (on port 10023). the other way is: numb! no chance — i get nothing back from the mixer.
the osc documentation states that sending the console an "/xcontrol" command (other sources say "/xremote" is necessary) will dump out its current values. furthermore it is said that sending an empty path (without a value) will return the value for this given path (see patch). nothing (!) works.
anybody? am i doing something very basic wrong here?
i'd be so gracious!
this is not very helpful, for me at least:
http://www.behringer.com/assets/X32_OSC_Remote_Protocol.pdf
You can't send and receive on the same port as far as I know, try changing your receive port to something else like 9000
several sources say, that it sends back on the same port as you request the dumpout (this sounds like a tongue-breaker! :))
if i use wireshark (mac application to "sniff" my connections), i get the impression that my computer *more or less randomly*
receives on some strange ports such as 60302 etc. i barely have an idea about networking.
got another hint? is there a chance that i need to convert my request-messages to binary or something? no idea :S
i think i'm not getting the whole port thing which i suppose is the actual problem.
my mixer runs (?) on port 10023. if i use it's native mac-application/editor to connect to it and
change settings, my changes are sent out on this port, but received on another. how do i know (and furthermore set up)
max to receive on the port the console sends information back from (as this port seems to be different every time :S)
If I am using an OSC app on an iPad for example I will set it up like this, but I don't know enough to say how that relates to your mixer:
iPad outgoing port: 8000
iPad incoming port: 9000
Max outgoing port: 9000
Max incoming port: 8000
I would have thought you have options to choose what input and output ports you use on your mixer, but I really don't know. Does it have its own forum? Maybe look there?
thanks again, luke!
the mixer has some forums (as it's pretty much boosted in popularity), but nothing's of help,
cause (strangely.. or understandably) nobody seems to have attempted a connection with max.
unfortunately i can't set up it's outgoing port. it's incoming port is 10023 as mentioned.
i think i don't understand the udp-thing. what i suppose i'd need to find out is the port that max
receives information back when it sends them out. does that make sense? do you know anything about this?
You define the udp ports in the simplest way.
Send from Max (anything)
udpsend 9001 (send out of port 9001)
recieve into max
udpreceive 9002 (receive on port 9002)
Make a simple test.
Create a simulation in max with the right port numbers and just send a basic message through.
Once you have that working then try it with the mixer.
The tutorial for the object states it all very clearly.
i think i've gotten that far. sending and then receiving on one and the same port within max works fine. (udpsend 9000 -> udpreceive 9000).
the mixer's osc manual says it receives on port 10023. works! furthermore it says, that it sends requests back on the senders port.
requests to the mixer are apparently stated by non-value path-messages (e.g. "/channel/01" instead of "/channel/01 1000") or the message "/xremote". but the port these messages "come back" at seems to be random. anyhow other (non-max) software is obviously able to receive changes within the mixers parameters.
I had a look at the x32 forum and there seem to be others having this problem, it seems to be a strange OSC implementation on Behringer's part:
On the DAWOSC forum someone explains it well:
http://dawosc.forumotion.com/t72p15-connecting-to-hardware-mixer
I know Siska Adam has some UDP objects in the sadam library, maybe see if they can help.
thanks for all your effort, luke.
i think i might just need to give up :( i've looked into adam's udp objects but they appear to be of no help -
it still seems necessary to (obviously) listen on one explicit port. to sum up what i've learned / suppose:
1) i send a request to the behringer x32's port 10023
2) behringer gets my port (i am sending from) and sends the requested data back to this port
3) i cant find out which port i am sending (receiving) through as it appears to be random.
is this correct? any last words :) ?
i've done some more wiretapping.. it appears, that max receives information back on *some* (own, randomly assigned) port.this is most probably the port that the x32 sends the data back to - the port i would have to udpreceive to.
is there any way to read out max's "source port" - in other words its own port? does that even make sense in terms of networking?
A computer sending to itself with UDP is always 127.0.0.1.
Eg udpsend 127.0.0.1. I use this to send from ableton max for live to another max patch. Hope that makes sense.
You have to define the port, max can't do that randomly.
Maybe post a stripped down version of your patch with just the basic data flow and udp objects. maybe you made a simple error with defining the arguments.
Eg. udpreceive doesn't need an ip address !
@Andro, I read through some stuff on a couple of forums and this isn't a normal OSC setup by the look of it. The x32 seems to do some weird stuff in the way it handles OSC as it won't let you decide on an output port, I quote:
"x32 listens on port 10023 and responds to the port that requested /xremote command. That is what causes problem to all osc programs (both ios and android).
Let me try to explain the "random port" thing.
When you send a UDP message, it goes from IP1:PORT1 to IP2:PORT2. You specify IP2 and PORT2 (that is your outgoing setting). IP1 is your client's IP. Now PORT1 is the problem. Normally you don't care what it is and usually it is randomly assigned by OS or socket library."
So it seems this is the problem, it is sending back to an originating random port rather than letting you specify one so you don't know what to set your UDPreceive to. Max won't let you specify an outgoing port (you specify the host port on UDPsend) and it shouldn't have to really as it works like every other OSC app.
udpreceive doesn’t need an ip address
but it still needs a port number !
@op : what are the applications that are designed to communicate wiht the Behringer and which work naturally with it ? you could find by there which port number is the correct one. anyway don't give up :) are you on osx ? there is "network utility.app" (or something called close to that) that might help you see what's going on
luke got it pretty straight.
port and ip of the behringer are clear — the ip you define and the port is always (!) 10023.
to repeat: the problem is the senders (max's) port.
sender --> states request from port x to port 10023
x32 --> send back to the senders port x.
software that works well:
> x32 sniffer (x32 scribbler -- might even be opensource, so if anybody'd like to dig into that; i have no clue of "real" programming :))
> official behringer x32-edit software (mac and win)
i'm on a mac. i use wireshark to "sniff" my outgoing connections (port). this clearly displays, that my port (from which is send requests to the x32) is always random :/
Hi Ben,
I'm on the same problem except I'm using processing and the OSCP5 library to communicate. I can send osc messages ot the desk and control it but not receive anything back. I also used wireshark to show it was replying with any changes but to random ports.
The unofficial X32 OSC protocol says "The server replies on the UDP port specified by the client when establishing communication". Therefore, wouldn't you need to establish a communication first so the server/desk knows which port to reply on. I.e. send a "/server/connect" message? The X32 edit app requires you to do this before you can do anything to the desk which is leading me to think this may be the issue.
hey
I don't speak english very well, but i try...
I made a Max object called UdpSend_LocalPort with java, i modified the properties of UdpSend to know which Local port was used.
Try it to communicate with X32, say I if that works for you.
I am under Windows 7, max 6.1 32bit
see you
Jeannick
hei jeannick – incredible!!!
i totally want to try it, but unfortunately the "mxj UdpSend_LocalPort" is missing the code / external (i guess you'll have to upload that mxj class / code separately in order for me to place it into my root directory?).
thanks so much! can't wait for your reply!
hey
i can't post here the .class and .java or .rar with all code you need, it doesn't work
I can email you all, if you post me your adress or tell how I can do...
jeannick
thanks so much!!
it's mail (-at-) bcbas.com
ok
it's done
after having received an e-mail yesterday with someone asking me if i had found a solution to this problem from a year ago – yes, i have. it works like a charme and here it is:
the *only* way i got a 2-way communication going with the X32 console was to use the SADAM externals
(sadam.udpReceiver, sadam.udpClient and sadam.udpSender). if you find this helping you, do consider a donation for siska ádám – these are some great tools.
Hey Benny,
Can you please post an example with some x32 OSC lines included, of maybe a setup that is working for you right now.
I tried using your previous patch but can't get it to work!!
I am using 64 bit, are you using AL 32 bit?
Your help will be greatly appreciated, thanks.
hello piano4me,
i am running max 7.2.4 64 bit (MAC OS) and everything is working fine for me (and has been, throughout former versions and also on 32 bit).
are you sure you have set up the IP and port of your X32 correctly? mind the messagebox that says "dst_port 10023" – you'll have to initialise / click this, when loading the patch.
i've updated the patch with a few more notes... see if this helps you
Hi!
I'm trying to get this to work with the xair-18. Unfortunately i cant find the SADAM externals.
The page http://www.sadam.hu/ it douse't work any more. Can someone sent it to me?....
my email is fivefresh(ad)gmail.com
Thank you!!!
This is great!!!! Benny with this patch it is possible to read the LED meters, such as those shown in the official behringer application? ?
if i recall correctly (and/or if it's in the behringer documentation), then yes – you can. yet, some of the data is formated strangely (i think in blobs), so you'll need to do some parsing.
for sake of completion, here's the other post on setting up sadams externals and here's a link to an inofficial x32 osc documentation
good luck on getting it going! :)
Hey Benniy,
Your patch works absolutely great. I spend hours yesterday searching for a hint how to get bi-directional communication for my MR18 / similar to XR18 working until I searched the forums here.
Cheers
Len
Here's my solution for Windows using Sadam to pass the OSC messages and ODot to process the returned messages but I suspect that you've worked this out already! Not sure if MacOS uses 127.0.01 as an internal LocalHost address. (It should work with all the Behringer X-Air mixers - XR12/XR16/XR18/X32/M32 etc.)
.png)
Incidentally, the RESET receiver is fed by a loadbang object so that Sadam is configured and the metro starts running as soon as the patcher is loaded. You need to keep sending the /xremote command to the mixer at regular intervals (most say every 5-10 seconds depending on the mixer type) to ensure that the mixer keeps sending out live updates.
hey folks,
i't has been a while and recently got back to my mr18. Did anyone of you manage to subscribe to the level meters? It is the last mystery i haven't solved yet and it is driving me crazy.
I found the x-Air Remote Protocol documentation which provides the following:
meter subscriptions are used to request a set of meter values,e.g.:
/meters ,si “/meters/0” 8 (meterID ,oscvalues <string> <integer>) Binary OSC message:
2f 6d 65 74 65 72 73 00 2c 73 69 00 2f 6d 65 74 ; /meters.,si./met
65 72 73 2f 30 00 00 00 00 00 00 08 ; ers/0.......... returns 8 channel meters (pre-fader l/r, gate and comp gain reduction, post-fader l/r meters, gate key, comp key) of channel 9:
If I send this message to the udp-send object i get the following error notification
udpsend: osc unrecognized argument type
Kind Regards,
Len
I've not mastered this bit yet either but by all accounts it supposed to be fairly straightforward! What I can't figure out from your post is which message is giving you the error? You appear the have several message types strung together and I'm not at all familiar with what {ers/0} is supposed to be doing in there.
For example, all you should need to send is:
/meters/0 8
and then the server should reply with the level values at 50ms intervals, or thereabouts.
I think what follows in the original document is misformatted and should be on separate lines.
Don't forget that the server will only send data for about 10s before you need to send the command again to keep it active. Also, you need to keep sending /xremote every 5-10s to keep the link alive.
Ok, I've done a bit of digging on this. If if send a {/meters/0} request, the levels server does indeed appear to send back the meter levels as requested. However, the data returned is in a pure binary blob and, as such, [udpreceive] will not be able to decode it. I dont know if you could get the full-packet option to work but I couldn't!
However, I could see something of what was being returned by using the Sadam library [sadam.udpclient] object as that outputs the pure binary data.
You can check this few sources :
https://github.com/Jbithell/xr-meters
or
https://sites.google.com/site/patrickmaillot/x32
https://github.com/pmaillot/X32-Behringer
maybe you can get some ideas from there.
Thanks to both of you!
I just found out by accident. Sending "/meters/0" does not trigger any response. However when i send "/meters/0 /meters/0" then the mixer is sending data.
Thank you guys for all your help.
Kind regards
Len
That's interesting! Wierd but interesting. I'm also not sure that the server only sends for 10s either, as suggested in the X-32 documentation - once I started the server, I couldn't switch it off!!! 😂🤣😂 Unless I power cycled the mixer! Perhaps just sending "/meters" with no argument will do that - or it might send an error? Who knows?
All I know is that the documentation is not really all that helpful - it's ok as a reminder for somebody who already knows how it works but not thorough enough for a complete novice to understand.
I agree. The documentation could be much better. Also the implementation of returning messages to the requesters port os a strange and annoying detail.