jit.net.recv - whatever I do, it doesn't work


    Jul 20 2015 | 7:21 pm
    Hi all, I'm trying to establish a connection between two Max 7 patches running on two Mac OS Machines running Mac OS 10.10. Whatever I try, I cannot establish a connection with jit.net.recv. I found these two forum threads where folks had issues:
    I am able to establish a connection when the ip address is set to 127.0.0.1 on both jit.net.send and jit.net.recv running inside the same patch. But no luck when trying over network via a wireless router with the firewall disabled and no firewall active on both computers. Both computers are running Max in 32 bit mode.
    Is the following setup correct, or have I misunderstood something? Sending computer with ip address 192.168.1.33: Object text [jit.net.send @ip 192.168.1.34 @port 7474] Receiving computer with ip address 192.168.1.34: Object text [jit.net.recv @ip 192.168.1.33 @ port 7474]
    I have also tried various port settings. Am I doing something wrong?
    Best, Matthias

    • Jul 21 2015 | 12:46 am
      just for diagnostics, try eliminating the wireless router and connect the two computers directly with an ethernet crossover cable
    • Jul 21 2015 | 4:34 am
      Unfortunately, one of the computers is a new MacBook Pro with Retina display, so no ethernet port. I'll try some more with OS network settings, apart from that I'm at a loss..
      But thanks anyway..
      Matthias
    • Jul 21 2015 | 4:39 am
      What I haven't tried is to run Max in "Low Resolution Mode" on the Retina machine. I don't know, but I'll just try some more..
    • Jul 27 2015 | 6:30 am
      OK, I got it working this weekend. The trick was to find a free port (port 7474 never works in my setup) and having the jit.net.recv listen to ANY ip address on the network. As soon as I specify an ip address for the jit.net.recv to listen to (and I know the ip address where the signal is coming from), the connection breaks.
      Did anyone have a similar experience?
      Best, Matthias
    • Jul 27 2015 | 8:22 am
      I've got a similar problem within max7. The ports 7474 to 7477 are not seen as free and jit.net.send the connected attribute is set to 1 when something is send. But it works if I put @ip 127.0.0.1 in jit.net.recv (sending from the same computer).
      And even if it works, I've got these messages in the max console when the jit.net.recv object is instanciated: binding method unsuccessful there is probably something already bound to this port.
      It works fine in max6 on the same computer when max7 is closed, but can't receive in max6 on 7474 to 7477 without @ip 127.0.0.1 in jit.net.recv.
      Jean-Michel
      { "version" : "Version 7.0.2 (5919d1e) (32-bit mac)", "platform" : "mac", "arch" : "x86", "osversion" : "Mac OS X Version 10.9.5 x86_64", "samplerate" : 48000, "iovs" : 512, "sigvs" : 512, "scheduler_in_audio_interrupt" : "off", "audio_drivername" : "Core Audio", "audio_driver_subname" : "", "license" : "permanent full", "machine_id" : "b7efcb282c00165522f59158dfd90930", "eventinterval" : 2, "overdrive" : "off", "mixerparallel" : "off", "mixercrossfade" : 0, "mixerlatency" : 30.0, "mixerramptime" : 10.0, "videoengine" : "avf", "packages" : { "Beap" : { "name" : "BEAP", "type" : "package", "author" : "Matthew Davidson, Peter McCulloch", "description" : "BEAP (Berklee Electro Acoustic Pedagogy) Modular is a synthesis pedagogical tool.", "version" : "Master from GitHub", "major_version" : "0", "minor_version" : "0", "min_max_version" : "612", "min_osx_version" : "None", "min_win_version" : "None", "website" : "https://github.com/stretta/BEAP/wiki", "link_mac32" : "https://github.com/stretta/BEAP/archive/master.zip", "link_mac64" : "https://github.com/stretta/BEAP/archive/master.zip", "link_win32" : "https://github.com/stretta/BEAP/archive/master.zip", "link_win64" : "https://github.com/stretta/BEAP/archive/master.zip", "relative_path" : "None", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/Beap", "vol" : -451 } , "Gen" : { "name" : "Gen", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/Gen", "vol" : -452 } , "Jitter" : { "name" : "Jitter", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/Jitter", "vol" : -453 } , "Max for Live" : { "name" : "Max for Live", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/Max for Live", "vol" : -454 } , "MaxDefaultContent" : { "name" : "MaxDefaultContent", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/MaxDefaultContent", "vol" : -455 } , "MaxIntroLessons" : { "name" : "MaxIntroLessons", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/MaxIntroLessons", "vol" : -456 } , "mira" : { "name" : "Mira", "type" : "package", "author" : "Cycling '74", "description" : "Mira automatically connects to Max and mirrors your interface.", "version" : "1.1.8", "major_version" : "1", "minor_version" : "1", "min_max_version" : "7.0.2", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/mira", "vol" : -457 } , "vizzie" : { "name" : "vizzie", "path" : "yetipro:/Applications/Max.app/Contents/Resources/C74/packages/vizzie", "vol" : -458 } , "Max" : { "name" : "Max" } , "MSP" : { "name" : "MSP" }
      }
      }
    • Jul 27 2015 | 8:30 am
      From my experience over the past weekend, I can tell that every network configuration works with various port settings. Instantiate a jit.net.recv without specifying an ip address, hook up a message box to the jit.net.recv inlet containing the message [port $1]. Connect an int number box to the message and scroll through port numbers until the Max console doesn't complain with the "binding method unsuccessful" message.
      On the other (sending) machine, set the ip attribute of the jit.net.send object to the ip address of the computer you want to send the video to and use the the port number you have just found on the receiving machine.
      This fixed it for me. The only thing I'm puzzled about is why I can't specify the ip attribute of the jit.net.recv object on the receiving machine..
      Best, Matthias
    • Jul 30 2015 | 11:22 am
      I have been in contact with support about this issue. It turns out I have completely misunderstood the IP monitoring concept of jit.net.recv. The jit.net.recv object actually monitors the IP address (if specified) a jit.net.send object has formed a connection with.
      Ben from C74 support wrote this: "The @ip attribute of jit.net.recv is the IP address to monitor for incoming connections. The @ip attribute of jit.net.send is the IP address to form a connection with. Therefore, these need to be the same on the send and receive side. In your setup, your jit.net.send will never be received by jit.net.receive, as it is listening to a completely different IP address."
      So if I have three computers with IP addresses (1) 192.168.1.33, (2) 192.168.1.34, and (3) 192.168.1.35 and if I have a jit.net.send object on computer (1) with the @ip attribute set to the IP address of computer (2), I can set the @ip attribute of a jit.net.recv object on computer (3) to the IP address of computer (2) and still receive the matrix.
      Got it? ;-)
      Best, Matthias
    • Jan 26 2016 | 5:46 pm
      I've just gotten this stuff working between two machines (in preparation for a discussion about networking) but I don't quite understand the description above:
      I had assumed that, under the covers, [jit.net.recv] implemented a standard TCP listening server on some (possibly default) port on the machine where you instantiate the object. But if the description above is correct and I can set the ip address of a [jit.net.recv] to an IP address of some other computer, then how is a listening server being created?
    • Jan 26 2016 | 11:46 pm
      the listening server's IP address is always the address of the device it is instantiated on, so there is no need to explicitly specify it
    • Jan 26 2016 | 11:51 pm
      Well, that's what I would have expected (and was the first thing I tried) on the assumption that a [jit.net.recv] implements a standard listening server but in fact that didn't work, which is why I started looking around and found this thread. I had to explicitly define the IP address, even localhost (127.0.0.1) didn't work.
    • Jan 13 2018 | 11:19 am
      Thank you, Matthias! I managed to work this through thanks to your help. Too bad they don't write this down in the description of the object. By the way, anyone managed to make this work over the internet? That is my next challenge
    • Jan 13 2018 | 11:22 am
      I added the comments. receiver
    • Jan 13 2018 | 11:23 am
      sender