huh!? udpreceive not working inside a M4L device

Nov 7, 2011 at 10:26pm

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!!

#59873
Nov 7, 2011 at 10:32pm

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!

#215529
Nov 21, 2011 at 3:02am

OK – wow. This just saved me from tearing my hair out. Thanks basvik. This is well-worth noting somewhere in big capital letters.

#215530
Nov 21, 2011 at 5:16am

By saving the patch preset you mean ‘in a preset object’ ? If that’s it, never seen this mentioned anywhere…

#215531
Nov 21, 2011 at 10:21am

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.

#215532
Nov 21, 2011 at 7:17pm

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.

#215533
Nov 21, 2011 at 9:41pm

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.

#215534
Nov 22, 2011 at 3:27pm

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.

#215535
Jan 17, 2012 at 4:33pm

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 ?

#215536
Jan 17, 2012 at 5:26pm

Try deleting and re-aadding the device in live. It works fornme sometimes

#215537
Jan 19, 2012 at 6:30am

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.

#215538
Jan 19, 2012 at 11:07am

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.

– Pasted Max Patch, click to expand. –
#215539
Jan 20, 2012 at 2:19am

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!

#215540
Feb 2, 2012 at 1:17am

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 ?

#215541
Feb 6, 2012 at 4:31am

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.

#215542
Feb 6, 2012 at 4:36am

@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.

#215543
Feb 6, 2012 at 1:05pm

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).

#215544
Feb 7, 2012 at 3:27am

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?

#215545
Feb 8, 2012 at 10:22am

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…

#215546
Feb 8, 2012 at 11:05am

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?

#215547
Mar 3, 2012 at 1:16am

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….

#215548
Apr 13, 2012 at 11:36am

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…

#215549
Feb 21, 2013 at 10:52pm

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.

#215550

You must be logged in to reply to this topic.