one udpsend to many udpreceive

May 25, 2011 at 8:02pm

one udpsend to many udpreceive


I have a path that I run in different instances of max/MSP so they render at different cores. I would like to add a ‘remote control’ path that can control these ‘clients’ so I wouldn’t have to manually give in the same settings per patch.

Send and receive only works in one max/msp instance. I thought it would be possible with udpsend and udpreceive. But multiple instances of udpsend of udpreceive give the error ‘bind to port xxxx unsuccessful’. I searched a little on the forum, and it seems there isn’t an easy way to have a ‘one to many’ communication. I’m a little surprised by that.

I want to send bangs and an int, to control the client patches in a very simple way, nothing fancy.
If it indeed is inpossible or difficult, I’ll just continue manual patch per patch control.


May 25, 2011 at 8:48pm

the port binding only occurs when a udpreceive is instantiated. so if you specify a unique port number for each receive instance, it will work. the controller patch can send to e.g., 3001, 3002, etc and slave patches running in separate runtime instances can have a udpreceive using those port numbers without error. maybe somebody else knows of a dynamic solution.

May 25, 2011 at 9:13pm

Another solution would be using a “global variable”, i.e. [value] object.
But timing may be problematic as it depends on the polling rate of the receivers.

– Pasted Max Patch, click to expand. –

Note: Some “observers” built into M4L are using this method.

May 25, 2011 at 9:20pm

i’m not in front of max right now. does [value] work across separate instances of max?

May 25, 2011 at 9:27pm

Oops, my bad. It doesn’t work.

May 25, 2011 at 9:35pm

What you need is multicast communication. Take a look at the mxj objects net.multi.send and net.multi.recv, or even net.maxhole.

May 25, 2011 at 10:47pm

Surely the easiest solution is simply to receive all the control data in one patch (with a udpreceive) and then udp send it locally over different ports for the other patchers to pick it up?

May 25, 2011 at 11:36pm

Thank you all for the quick responses!

@driftpattern: I indeed was looking for a dynamic approach, so I wouldn’t need to update all the different patches when changes are made.

@broc: I guess the value object has quiet the same characteristics as the send and receive objects. No?

@jesse: I’m going to take a look at these ‘multicast type’ objects. Sounds promising!

@David butler: the thing is that every patch is in a different instance of max/msp, therefore I would need to have unique patches, as driftpattern also suggested. That is a working solution, but I would like to have it simple and dynamic.

May 26, 2011 at 7:42pm

[mxj net.multi.send] en [mxj net.multi.recv] are great.
I really have to learn about this mxj stuff.
Thank you!

May 26, 2011 at 7:51pm

we had a similar question here some months ago.

i suggested to use multicast adresses in the LAN – instead of unique IPs.


May 27, 2011 at 11:03pm

re: net.multi and maxhole
i had no idea these were there. it would be great if c74 could add these to the “see also” section for the udp help files. maybe even mention in the communications tutorials.

May 28, 2011 at 6:52am

I agree, they are in the standard help files, but I didn’t find them at all, unless typing something after “mxj” so it became an object you could ask help for.


You must be logged in to reply to this topic.