Alternatives to udpreceive/udpsend

Hi,

I am not sure that I understand your problem, but maybe you should consider that port bindings are managed by the OS, and once something gets bound to a specific port, the OS itself won't allow other guys to bind to the same port (this is how network sockets work by design - otherwise it could happen that two different processes start listening on the same incoming port, and then there would be no way to tell the actual target of an incoming network package). So, you can't have two udp (or tcp) listeners bound to the same port, regardless of whether you're trying to connect from Max or Live or whatever application. As far as I know, the OS will not allow that for you...

Hope this helps,
Ádám

You could have a look at Matthijs Kneppers' solution: http://livegrabber.sourceforge.net/
He uses custom mxj networking objects that check whether ports are already bound and elegantly switch to the next available one if necessary.
There was a bug in Max608 that prevented it from working right. Is supposed to be fixed in 61 but I haven't verified that.

As a workaround you could have a single "UdpReceiver" device permanently loaded in your Live set and transmit the messages from there to other devices via send/receive objects. However, it would introduce some latency and thus may not be suited for time critical messages.

yeah, that's the thing; the Lemurs we use (quite a few) are somewhat locked to specific udp ports, so I can't "elegantly" switch them. I kinda just need Max to release the ports once it isn't using them :( Apparently this isn't a bug, it's the expected behaviour.

And broc, that was exactly the approach we were going for, but since it's an orchestra with real-time input, that extra latency simply isn't something we can do, either.

I really want to use Live for this, but damn, it's really difficult like this, it all seems to stem from the fact that there's a differentiation between Live the program, and Max the program, where MfL ought to remove those lines a bit more for it to work.

Hi,

if the only problem of yours is that you need to release a port after using it then a simple workaround would be to take a random port number (from a pool that surely wouldn't overlap with any actual port that you use) and assign it to udpreceive once you don't need it any longer. This is slightly trickier to implement than it sounds (for example, you have to check whether the new port assignment was successful etc), but it can be done with a little patching.

HTH,
Ádám

Is the problem (or part of the problem) the lack of a coherent active/inactive notification system for when patchers are moved between Live's embedded Max runtime and the external Max for editing?

I think the binding conflict simply occurs between Max and Live which are different applications running more or less at the same time.

Ádám,
>would be to take a random port number (from a pool that surely wouldn't overlap with any actual port that you use) and assign it to udpreceive once you don't need it any longer.

hmm. Some kind of closebang mechanism that binds to port 11111 or some nonsense would perhaps work to liberate the port efficiently...

Nick,
I'm not sure, actually. Ideally they'd appear as the same application somehow (insert ubiquitous "oh that must be easy to code" comment) - the transparency that I get the impression the devs are looking for seems to go out the window.

broc,
>I think the binding conflict simply occurs between Max and Live which are different applications running more or less at the same time.
as I've tried to explain previously, it isn't as simple, I think. Because even after editing, when you close the Max patch that binds the port it doesn't release it in a way where you can "get it back" in your mfl device; you have to delete the mfl device and put it back in in order to gain access to the unused but bound port. (This might point towards what Nick is saying, I guess)

I guess what I'm looking for is a way of standardizing my workflow so that I don't find myself doing backflips just to use OSC :)

I don't think there is a proper solution unless Max would be fully integrated into Live, ie. running the M4L device editor not in external Max but in the Live environment.