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
This goes somewhere else
-A
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.
-A
@Andrew
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.
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
Cheers
-A
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
-A
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.
Here's a Max 8 and Live 10 solution that just requires you to send a bang before you open the max editor for the first time
I just tried this abstraction and I can't seem to get it working. I changed all the port numbers in the patch to the port I am using, and then applied the same port number in the object abstraction itself. Am I doing something wrong? Not sure how this patch is actually implemented. Thanks!
I've never managed to get [udpreceive] to work properly with a port that is already open somewhere else in the system even though it should, especially if you want to receive the same message stream that is being read somewhere else. In my opinion, is a fundemental flaw in how the object has been coded. I've got around it by using the Sadam library objects, which do work properly! Unfortunately, unlike [udpreceive], they only output the raw binary data rather than decoded OSC messages so my solution is to resend the data internally (via localhost or 127.0.0.1) from [sadam.udpclient] to [udpreceive] using a randomised port number:
Thanks Andy, looks great, only missing the [OSCDebug]-abstraction
Hello guys. I'm learning Max for Live here. I decided to file my synth with a granulator in appearance from YouTube https://disk.yandex.ru/d/6ImPB8hlc3JJAA , but I got stuck on the fact that there was no sound. It seems to me that there is some kind of preliminary setting that includes this https://disk.yandex.ru/d/SlBosSyyFbnEZA Please tell me where it is enabled. I can not check the sound in real time when clicking on the replacement https://disk.yandex.ru/d/tjQlHX3AZVIi0w
Thanks a lot, Andy