Alternatives to udpreceive/udpsend

Apr 7, 2013 at 5:40pm

Alternatives to udpreceive/udpsend

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.

#67581
Apr 7, 2013 at 7:20pm

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

#243195
Apr 7, 2013 at 7:30pm

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.

#243196
Apr 7, 2013 at 7:41pm

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.

#243197
Apr 7, 2013 at 10:47pm

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.

#243198
Apr 8, 2013 at 9:49am

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

#243199
Apr 8, 2013 at 10:25am

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?

#243200
Apr 8, 2013 at 11:04am

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

#243201
Apr 8, 2013 at 11:21am

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

#243202
Apr 8, 2013 at 12:15pm

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.

#243203
Apr 8, 2013 at 2:13pm

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?

#243204
Apr 8, 2013 at 3:45pm

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.

#243205
Apr 8, 2013 at 6:22pm

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?

#243206
Apr 8, 2013 at 9:05pm

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

#243207
Apr 8, 2013 at 9:54pm

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

#243208
Apr 9, 2013 at 8:24pm

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. –
#243209
Apr 16, 2013 at 11:30pm

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.

#243210
Apr 19, 2013 at 11:04am

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

#243211
Apr 19, 2013 at 11:20am

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…

#243212
Apr 19, 2013 at 11:22am

:doublepost:

#243213
Apr 19, 2013 at 11:28am

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. –
#243214
Apr 19, 2013 at 1:29pm

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!

#243215
Apr 19, 2013 at 6:34pm

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.

#243216
Apr 19, 2013 at 6:42pm

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.

#243217
Apr 19, 2013 at 11:51pm

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.

#243218
Apr 20, 2013 at 3:38pm

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…

#243219

You must be logged in to reply to this topic.