Udpreceive not really working/ binding for osc

Feb 14, 2013 at 11:06am

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.

#66512
Feb 14, 2013 at 12:04pm

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

#239392
Mar 12, 2013 at 5:28pm

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)

#239393
Mar 12, 2013 at 6:02pm

max opens a new port when opening in edit mode

#239394
Mar 12, 2013 at 6:22pm

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.

#239395
May 9, 2013 at 10:09am

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

#239396
May 9, 2013 at 10:28am

What really bothers me is that this isn’t being acknowledged as an issue… it’s considered “how it works”, which is frustrating.

#239397
May 9, 2013 at 11:05am

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.

#239398
May 9, 2013 at 3:45pm

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

#239399
May 10, 2013 at 8:00am

Hi Andrew, both patches are the same so the difference isn’t clear :))

#239400
May 10, 2013 at 2:42pm

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

#239401
May 10, 2013 at 7:33pm

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

#239402
May 10, 2013 at 8:12pm

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?

#239403
May 10, 2013 at 9:16pm

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. –
#239404
May 10, 2013 at 9:25pm

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

#239405
May 10, 2013 at 9:32pm

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?

#239406
May 10, 2013 at 9:52pm

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

#239407
May 11, 2013 at 2:04am

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.

#239408
May 20, 2013 at 3:21pm

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.

#249995
May 26, 2013 at 5:08pm

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)

#250756
May 26, 2013 at 11:52pm

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?

#250773
May 27, 2013 at 3:38am

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

#250783

You must be logged in to reply to this topic.