Udpreceive not really working/ binding for osc

    Feb 14 2013 | 11:06 am
    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.

    • Feb 14 2013 | 12:04 pm
      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.
    • Mar 12 2013 | 5:28 pm
      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)
    • Mar 12 2013 | 6:02 pm
      max opens a new port when opening in edit mode
    • Mar 12 2013 | 6:22 pm
      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.
    • May 09 2013 | 10:09 am
      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
    • May 09 2013 | 10:28 am
      What really bothers me is that this isn't being acknowledged as an issue... it's considered "how it works", which is frustrating.
    • May 09 2013 | 11:05 am
      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.
    • May 09 2013 | 3:45 pm
      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
    • May 10 2013 | 8:00 am
      Hi Andrew, both patches are the same so the difference isn't clear :))
    • May 10 2013 | 2:42 pm
      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.
    • May 10 2013 | 7:33 pm
      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?
    • May 10 2013 | 8:12 pm
      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?
    • May 10 2013 | 9:16 pm
      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.
    • May 10 2013 | 9:25 pm
      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
    • May 10 2013 | 9:32 pm
      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?
    • May 10 2013 | 9:52 pm
      It's working fine for me. Both with 9.03/6.13b and with 8.4.1/5.1.9 on 10.6.8
    • May 11 2013 | 2:04 am
      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.
    • May 20 2013 | 10:21 pm
      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.
    • May 27 2013 | 12:08 am
      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)
    • May 27 2013 | 6:52 am
      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?
    • May 27 2013 | 10:38 am
      Yeah I was using local monitoring in the max patch, which I don't actually need. After removing that, it was gravy.