absolutely going mad! > osc udp
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:
----------begin_max5_patcher---------- 1108.3oc0YtriaaCEFds8SAiV0Et1h2zkftoIcRP1jEo.EEHnX.sEsGkHIZP Q63jfruOC8wqOIkjRxVyDKYoL1xS2HOhTh7vO8etPNec7Hm4hc7bGvyAuGLZ zWGOZjsISCiJuejSJa2hDVt8wbR444rUbmIE8o36T11WKjJ.z0Egq5RrQkvU pOulWL9NNf+prqkhLUd7Wrc.QScKaNaSZbl9cryDprw0L0h6hyVcqjuPULRg Tr9c.XHw7iWf4JTec+3GGYsIw7O7yHhSsIMikZmTmeUFyRbNLuEFqchglF+1 3wlKS5HUx3eROYeGTTfXv7F4QblxYBvYNKaU+PCrYzfo9FZPvdSoZBgLWQtM fFXeQC5G.MKDoobyJ8Ar44+D3c27xadye7l29Zmir3MVcUyxUyMM41abTpTP dVp.IE2Edbd.C6KObOi73e+6+A76271eSiCPu4wZIOWOnLUrHqtZ.AsKXrcc 6VdY+ZumhJD0NBPs1pMJFbMo3u.xDJi4+riBwZdTcFhPnucASC7eTTD5FZGG BIv3UBKnYSNmP+g.iMD2RpGVNX1xcRU1LW+Yow6lsjEwkMGaex4O9dEnv9sB J50LJ1kPu4RQV8laviTugrC.A1I8F4Jp2VKiOv1GYFvv.bsUMlz5hFcEWzah zBfE73s7yZcSmNaHlTjMz0qU1.GhBmZ1u5SB4Gye14xohFPspB+GmOEMnvkJ vlW8TtTt+eMSXOwgGzqC3XPpKnosmzqbYmxeqQMleAMnmVi0R1OhmUb4QK8R 8aa6MzgvIsQntSxSEJ94mjP3YgjEUp5grHj1JHIWWPtPOqRQxkeuyDMS04E8 bsDl50FSvWwsN+kT1ZfqdE5at5dXa7cEMMDMidxs4fCIFBE1pbIrkrifWHRh t3.RW9f10IB.CQSgdAS00PLEc+JINOmkfOzdJBPebaQ2wW05GYK9nVljlu5x 6.URkxpy8QsBE30zCJAH4aGlcrUAEbPgGTqkEgGhMr0.Txsa0XI3LTO.bJMj BC76oWEwFYZeIjEDC1vgofCGBAThdOHSipMjaYx8y0204QURKSDL0AP0Pdcj tXFH0CoCmD3ZBpPHEUk+ienTXLtgAptMTerpeBn6Ojk0LodAq3xa4Yr4I75u vCDiksly1xitkoTx34aT7C+UdIoKQsglIa3hkUMW0d8IMQjspQheumL+Ng7f P3U+IveVvwdtpuOviz2lrXUt5yEqR2h9sRlpeJ0OVTpMmrG9uHv94vz98EU4 hMxEUphpCeGb3KRDOWEms+Cx6OrQyZOzcwQQba+UAghhyMeRhZNoQmsGXGrG 7.aOvSYOgCl8D1E9fFN9.6h8XN.vmT1CZvrGZWjyjAybHOsLG7SLyIrqAefC i8zIwLd3BF52A6Ib.C9bQ0OE4VYqWukKyKGSqonKM6CBo4VuI1aiyJt0lI2Q WReb0yaK8zgI0kFoz0EsQVTTvt.Omwl44ai+Ows8TXC -----------end_max5_patcher-----------
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:
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 :) ?
- This reply was modified 10 months by benniy.
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 :/
"mad! > osc udp"
i never saw this usage of ‘>’ before. it immediately clicked as ‘mad OVER osc udp’. so instinctual. yet i’d think for ‘over’ it might be:
"mad! / osc udp"
but then that might look like an ‘or’!
anyways, i learned something new today just from the title :)
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.
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
----------begin_max5_patcher---------- 2364.3oc2bs0aaajE9YWf9eXfPenKfp8bi2xaAAK1VfzlhXu.KPcQ.k3XYlH RJPR4nrEKv9Sa+osyMIQpKjijFRwjXDIYIZxy7ctNemC0e88e2MiljshULB7 Jve.t4l+h+N2HeOw6by523lQIgqlNOrPdfiRYeNaxGGMV+YkrUkx2OGjvJJt mkFs4ydJKsLMLgI+7WmGGNeyGktLINcNqTdNgqe23H4gxO++jCZywtHrb5yw oy9PNaZoRXQN2BGyeDJeBJeByeD7mUt.YKKWeEPUEoh3+sTjP3a2bkUGa4WV vTWfQi.+o7i9Oe+2Idl+zXKAQumUtLO0NfDrIPB6qQoup.ohKAjPG.jn9MBR dRbwiXJJAOFJ0QHwY4QcPbv0DiE30CGDq1vYr8Ah6JJCKWVbxn.9Pn.sITfn Bn3KexkJw.hAdLKxYErTtTFmkdbWI2stRSlMMadVtNZl7hJd.pe01K3g74Nz Usxhfhkml.0hve6hv5Vnu6927S4bIjAta5y2AQ2kDu5tmBiX41whMvDOWsEq OsMKV7oGeab2Di6cKXo2msLM5MbIIOatUPKOrAnkqqxDCQZCsHmGZMVZU7Pb B6gvYWB1ULOtlcz7rvR9kbwxxZ.Pqvx1n+aVDaWCGOPHU9HlBWmB87iArHLm qRKY4efkFNYNqVzyyv+1sh6cMA7rw5oYII7Kz9FpumMkE+BCnCMW.JyCSKRh KKYQfrWX4fPPJq7yY4eB.9QvS4YIf+EACdJKGvVElrXN6us4rNONkMka0Wtm 40YGfvowhDw5v4pb6XnH9KvAYPNMyhmS1ZH8T9rIxyvsPizdNJqLGrJ7LpaT e2+2e3ge429G2amnwjFAaHrheCJvY655Rv5mBmxLRAHVyURoB2jMEdq6NoTO Uc05sYTcMYec0uFtZqaVXNCTvD5G9RMBDlFADxmxkq7Y1FmtvB.ObK20qLaO GOPG54Q7LwXXimm+vwySESnic73QIixR3RKO937rogyAKxxKABsDWxhpDOMC DVBdNqn7vJKrUTVtlnrvHUFEG4uQbutJKc8J5rwDTm56UvJOY0zEoPbLQgPH UUHXzvPgnkFmNWgHUEctlfZjl.V0XbnnIP6KTcilPjvQf3fIeADu.DFEwErB 6f+HiBM4AsZUEVA+0rDXmxBN1NE4XNvRHcykuo4+RQcfKz96kdRX5rKc+zSV VVlkZ9ZFiLYM6rY0ZH+nGdscAqqix70ii9cQTvWI7DvjGGYEJvvTCHJfBqUH e2SBF7VGJB44NtBcXWJSXJ6Xpt9chaGRE1zm41.L63o1HQNtpM9SbMzS873w IVjKP8TWXW+dY8wuUTxkv.2Nl0Nlvus1m20Rl0Mu+zFI7kavCQAtHKw5qa0p Ap41Ze02FEmJtjcTeF0KK2Aj5yMfGvxW7JhOkfnVSG5XQc3w6E4FkHxJ8hz0 fjJNJ1J87FVsh73MdZmtZ.9AjUr0Q9FXq6o15A0oO6BE7VedLInuUCJoIdg1 k1yKSWDN8SfB9OwVIKriQYgIU4hGcpYgIFzMkKLE7wvKAU8EeIYhkZ9jC0Dz RsMZ+VQKzoiVcS02aSzY2RvQlDsjppUgpwquMS1oWcNHXWVvhj8BT.9Vjne3 2hf1olETirfSCpUxosTiFrSJn82D0NrczQ5oE1slRTibdns4rcMkWwc5poDr iURON5mEtSuptCkshLhLHxHwq2ImnCbozyoCxMnCqKh6NAl.lXkj7MNNN5.D ph7nt1mVBMkDq4Q7R4b6X.17rvH00vF8L2.DS0ZK2NX7LuTHpLa1r4rSft0l MP1kaYCWtm2b0bvs13iINDi1Zipp6Vbi0Cww5csu9wNvnjuLyy.NPHzNbs3Y fhRUytGZ3YWdz8.FsP1rPYqbUk7I9mU7jw9sOO5qItgNjFh3vnvja4HidTtx sHlfZzeWu8ELd2trXudJMOtnSoo9tU4rjrRlcb5LvmSmRvysm47w7.iFL9wA UhJ541kUhdWb5SY1Q4z7vyhppcnecOW3t6sH5u9wZBsGqqpeH1O10AD9e+W0 OO93X0KrydebLYuOpJrIAvuNsBcqx2icn8wHyvmls+3gRj+6PKrpZEnIZEXk gKjbQk0NYdb5mN3dO2WL2YSpAHhG1Y7QdUS5MsGiYE7tYvz5vJdKtj9ScvhU Lgf5.C6OUGT+1xjIV51lownHZcW8stXRQYwyRy3ml4wS+j46B6XUxc9AXpxB Pmw.okZyGwjVhpucS7UEXLTaI5EUakI3fm9dtySBDDrsRqgo8e6NIUysoVJc AKrh6LTNVJFI1ZLwBxRAaIRG743xmAu8cu40uE76u68OrWerN77lWaEdYij9 AcMZLoptoP5mzC+ME0Cz7RcnAPrMq2QSJft36Zqktf.jb8crkR2+le6We8C1 I8oICMnas6e1g+8ZdxpOB9mQKDNRe37GFsCBWlbyXpMMbpVH0ggKGqtcet9g DfMy9d7N+2vXfjZw.uvZDOZLvWhYetHaY9T6jnxy.1505LEsnCm70KBSYmxH l1LS8PEYc5IPp08zz9P2mKtYmYxqOdyQmjEUedD1IVrumXRCFevWUyp8X7cT Q7c71vo81+NdMjp5Uk519B6oMl5CoYO9aBrWO5CZvWduJe0Q+VtgSBb91wxO npoub9Ft5neyjfi7+1A80v9ZzGO.r8I9lbyVYOz2x3JoV6xUEbpBnuC.pNSx M1r6WtUx0s3C1AV0UQnRDqm0APEQJhUTFmtYI9Gaa3c0i543nHVZMvIJtPvJ hTIzfh9jjKbqxk6UQtPsJW3dWt7MQOh76c4R7s0R6.FMXfJXBNcpdT8gfYjl r+svbMQtbFlhEo2EKwfha.b0+pQ4kr0HqjqffgLJUT+GBS7sOX6BV+KWTixc SuBBFcfpIMRt5+TQDhQ3E55HXnAXtncCOcDAq+kKiDKZuKWXyJy2q+ELip1o +MvvtCzpvvNFUuS+WvCFOPC5iQCTSL3P0DafpHQACT.CYzluo8OYEng5dIQF UIl2UPvHCUDSbIIsteR50QvnslPB167nfLZithujftFBVqpRwsN80PvZ2324 5HXsuODzPEwfWjWoll+vEKdgkWnO0JYZTR3GUMdvcr52iSU+tp4DixYuDu9O QeHg4SeNtjMsbYtZ5AV46Nh+IxKH+g++AAEvD -----------end_max5_patcher-----------
Forums > Max For Live