object allows us to send uncompressed matrices over the Internet to a jit.net.recv
object in a Max patch on a different computer.
• In the Jitter Tutorials folder, open the tutorial patches 52jNetworkSend
. If you like, you can open these on different computers.
objects communicate using the TCP protocol. A discussion
of the different types of network transmission protocols is beyond the scope of this
Tutorial; it’s important to note, however, that TCP is a connection-oriented
Before anything can be sent or received the pair of objects must make a connection to one
another. Both objects report any change in their connection status out the dump outlet
with a message, followed by an argument of when connected or when disconnected.
A patch to send Jitter matrices over a computer network using TCP.
To form a connection, the jit.net.recv
objects must be set to “listen” to the
. We can set the attribute to any positive integer value, but some of the lower numbers are reserved for commonly used network services such as FTP, web browsing, etc. A port in the range above 1024 and below 10000 will probably be safe. If no port is specified, the default for both objects is 7474.
In addition to jit.net.send
object must know the IP address
computer running the Max patch containing the jit.net.recv
object we’d like to send to. A
computer may have more than one IP address – the wireless interface and Ethernet port
will have different addresses, for example – and, by default, the jit.net.recv
object will listen
to all of them for a connection request from a jit.net.send
suitor. It is possible to specify
which interface to use by sending the object an message with the specific IP address of the desired interface as an argument.
If we open the sending and receiving patches on the same computer, the objects may
immediately form a connection. The toggle
boxes connected to the route
objects in each
patch will be checked if this is the case. By default the jit.net.send
object’s attribute is set
to , which is the local loopback
address. The jit.net.recv
object is listening to all
addresses by default, including the local loopback, so a connection should be made if the
two patches are on the same computer. If you’re running the patches on different
computers, you can use the mxj net.local
object to figure out what IP address the jit.net.send
object should be trying to connect with. Note that one can specify an IP address with the
attribute, or alternatively one can specify a hostname
with the attribute and jit.net.send
will attempt to use the Domain Name Service (DNS) to resolve the hostname to an IP address.
A patch to receive and display Jitter matrices sent over a computer network.
If you can’t get your objects to connect to one another, and you’re sure you’ve got the IP address and port correct, make sure a software firewall on any computer isn’t preventing communication on the Control Panel:Windows Firewall:Advanced tab, where double clicking any of the network connections will bring up an Advanced Settings window that allows you to define new “services”. On an OS X machine the controls for the software firewall can be found in System Preferences:Sharing:Firewall, where you can click on the New… button to specify a port to open. If you are connecting two computers together through one or more routers, it’s possible that they have filters in place that are rejecting the packets.
we’ve selected ( in these tutorial patches). On a computer running Windows XP, the controls for the software firewall can be found in the
• Turn on the toggle
box connected to the qmetro
in the 52jNetworkSend.pat
In the sending patch, a jit.qt.movie
object is sending matrices to a jit.net.send
that the qmetro
driving the movie playback triggers the movie frame and then sends the
object a message. This causes a one-way latency estimate to be output from the dump outlet. We can use this estimate of the transmission latency to synchronize events on the two computers, for instance by delaying the processing or display of a matrix on a local computer by the amount of the estimate, at which point the receiving computer should be ready to process the matrix it has received.
Latency is influenced by two factors: the direct transmission time between the two computers, and the amount of data being sent. The more data that is sent, the longer the time it takes to move all the data across the network. Obviously the speed of the computer’s network interface and all routing hardware is key in this respect – the transmission can only be as fast as the weakest link in the chain. One technique we might consider using to reduce latency is to transmit matrices using either of the grgb or uyvy compressed color spaces that are discussed in Tutorial 49.
In addition to sending matrices, any normal Max message input into the right inlet of
will come out the middle outlet of the connected jit.net.recv
object. The input
order of messages and matrices will be preserved in the receiving patch. In this example,
named contains a slower qmetro
that changes the dimensionality of
the movie every half second. These new dimensions are input into the right inlet of the
object. When the two integers come out the second outlet of the jit.net.recv
object they are used as the arguments of the message to resize the jit.pwindow
The matrices in this tutorial patch are of type jit.net.send
handle matrices of any type. For an example that uses matrices, please refer to
in the jit-examples/audio
Using the jit.net.send
objects, you can send uncompressed Jitter matrices to another computer running Max. You specify a for the two machines to communicate on, as well as an address for the sending machine to use when connecting to the receiving machine.
Receive matrices from a
object via TCP/IP
Send matrices to a
object via TCP/IP
Play or edit a QuickTime movie