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.
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,
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.
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.
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.
>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…
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.
>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.
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?
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.
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?
Funk Eater, I would be very happy if you could follow up your findings with support?
I’ll prepare a short example patch and contact support.
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. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 517.3ocyUF0biBBDG+Y8SACO64.XLQumt1uF2z4FhvkPFEc.Lm85zu6GBwoI 8riI1zL4EwcYg8O+bY8kv.355NtFB9N3mfffWBCBbt5cDbvN.VQ6JJoZWXvJ tVS2vgQ94L7NiyOdvirsRHK4FW3jCNanlhsB4leo3EFe5xSiQQ.LdY+PBIN0 ZXeG7zgk76ZoQK9KuOZLxFj2sf4RW85ceifNJm0slgjhOZGjzJ2N.ePInkfG qKYCKxuByyMbuffPvS8y7ZXX+inOIPPWJPvKQwDKExQylH376AhH4+wJl+CH MJdCWx.zBiXOeT5fmrbI0MjgcFYWFbP2wvgwKoOCRQn4cMxWyjtbFX4JWxrl J2bUIilWBvfw4RxTbI0UnrXNbIabtj7Y3RzaiWUFU0sCH4l3VVSrEA6A+noV Y.qPeP8zz2yxxcCKVMCxkLN4Hy8d10lVk11OwlsBMiuWTbwchRbDh3prVkOC 9PV80TZIjlggSvkSZ1Ss78+o2c358eJC00sphgMenyI3sSHiqMBI0HpkGETx IwrUvXb2zC.fIzz0kbGFPi9w7rkS9YHm2o4uR8PP2Y5wVeAHSnmralb5yDdJ 5jeSkyTertcp4bJkIyszwewm1zrmqzG1SmRrsI2Uq5MWF4LERuoqsGTY6KND u2CUY6BZrs.aU91RcKW.C6yyqg+CFm.0RB -----------end_max5_patcher-----------
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.
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
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…
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. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 3517.3oc6cs0iihbE94d9Uf7NOjnsmNTWAxJEkKujUZ1cSxHEEoIiZQaWsGl ECV.tmKq17aOPUEtA21EEX3f6LYjFaiACm5qN2qyo5e4EWs3tzOIxW376cdq yUW8Ku3pqjeU0Wbk93qVrI7SKiCykW1hDwGSu6CKtVcpBwmJjecbZ3p6BSVW eh6SSJxi9hn5jH2ab0ec5thXQQwm2JTOyExeiy6zmNY2lnjxKP9nPO9kpeVq ucaXwx2Gkr91LwxB0Myi6W9fbnxWYrpWQked+cOZkjTKI+WwcaRnIgajzyh+ TVTXryeNMd0hpy9qu3EUubskPyFQdd3ZwSvl6VuLMNMy4kHmWhcdIw4kz9BS m.hvCDhPLr7MW0a7iCRrfI.jNA+Sw6ixkzqHq2Xy0mDeNNKDta7wiW8FmZhG hw6BdzmNO7gZZ8a9wJps0f0Yw2U8x272qdUjrR8MNua7v1rxwtvIeW18gKE2 d2ZmkkzaVZ7s4h3xQdTZx9u490M93ssNwso2e+flZN7+GephezoJd2SUX4aD 8QmZthBn7t3AQ1mKpH2YVL22UxEiLIjCnLdbzChajpByGBiTuMUXgbtqTBm6 Zh2YJXctaWQQZxBHrJhIRk7dpgJ1s90iMTQAi3zco1EmeLMQLHWBttmBC3NA .pRat1x2IlqwL3DGdkCpuPSTRwXohfPU7CARKckPD6znBxk.GrDM+fBwmZCn fedqXndvRsPwPPvXZfLb61RGcFjxgQalV4gmdv6QMZhzCP+fcty4tgpwbLsP RPJEkA3tEEB.TqY913nBGWG2gnl3ZSZKHCDhHJQGFxnCnSADIcnJN5QonsYh bQRQXkO8MHTJQEzmjZkjYSpzB9DWCdR4IEfjupB41soNj6RyVUFkSEPtepoI U17Y1zN7dcqUCOoOipGmDpe7ET0iZnHW4Xr5pzOnGBy1Os78IqDeZgImQuON MrAizI.dOhFrkRP54fwU.U6cCg+jauMv7d65aCyJG7EhraEIg2EKZ9Cphec0 sgEEYQklmDO9obMBqg3JLLdmH895ut96ad6yKDaUCXWM+vAO8cazvraENGT9 u8vbqqbWRTQdwmUj5wtUaJmwqNWPvMG6zQk+9RgOMa0QeD0y4F94OEtZOZee ZVwQYqZcYwoIqO3pTWjjst9sdxiuMLQDWO+pyA0oEh5fQVECgxjoJCIcwHWF DbQzxRDZUTlJKCCR+huRoBgzPHh2St78QvkktqDbkmwc.H5xzMaDUlQNvlTK 0EmvdzI.V4Un0P38DCH8P078YquSd7MtlBEp5QDnfT1Si50BvjOi1wHp761P g23YGiKuqpWGO6XD+o0NVamjZZBKKbUTJ9IrpaqTd6z9j8Nad8AxImFxYp7t vT9fy4l7exGaYxVKmSJRyDGnVWaCq7NU9zMX.6XlAcGtJ3JXucDc8Eqa4tZK k3HMeyiu7HtsNoDBVFGs7maEFjIoJD06DZXO5jrRdvNaJGmgXS5JQGAowYpz v6sOmMGvfnnhzj9aa6Dxq9HaYyZXIY+r3cqSenEnXXN5nbZGJs9S6ZYrQQ1K 9CKZ87NX3y7vLZP0vmiXbet7SLeeLc3pYdNwGeROEle9XpOX7wtWT7weexEJ abSKlOd12hdGn74mfgFSanXFwufXnqsb6wghg1K3hhg9e8rhe9BhYVoc9hhY l56CMyr++mYdNW4CJsYfGlW4COzh42go94HjJmBfa2v.PyAywGO74HZYk3xy U9AnU8ZnVDXfEPGi70.+fwI9.od.ZvLNuqU.nBCRoSnEkL9pA7l7o82HKdt8 lNy1krLrPLzTKepR2SrV7osN27s+teyMe6u8rK+t9X+j0Y7r5pjTsHWmJwcd SQBigQ7g4cgH9nKcIjZE+zYQXZkeXSt7y+nhHVMwxOkCUYoljKJFoJMo2Nap EVvt9pbYZTXgNQBKhUQOcYqdc0xt7gurIdHBQ5xonsZkA4WBRF0R.2tU+5XB XtHtq+0pO4g8zexmQLIuQ6yBmUOIpSqnqxsV2dJTM99hLhVZbd0qdU0hZORx It8UNggcapjyXYZxArhrxsDXNukeTWmU5PRoFa7.NG3QeQ5qEa1kMo.ft.94 p7DwCLB..VuYY1C.SlngtHc8svBBm9+f7F5vGpMgZl2.CG.7kXmRGzGw9Up2 01dclUzkxqQVCl+jiLMS+7OPe8Mgait4MgOHdSQVitgYO9c5KAZmzX9M8vF4 ZLjFFfVepcfsp+JmMvoUSwYNbOlKbXSZExTdeSWO2sSDqU+VYz3MM.XaWJuE WMW1tpawJEpvM1UtT5WWXCQUDaTMeiYrAArgc6vlyyvNlSerXML6XCgCbiJV 0jtqDODsbvMvVmcb.Zf4OWorwXDRD.cQdcUdalq93QIBwH514wTapPHecfI0 pbUwKD3ZDSPOySOKKX1SOqlGj.V1YwAPjc1kgIiU1YgggPWAwp04TsJSD2Yg iPWwprlLFSKKA2exYI9mQhONVLDmpyP+t+cV404T9+OFkrJ8isqd9cIEMUHB sd05YUUwuEnJaDuSjFhovVyo5+j+ZZdw4z9IJMoOO5+DhKf.6eKM6r.VBCHf sQ3mCsud.M9he5M+knjoMg5Jmf7zKmfwbFxvPF2Y4XOc2rsLKDUs2vTvCy7N bDBzLFJ6JIjoVVBM2srTcshZSKKQceN1xRczYzaanQ7raLZs5wwtynwpEqUO IMvNiFMqcFMb8FsMcGMqjd.oAoavcc59iVdQme6QexDtWFpgc5nOyE7Tshud 52LlUcJAxUbPC.SrAZsgHeUAo1gpzuVxlklYf628ltBk+UBlv5Al3A317WQX 1ZQgCx4knYCazEMgqEazeTLr6hQwNwCdmeaD8XSmxbc0EEXbS5gD70w1bVMl XiHEARQpJS6yn3jFWzhSTiaJXD.WqxcqJ8XconzyboqXyUc.TCOpRzx23FtJ ACeMR79tSC1TiMTUkZ4YLrZrOnrN4p5GYYXbE.432MGzY5XmN0B06OulwhIo VZJCes+6iz5kqcLqKDc5BpCH031LK11zELwEBbszjZSZbtjmzdBqQNy5ZPSg 7ztMkgaWeeCyxR+Xq0pgxXbOYGvR8CHbYMmyvLb.p8R2zSlu1d9XL2xpHFss r4KRauAfwbC7nRhl5QwL4m783H7A6.GEhMJ7n4l0oDNtOSCztCzkLZcwzSGR 9pQCoCurX4tVEkevDM10WMQ+jO0Zht5VN0avSMbvdYrHLq+6Blxe1PpJkt2f k0kvN0rrJfQstKYa3xe1IZakMO7PaxkwZ6ZLn410n4h2AAX5NjqppnjSxIHX wYnzxHZwL1ANFLbRrH4XHJjA1F2+sm2Qeq4Mv9slWDfYNrZCeOuHrLDtUmw1 9dGa+6jAZsAUWDyFWIPDjqDn5OKGMJyl4nCBpgG8JZYL+HHDf4BXP.yHmH.0 BHQLkG.DfE79Jw8hr3GqJlYJHW8ZfZzDFfVvj8ezqSCWUZE6OJCwMbWQZewn 3n7QO7uZYKcmMRLWwt.lvj3cqKGA+m9hQ4QqSBiqPI8mFIcP9OVvdLil5wvh QQIWVPDh2MDMEpnG+cRZBcF1Jo8zMXr+v2Jo86XmjVdujUq3A+Q0SRNxs33V vbd5trk07N5+PabciZ.YkHuHJYOE81F+oGowU89nUqDIGDEqp6MNYtgrlf7r gf75fd1DsZaZY7A40aUmrJmVoXY85ion8G83CZ7FAk1hbPcLBB56HPU6JXjb fnGOxilpQPWyAU6k+PwSXA4PAiZp1Zn6b90K.L5wyJ3g2O9Mlp6v3ARIFpqT hQdzDvuUs+D18HnmRLz.hpqTj8iBgqFAUGMEi.azZQAjmfaCOJbxLd1nQg4C G8Psfd7fSCmGxF5ANqvbajH4vgObuKK9GtM7O.BOtVPNvo8gYiEIFGN5wFtY uKL5g4BG8XszEBF5wJOnAjelMEwjfkdjPTMCkNlD4QSf+ILazWw.DQsxdGpm HpxGOlZEJnzf8GMEHJxVutQCXDHSKNEo533idjpjeZeDmouR19ilqQdUuuCk 1BaL9wgy2I1EkqAzfKKOmrid7fidrJxMFbzC2F5AP9Gq7zEAG8fsQZm0SKGd dxrCfjlLZdzDn+jZs9SfPTWaxU.fZHrw4u9M+5i7kEs.VucvqZH7VGU+2UV4 Tu2z3ElUNgAWRYH1nJlyurnGhGrzC5Lsje.mHVwfwTq9HFEn5bzlGgPMiH.g lFdQ4fC2UN9ADrsxNLtmnsBCYA3F50kGMEHpMi.Bfh21DEMgCK8z8RMBG8Xk mMvE2vAl7meIRrsqJC5xgdjdhdAQOH3xoBwF+JY.xOaC7.WfC3fKK0OXaRBL AN1GrMlKvvEF.1F9GFbAliQWVdmhcshelz2UMW5iD1mpRGMY+QSfGSVNDv8K Ip5g.Qumuv0a1XjIwMZjUoyBtf4Q9SvRUnK+CrpTJzNUimnRo.4YidH3j6Q7 w.QGY5oK7opGUbH8IrT0TKVWTrptgo0eiJGwQfUAB.mkFjMABfgyy.jUdNwf kdrhiqO5TP5BZTs2GnM6flHNNaJYu..QTqBcfCK8zUxfP.ZEyFesPvEJygtQ YvYTLPDDdJJIAk6dTDpYYRWczTHSZiye.JRZiM.PoFjETyPxzgpmAB2t8AQV t9VJIjEaB+fpQK3WKOLJQcnrwDVjIdHp95kcNxhvrkuOpPrrXmZ2jbwm74Kd Q0y4Wew+E+Ta18. -----------end_max5_patcher-----------
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!
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.
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.
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.
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…
Forums > MaxMSP