jit,net.recv not working in MAX7?
jit.net.recv which is working fine in MAX6 is not working in MAX7. The help example is also not working (windows 7)...
Can anyone verify? Thanks
I can confirm. changing the patch like this solve it but it still has error message in Max window on open.
-Max Window-
binding method unsuccessful
there is probably something already bound to this port.
-
Both the help patch and FP's fix are working and post the error in Max 7.0.1 on OSX 10.8.5.
Help patch on Win 8.1 and Max 7.0.1 works and shows no error.
CORRECTION: the help patch doesn't work on win8.1 but posts no error.
The jit.net.send help patch works fine.
I am having trouble getting jit.net.recv to connect remotely from a jit.net.send on another machine in Max 7.2.2 on OS X 10.11.5. Port binding does not work, although when I attempt to change jit.net.recv's attributes I tend to get one frame from the video source before it stops working.
Crappy, slow network connection is partially to blame in my case. After blindly port hunting for something that wasn't bound (7480, but I don't ever remember it being this difficult to find an open port while doing OSC stuff??), and shrinking down my webcam resolution to unreasonably tiny (320x240), and lowering the metro framerate (40ms), I got something that had ~12sec latency.
Then, when I tried switching to an ad-hoc WiFi configuration or using a crossover cable, that same port was bound again and hunting for a new one turned up nothing.
Something about Max's ability to bind and hold onto a port for TCP with these two objects is messed up in the newest versions of Max 7.
I just tried a udpsend/udpreceive test and then a mxj.net.send/mxj.send.recv pair with the same ports (7474 first, then another test with 8000) and they both worked fine. So the problem is with jit.net.recv specifically. Running everything in 64-bit and 32-bit.
i'm still experience the same issue (Max7.2.5. MacOS 10.9.5. September 2016).
all the best!
jmb
This default port of 7474 is being used elsewhere as of Max 7 (sorry about that), so I'd suggest explicitly using another port number (needs to be set both on the send and recv object). For me, if I use 7480 for example it works fine, and we can update this default in a future version. FWIW, if there's a firewall setup or http proxy you might have other issues.
The reasons others saw udpsend/udpreceive working with port 7474 is that the UDP port space is different than the TCP port space.