UDP with M4L-Max is only working in one direction
I'm trying to get updsend and udpreceive working so I can send from my Max patch to an M4L patch in Live. Up until now I've been using send/receive which works only when the patch is open in Max, but it's very unpredictable.
So I'm switching it to udpsend/receive, but it appears to only be working in one direction. It sends fine from Live to Max, but not vice-versa. I'm not sure if this has anything with the port issues that have been mentioned before or not. I'm using "localhost" in both udpsend objects, which could possibly be the issue. I haven't worked much with the udp objects.
Max patch:
M4L patch:
I just tried your patches and they were working for me.
Have you used the UDP Tester (located under Extras) to see if both ports are available. Could just be that on your computer port 8665 (the one from Max) is available to use but port 9000 (the one from M4L) is not.
But one thing to note:
In some cases udp objects in M4L patches don't work if the Max application is open. I'm not sure why this is or if it applies to your case, but I use udp between two computers and after I create the connection I have to close out of the Max application to make it work (I don't use standalone version however, only m4l)
... port 9000 is used by a numer of applications, a.o by torrent clients. so it's quite possile that it is not free on your machine.
OS X has a port scanner as part of the network untilty. a quick check will tell you ports in use.
Yes, it must have been in use last night or something. Tried it again this morning and it's working fine.
Thanks the help!
Has anyone wrapped udpsend and updreceive into a wrapper patch that can be named so I can use it like a send/receive? Simply because send/receive don't work so good with M4L to Max.
If not, I'll have to create one...
By a name, I mean an argument could be specified that auto-created a unique port for each.
You could even keep the original send/receive pair which would allow double-clicking to jump to the receive from the send. We'll see...
what would be the advantage despite having on argument less to type in udpsend?
My thoughts exactly, Jan....
Well, the only benefit is that you can name the UDP so know what it's sending, similar to what I did with my send/receives. A comment beside could achieve the same, but having the old send/receives allow you to quickly jump to either end if ports are being used and need to be changed.
Most of this would be unnecessary if UDP just supported jumping back and forth the way send/receives do when you double-click them.
Most of this would be unnecessary if UDP just supported jumping back and forth the way send/receives do when you double-click them.
these are networking objects. How could that work? showing all udpsend/receive pairs all over the world ;)
[quote]these are networking objects. How could that work? showing all udpsend/receive pairs all over the world ;)[\quote]
It's a good point, but when I'm using it with localhost on a single machine, it could work. :)
This could all be avoided if send/receive just worked between Max and M4L!
Hello,
I'm reviving this thread as I am running into a problem.
I want a Max patch to communicate with a M4L device with udpreceive/send pairs. It works just fine when I am editing the M4L device, but stops working when using in a normal context.
Attached an example with a Max patch and a M4L device to illustrate.
Hopefully someone can help.
EDIT : it appears to work just fine on my other mac computer (OS 10.12.6)
Well, that's weird.
The message box "are_you_here" seems to be the cause. Corrupted or so. I deleted it, then replaced, it works fine.
hum, not so well.
I've got this message "message: no such object" 4 times in a row when loading a set containing the device.
try some other text instead of are_you_here
Wow, now, when I hit "m" to put a new message box, it makes a new object called "message" and the error message above.
Time for a new install I guess.
you have patch named message somewhere in max search path.
remove or rename it
damn you're right !
I made the silly thing to call a bpatcher used to display messages "message"....
Hopefully it'll fix it.
Thanks !!!!
It now works, but for some reason the port 8614 was unresponsive. Changed it to 8699 and it "solved" it.
How can it happen ?
Now port 8699 died as well, what can be the reason ?
sometimes things simply happen.
Not allways for obvious reason.
maybe tomorrow that port will work again
Hahaha, not sure if you're being serious of just mocking me (which I could understand as my few messages have been a bit chaotic), but that's quite a serious question. I mean, if I can't rely on a port number, that's a big deal, since I won't be able to change it on the receivers.
Is it generally admitted that udp ports can just stop working ?
no, but I don't use Live and can't really help you with it's problems.
In theory any app on the same network should be able to share ports.
Just make sure not to create feedback loops.
If you can use same port within max, than it is live that bugs it.
Thanks, I'll investigate.
If all you want is to get IDs of present devices,
just broadcast one request on a single port,
and let each device send it's ID back, to populate list.
Once i had to do similar thing for kind of voting system with few hundred
devices on the network.
My scenario is :
I got 1 Max patch, the "setlister", that allows me to cue and remotely load songs (ableton live sets), and in each live set, one "satellite" M4L device used to automatically discard saving when switching to another song.
I want the satellite to know if the setlister is open. If it is, it will be active and prevent from saving. If not, it will do nothing.
So the concept is :
when I load a song, the satellite sends a message to an udp port, which is listened by the setlister. If the setlister receives it, it sends back a message on another port. That sets the satellite active.
I can't think of a better routine. Maybe I'm missing something ?
I found some ports (8800 and 8900) that seem stable and keep working after a few reboots, but I have no id if I can rely on them...
what you describe is all ok, but I can't tell you why UDP ports
suddenly get corrupt, or deactivated ???
Is it only when Live is in use ?
Or is initiating the ports as the part of each loaded song causing it ?
You should maybe post details about the whole procedure,
like what is Max sending to Live in order to close one
and load another set.
try to replace localhost with 127.0.0.1
in both .maxpat and .amxd udpsend objects
I can confirm that Live does bug the send port.
If the above suggestion does not help,
you can try to send from max in some easy interval, like 5 seconds
or more message yes_i_am
Thanks for the suggestions, I'll try them.
Yeah, you're right, in the worst case, I can always send a message from the max patch from time to time, assuming that the connection works in this direction, of course.
Well, none of the suggestions will help, as it appears that the connection gets lost and the port die in Live, in both directions.
Checking with the support.
@Chapelier Fou : Did you try to set Both port numbers - automatically and explicitly using messages - when loading the M4L device and before sending your message?
I'm not in front of my pc (so i can’t test it) but I thought it could be an initialization problem...
@pjeve : I'll try, but with not much faith. As when the ports die, they won't work anymore even after manually re-typing the port in the object box.