one udpsend to many udpreceive
Hi,
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.
thanks,
Elias
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. 127.0.0.1:3000, 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.
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.
Note: Some "observers" built into M4L are using this method.
i’m not in front of max right now. does [value] work across separate instances of max?
Oops, my bad. It doesn’t work.
What you need is multicast communication. Take a look at the mxj objects net.multi.send and net.multi.recv, or even net.maxhole.
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?
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.
[mxj net.multi.send] en [mxj net.multi.recv] are great.
I really have to learn about this mxj stuff.
Thank you!
we had a similar question here some months ago.
i suggested to use multicast adresses in the LAN – instead of unique IPs.
-110
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.
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.