huh!? udpreceive not working inside a M4L device
guys - I'm stuck, probably something stupid.
I've been continuously editing while making devices over the past months, so I'd have the M4L device open in Max all the time (I have the full version of Max 6)
Only now do I find that when I close Max, the M4L device doesn't communicate with the outside world, either udp receive or just a simple receive object, listening to a Max patcher.
No idea what's going on!! hope this is an obvious one...
Thanks!!
ok. panic over. So you need to save the patch preset. Ok, pfew. totally does not make any sense to me .... is this documented anywhere? - but that's probably me still overreacting. ha!
OK - wow. This just saved me from tearing my hair out. Thanks basvik. This is well-worth noting somewhere in big capital letters.
By saving the patch preset you mean 'in a preset object' ? If that's it, never seen this mentioned anywhere...
I think the point is that sometimes after editing you need to save and *reload* the device into the Live set to ensure certain initializations (eg. binding to udp port). Saving it as 'preset object' or not doesn't really matter.
it would be good to have this in the manual or docs somewhere - even better if it was explained it somehow (just like the 'deferlow': seems like only on this forum can you figure out why when and how to use it to make M4L devices work - we're programming so we like knowing how stuff works, it helps us create better programs...
I may be completely wrong and happy to stand corrected if I missed where this was documented - but I haven't really found it anywhere, other than just 'stumbling upon' a post somewhere that said you have to save your preset. but... why? why?
@Stephane.. I'm not quite sure what it's called officially, but it is hitting the little disk icon on the top right of your M4L device IN LIVE and then hit enter or type a name.. I believe it is an Ableton preset you're saving there.
oh and - this post may sound grumpy but I absolutely love Max and M4L - this is all just comments to make it even better.
No grumpiness detected. I already had to save an amxd and reload it to get it to work properly, and there was no udp object in it.
Yes, reloading a device (or the whole Live set) seems necessary in several situations.
I guess this behavior is not intentional but just a flaw of the current M4L implementation.
Hi,
I have a similar problem here. I'm running Live 8.2.7, Max 5.1.9 on a windows 7 machine.
It seems that the updreceive object is not working inside max for live. It's running fine when the device is openned.
Saving presets as you suggested doesn't work here. Do you have any more info ?
Try deleting and re-aadding the device in live. It works fornme sometimes
basically udpsend/receive (I forget which one) will only allow a port to be bound to once. If there is already something bound to it it does not work.
Well, for maxforlive stuff your *max editor* will bind to the port, making it impossible for Live to bind to it, so you need to quit out of the max editor completely and then that will free up your mfl device to use the port.
this feels SO annoying. Has anyone gone through the trouble of setting up like a udp "Master Input", that will distribute udp to any patch that wants it? This is the only way I see that this would work properly.
Andreas and I had a moan about this over some beers last week.
I had a quick go at it just now. This sort-of works.
The "del 500" might not be necessary. What *is* necessary is the gate - flip in in the device inside Live (each time - sorry) - so that the device in Live goes offline to a different standby port than the one you open, otherwise the port clash remains.
Needless to say, this is an almightly hack. I'm sure it can be improved.
yeah, what I basically ended up doing was sending [port 9000, port 8000] to udpreceive on start. And I have them broken out to message objects, too.
Such a hack. But hey, it works for me at the moment. Now on to fixing my pattrstorage woes... yay!
I tried that trick (sending 2 differents ports to udpreceive) with several port numbers, but it just doesn't work. The Max editor is closed.
It doesn't work when the device is running, but it works perfectly when the device is being edited.
The same patch runs fine on Mac, do you think it could be a windows issue ?
sounds like you have a nasty problem Clement - if I were you I'd go back to basics and see if you can get anything at all. Eg create a M4L device with just a port that you can set in the the UI and a button to indicate whether it is receiving anything.
After you close your max editor etc, change the port in the M4L device (without opening the editor) just to make sure it is not some kind of issue with Max, or any other program already binding to that port.
You can also send to the same port from a M4L device: this way you can test the whole sending / receiving (and changing ports just from within M4L devices without needing to open the editor.
Don't forget to keep your 'Max' window open, the one from within Live (right-mouse click on the title bar of the actual device), so you can see any error messages. It normally tells you if anything is already bound to the port.
Good luck - let us know what you found.
@Nick: are you on PC or Mac? I didn't need to do anything like that.
However to make things easier for myself I created a 'UDP I/O' max patch which runs on its own: it communicates between Max and M4L devices. My Ipad talks to the UDP I/O patch which then passes the same signals on to LIVE (well, M4L) on different udp ports. This, together with saving the patch, works for me.
Hey Basvlk, thanks for your answer.
So I tried that, making a little patch with just the udpreceive object, and the possibility to select manually the port without openning it.
I cannot find a stable behaviour... For some time it never works directly, I have to change the port number, then come back to the one I want so that data is received. After a while though, it just works directly on the port I want, straight after launching the device.
Although, when I say that communication is working, its working with data coming from an udpsend object located in the same patch. It works also with an udpsend placed in another device. But it does not work with the iPad...
As far as the Max Runtime windows is concerned, everything seems fine. No error message coming from the udp objects. So no other things is hooked to the ports (apparently).
it really is strange - I don't think I have any more ideas.. does receiving data from your Ipad work consistently when you have the editor open?
hold on.. what port are you using? it may be a port that some other application on your PC is using?
Yeah when the editor is openned it's running perfectly. I'm using port 10000, but I tried other ones and it doesn't change anything... I'm kind of desperate...
I'd suggest doing a basic test.
1. In a new Live set create an M4L device that just contains the object [udpreceive 10000].
2. Save the set and quit Live.
3. Relaunch the Live set and open the Max runtime window (right-click on device title bar).
What message(s) do you see?
Clement, did you figure it out? I was just thinking.. could it be some kind of firewall/security program that allows some application to listen to a port and some others not? I suspect with the editor open it is 'Max' that accesses the ports and with the editor closed it is 'Live'... doing some wild guessing here....
Hi guys,
I'm working on it again and it seems to be what you suggested, a simple windows firewall problem...Live was not allowed. I figured that out installing Live 8.3 which was authorized by default and udp communication was working. Thanks a lot for reminding me that windows has a firewall, I've been working with mac for too long I guess...
I just came across this problem running windows 7 with lemur and Max for Live. I tired turning off windows firewall completely and also saving the device as a preset. Neither action made a difference.
Seems for the most part, the port will eventually switch back and osc connection will work again inside m4l/ableton once the max editor is closed, but the time it takes seems to vary.
This is pretty annoying situation to have to deal when building a device using OSC though,
Has anyone found a solid solution to this issue? I tried the workaround patch above but not really sure how that's supposed to work.
Here's a Max 8 and Live 10 solution that just requires you to send a bang before you open the max editor for the first time
My problem was that standalone Max was open at the same time as Live, receiving udp on the same port as my M4L device. When I closed max it started working in Live. shoutout WETTERBERG for the comment on bindings.
I also discovered that Audio needs to be on for Live!
These solutions, switching the ports on change of preview mode don't seem to work anymore with all the latest versions. Now when you go into edit mode, both Max and Live lose their bindings, until you quit Max. Not sure what to do at this point.
why don't you create a single master s/r UDP device and use only it
with appended send and receive objects to serve all other devices, being edited or not ?
Wetterberg mentioned that solution years ago ...
weird
What I figured out is you just have to open max before opening live or open it from within max for live (open it from an empty patch) BEFORE opening the patch which contain your udpreceive. If you don't do that then the binding will be lost both for max and live until you close max and you won't be able to edit anything until you close both.
I'm pretty sure the problem appeared just like this and I had no issue before.
I can confirm this behavior GRRRZ.
------------------------------------------------------------------------
Apple M1 Max
maxOS Monterey 12.6.5
Ableton Live 11.3.4
Max 8.5.4 (Full Version)
Not sure if this is what you are dealing with, but its a known (and annoying and apparently very hard to change) issue that once you edit an M4L device, the udp connection borks out and you have to reset the port number to a new one once you are out of edit mode. I went as far as making myself a fast system for doing this using a number box on the M4L side and an easy-to-edit Python script on the other.