Forums > MaxMSP

Alternatives to udpreceive/udpsend

April 7, 2013 | 5:40 pm

so I’ve been working with OSC for quite a few years now, but I’ve only just started scaling my projects to multi-player scenarios, across several machines and environments. And one of those environments is Ableton Live… unfortunately.

I’ve come to the painful conclusion that working with OSC *reception* in Live is simply too big of a hassle with udpreceive. It’s the binding and un-binding of udpreceive that’s kicking my ass, and I’m at a desparate point now.

If you edit the device in Live you have to not only delete the device after saving and re-instate it, you also have to quit out of Max first. It’s the biggest nuisance, especially if you just wanted to tweak something (completely un-OSC-related) in your patch before a show.

Are there viable alternatives? net.udp.recv has the same binding issues, but even worse, they don’t allow multiple instances to use the same port, so that’s right out. I’d love to avoid externals, but I am desparate.


April 7, 2013 | 7:20 pm

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



dtr
April 7, 2013 | 7:30 pm

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.


April 7, 2013 | 7:41 pm

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.


April 7, 2013 | 10:47 pm

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.


April 8, 2013 | 9:49 am

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


April 8, 2013 | 10:25 am

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?


April 8, 2013 | 11:04 am

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


April 8, 2013 | 11:21 am

Á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 :)


April 8, 2013 | 12:15 pm

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.


April 8, 2013 | 2:13 pm

Reading the documentation it should not be an issue.


Some Max objects monopolize a resource on your computer. The udpreceive object, for example, reserves a UDP port for itself so that no one else can access the port. This has the potential to create problems when you have two udpreceive objects in two copies of the same device. In this specific case, we have made the UDP objects release the port when they are disabled as a result of a preview mode switch. However, other third-party objects with similar resource-monopolizing issues may not work properly with preview mode.

I would expect that the udpreceive within live is disabled when you open the editor and have preview mode on. If you switch preview mode it should deactivate the one in max and activate the one in live again.

Also why do you need to delete and re-instate the device when you saved it?


April 8, 2013 | 3:45 pm

Unfortunately it doesn’t work in practice. If you have an M4L device with udpreceive, open it in the editor and close again, the udpreceive will not work anymore in Live. You need to delete and reload the device to enforce port reactivation.

Hopefully it’s just a bug that can be fixed.


April 8, 2013 | 6:22 pm

You are right. It’s a bug. I just tested it with a simple java external. active message is not sent when switching preview mode on/off.
Did anyone report this as bug already or contacted support regarding this?


April 8, 2013 | 9:05 pm

Funk Eater, I would be very happy if you could follow up your findings with support?


April 8, 2013 | 9:54 pm

I’ll prepare a short example patch and contact support.


April 9, 2013 | 8:24 pm

I did some more tests and for me it works fine with udpreceive. It is properly disabled in live when opening the editor and is enabled again when disabling preview mode. But there seams to be a timing issue.

I managed to get net.udp.recv to work properly with:

– Pasted Max Patch, click to expand. –

April 16, 2013 | 11:30 pm

darn. yeah, see the issue is that I need to run it simultaneously on about 10-20 devices, so net.udp.recv won’t cut it.

Damn. I’m getting closer and closer to simply cutting out Live altogether… :(

Still, it’s nice to know that it may be a localized problem, since it’s working for Funk Eater here.


April 19, 2013 | 11:04 am

If you are using Lemur you could try using the LemurLoader external (included as part of Mu) which can automatically change the ports used on the Lemur and do fancy things like load templates and modules. I use a max device which automatically scans and sets up my lemur for live shows. I also built in some functionality for using multiple lemurs and loading separate templates/setting to each of them. I could post the code if you fancy a look


April 19, 2013 | 11:20 am

Hi cphas! :) We actually have just about the exact same code built here, hehe :) Great minds think alike, huh?

We haven’t fully implemented it yet, I’d love to have a look.
… still doesn’t solve the problem, though – the way it is we cannot edit patches while inside Live without having to quit out of max and deleting and replacing the device…


April 19, 2013 | 11:22 am

:doublepost:


April 19, 2013 | 11:28 am

Haha and fools rarely differ :p

Here you go the index option selects which lemur the device locks on to. LemurLoader always seems to order them the same way so you can have multiple copies as long as different indices are selected. Changing the port changes it on both the lemur and udpreceive and the OSC message are sent to a global send and receive pair. I’ve never come across the problem you seem to be having. It does occasionally lock to a port causing errors but this device makes it simple enough to change the port. Hope this helps you out :)

– Pasted Max Patch, click to expand. –

April 19, 2013 | 1:29 pm

hey thanks – yeah, iterating through ports on the lemurs seems to be the way to go.

Our orchestra is upgrading now, so we’re coming up on six ipad lemurs and three Jazzmutant legacy Lemurs… eep!


April 19, 2013 | 6:34 pm

just had a look, mate – looks ultra-tidy! There’s some really clean stuff that I’ll integrate in ours first chance we get – ours has some other code in it to auto-detect whether it’s a legacy lemur or an ipad that we’ll want to move in.

thanks for sharing – I hope to share ours back once it’s… legible, hehe.
thanks again.


April 19, 2013 | 6:42 pm

Cheers mate I tend to get a bit OCD with max patching lol. How do you detect what kind of Lemur is connected? I didn’t realise that was possible.


April 19, 2013 | 11:51 pm

we have a specific template that sends out the "battery" variable – if it gets a value back, it’s iPad ;) Such a dirty hack, we felt bad for even doing it, but it bloody works :) That way we can flip things around a bit better, distinguishing between the wired and wireless networks, not to mention sending the specific templates up.

Still, we’ll probably need another night or two of hacking to get it to where we want it.


April 20, 2013 | 3:38 pm

Ahh that’s clever lol. I had looked into seeing if there was anyway to ping to identify the device as either an iPad or an iPhone but it doesn’t seem to be possible. It would be a really useful thing for Liine to include…


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