huh!? udpreceive not working inside a M4L device

    Nov 07 2011 | 10:26 pm
    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...

    • Nov 07 2011 | 10:32 pm
      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!
    • Nov 21 2011 | 3:02 am
      OK - wow. This just saved me from tearing my hair out. Thanks basvik. This is well-worth noting somewhere in big capital letters.
    • Nov 21 2011 | 5:16 am
      By saving the patch preset you mean 'in a preset object' ? If that's it, never seen this mentioned anywhere...
    • Nov 21 2011 | 10:21 am
      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.
    • Nov 21 2011 | 7:17 pm
      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.
    • Nov 21 2011 | 9:41 pm
      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.
    • Nov 22 2011 | 3:27 pm
      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.
    • Jan 17 2012 | 4:33 pm
      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 ?
    • Jan 17 2012 | 5:26 pm
      Try deleting and re-aadding the device in live. It works fornme sometimes
    • Jan 19 2012 | 6:30 am
      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.
    • Jan 19 2012 | 11:07 am
      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.
    • Jan 20 2012 | 2:19 am
      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!
    • Feb 02 2012 | 1:17 am
      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 ?
    • Feb 06 2012 | 4:31 am
      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.
    • Feb 06 2012 | 4:36 am
      @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.
    • Feb 06 2012 | 1:05 pm
      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).
    • Feb 07 2012 | 3:27 am
      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?
    • Feb 08 2012 | 10:22 am
      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...
    • Feb 08 2012 | 11:05 am
      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?
    • Mar 03 2012 | 1:16 am
      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....
    • Apr 13 2012 | 11:36 am
      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...
    • Feb 21 2013 | 10:52 pm
      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.