Udpreceive not really working/ binding for osc
Does anyone know why, for me, a maxpatch that uses UDPReceive (let’s say on port 8000) will work when I first load it, but when I open the patch in the max editor, it completely stops receiving data. The max window says
"bind to port 8000 unsuccessful.
there is probably something already bound to this port." every single time, once I open the device in the editor. Does anyone know how to stop this from happening. It happened when i moved to Max6 on the ableton 9/M4L beta and is a problem on the 32 and 64 bit versions.
I have to quit max and ableton each time I want to edit and then use a device. It is very annoying.
The problem is that an UDP receive port can be bound only to one app at the same time which leads to a binding conflict between Live and Max (editor).
See also this thread for related discussion.
I’m getting this same issue. Every time I go to edit a device, all my devices on that port stop working. The max window says "bind to port 1705 unsuccessful. there is probably something already bound to this port." for everyone of my devices running in the session. They worked only a minute ago on that same port.
I can’t figure out what is causing this problem. And the only way to fix it is to relaunch everything… but the big problem is I can’t edit patches with live in coming data because I can’t get a port connection. This is a huge problem as I can’t debug! I have to hope I patch everything up properly and relaunch to test.
This shouldn’t be an issue. What’s going on?
(I read the related forum discussion but nothing fruitful there)
max opens a new port when opening in edit mode
and we can all agree that this is really silly.
Best workaround is having little "enable/disable" buttons on each udpreceive that will switch between, say, port 8000 and port 9000 – that’ll let you jump back and forth a lot easier.
same problem here
i used to be able to switch from Ableton to editing the M4L device in Max and the port would work in Max
this was with Ableton8 + Max5
with ableton9 + max6 this doesn’t work anymore…
also, when i close the patch in Max and go back to Ableton, the osc port doesn’t work anymore,
in ableton 8, reloading the M4L device used to remedy this problem
in ableton 9, i first have to Quit Max, then reload the M4L Device…. that adds 1 more step in my routine…bahh
What really bothers me is that this isn’t being acknowledged as an issue… it’s considered "how it works", which is frustrating.
I seem to remember from earlier discussions that it has been acknowledged as an issue which is difficult or even impossible to solve since port binding is handled on system level. But anyway, some official clarification and documentation of the issue would be much appreciated.
There’s nothing we can do about the OS claiming network ports.
How about something along these lines -
This goes in a device
----------begin_max5_patcher---------- 510.3ocyVtsbaCBDF9ZomBFtV0iPGw8t1WiNYxfj1ZSFYjF.451L4cubPJwo QNVwMwStwLrrr7uedWP2GFfq5N.JL5qnefBBtOLHvYxZHXbd.dG6PcKS4bCK F1UARbjeIdiyXW0cegPlL9yNgVv1Atk9ljyZQeuqsYZ4dlzrnFj2BBVUqys3 w05FzsfV+6dvqILWnwQHbESrAit4nCPw+iyGR7poMajFWX1tSnjmL5CpyZxi ZPWukK1bqDp09iJqXsIRnj3B6PtMrHBcUL5F6VdHLz9SzBozNPoXafoTVCGb mBtuSpQTJc8b.Leg.7EP5sQljYIC4zjIOI2AiLOY7SJ9fHCcNxj8IkLi0Ljr x2AxHfeYR1W.FEzhHn3YvR4kREW2TzSiuMJkNKkROOkHo1AeUzE2YcBJMzza NPfuGNUQT50oFhbo0PThcfR+HnSqgKqza4pFXOuFlgNz+2ZowKpsCuC750pl hc7pzUFUtdVb4TfIqE+6aat3Ys+bFp5Fj0SYzzMNn3GSjFPo4Bll2INxozm4 yVdSCHN9wrFtx99lCxwy9m4hkS9mJ4jt.0X+bfqjbJWhbxtpxgbN4je0jioy FkbF4Tdgpw2mw562CR0XHcBwbqzccR6zhH2TtvO00tiklqgl720piYRSet1z jOH8W8bfVfCsmyCg+Efi8XG8 -----------end_max5_patcher-----------
This goes somewhere else
----------begin_max5_patcher---------- 436.3ocwTEsaBBCE8Y3qnoOyVnHf3daeGKFSA5vZvVRo3Xy3+9ZKTE2HQlQc gPI2SuTNmy8dYuqCLk2RpgfW.uAbb1653Xfz.N8wNvs31rRbsIMHi7AOcCzq aKIoUZfaxqpIrb.JX9y9pKDHIIYgMMZtII0K9TrE6cNSxvaIlcdUPwkC2ol9 kYGTvy98vrlsTVIQZ3A5DHuQZQsoVgkYqorhUBRlrScAAJZ4YefB6hTqfk52 4fqqdw6N3BIi3BQ+St.ZAxH+E2DWPxKJJIiHuP3QJHThSRDqHLbZIYH85Xr7 yJRG2fTlhkKmtNQWTmgHq9t80ZkrDb.x2eD8Gb4x6uTeJlUbR9So5GbktRRr dMN5d3JY7FlpbOhmftBOQ2Q3Af16yZPlhCEMpCEd44iY5CDLe1nVjgBvRJ6m +4zbfZ7y8sZdiHyJodq.fNJjbRsjxvRJmMHG0+IA9GyYMMOmvFN8jSq0CTF+ 0ez52egM9WfMQOL1DNA1D7vXSvDXC5JYSWaDtpZGQT2ejFhnFz1vE5vXOSHk 0EZFsgBxNpM+YFDrP0GKUMwMhtop1jXnq96bv8a.SS6yf. -----------end_max5_patcher-----------
Hi Andrew, both patches are the same so the difference isn’t clear :))
Weird, they’re different for me.
The top one is a port switcher which uses the "enabled/disabled" outlet of live.thisdevice to trigger port changes in udpreceive.
The bottom one is a dumb OSC test data sender.
When connecting ‘print’ to the 3rd outlet of live.thisdevice I get following results.
In the normal Max window:
- open device: -> 1
- close device: -> 0
In the Live Max window:
- open device: -> 0
- close device: -> 1
So it seems that the device receives ’1′ in both cases, when opened and closed, which would make it impossible to recognize if it’s in editor or performance mode.
Can you confirm this behavior?
I’m not sure that this idea will work for all the different combinations of preview button action etc, but for me it worked in basic tests.
It’s all about the timing of the messages.
Opening a device for editing disables the MFL copy and enables the editor one, and the opposite when you close a device.
Is it not working for you? How is it failing?
No, it doesn’t work for me. After open and close no more messages are received.
Just did another simple test connecting a message box to observe the preview state and it shows ’1′ in both edit and performance mode.
----------begin_max5_patcher---------- 316.3ocmRtsaCCBCF9ZxSAhqypJYpMs6tsWippIZvKwSIPTvoqaU8ceAxA0C qZS6FP7ai+s+fiQLwN6AvI3Ow2vYriQLVPxKvFNyDUpCYkJWHMQE3bpbPD2G ifCTPWNp7l0PN7KvqJmOa9fbcC3.CoHzZdsAxndSSV1kAe4J+5Be1bYmBe6v sLsUnoDnf2IChnN3nc26OjdtqFUUvUwyMnpj+hsTOFtVQYEnI+LmkIASkKRu u21VZzb4OLGmq2mJ8YMzWdgfu0G4TTjeI9OhWC7Q2bcCcKw8vLp.cZXOlA+B qufZxaoVx+mZqWG3jbgeKs+vp6BsGuGb1oL4hXt.Mz31E3JTuto1b8myPK40 ujgNaaS1XwGFQdxTWoAGglo2rMSed3xobJPsFBgGwXEpqscs1PKbUCFcJ5a. mwAwW. -----------end_max5_patcher-----------
I can open and close it as much as I like and goof with preview as well and it keeps on working.
Perhaps there is something in my beta build you don’t have. Please let me know versions and I’ll do some regression tests
I’m on Mac OS 10.5.8, Live 8.4, Max 5.1.9
Please try my simple test with the message box.
Do you get different preview states 1 and 0 depending on edit/performance mode?
It’s working fine for me. Both with 9.03/6.13b and with 8.4.1/5.1.9 on 10.6.8
Strange. I’m getting error messages about a binding conflict of the port which is assigned to preview state 1. Maybe it’s a timing problem depending on context.
I’m setting this up for a solid round of testing. Thank you for your tenacity, Andrew – it’s always greatly appreciated. Will report back as I go.
I’m having a similar problem but I’m trying to send OSC data from a Max patch (sending on udpsend localhost 10000), to a standalone app (built with Max) receiving on udpreceive 10000).
I get the same error message:
binding to port 10000
bind to port 10000 unsuccessful.
there is probably something already bound to this port.
How do I send osc data from one app to another on the same machine using udp?
(the standalone app will be installed on many machines on a network (including the master machine), then a max patch will act as the master, pushing data out to the rest)
Rodrigo, normally udpsends don’t cause the problem, it’s udpreceive that doesn’t work, IIRC. Is there a udpreceive in the Max patch as well as in the standalone?
Yeah I was using local monitoring in the max patch, which I don’t actually need. After removing that, it was gravy.