Forums > Max For Live

Udpreceive not really working/ binding for osc

February 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.


February 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.

http://cycling74.com/forums/topic.php?id=36165


March 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)


March 12, 2013 | 6:02 pm

max opens a new port when opening in edit mode


March 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 9, 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 9, 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 9, 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 9, 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

– Pasted Max Patch, click to expand. –

This goes somewhere else

– Pasted Max Patch, click to expand. –

-A


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.

-A


May 10, 2013 | 7:33 pm

@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?


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.

– Pasted Max Patch, click to expand. –

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

Cheers

-A


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

-A


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 | 3: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 26, 2013 | 5:08 pm

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 26, 2013 | 11:52 pm

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 | 3:38 am

Yeah I was using local monitoring in the max patch, which I don’t actually need. After removing that, it was gravy.


Viewing 22 posts - 1 through 22 (of 22 total)