This plugin will add master/slave networking to Virtools. It's been created for use in a passive stereoscopic setup and will sync the slave to the master system. It's been created for a research about historical stereophotographics and stereographics for use in theatre performances. This research was initiated by Stichting Lange Poten. The plugin was written by Knip 'n Plak coder wreck and myself.

• VNetSync version 1.02b
• VNetSync version 1.01b
• VNetSync version 1.0b

• VNetSync version 1.02b source code
• VNetSync version 1.01b source code
• VNetSync version 1.0b source code

Thanks to Gilles Pinault who provided us with a Virtools Dev 2.5 version.

• VNetSync25.zip

It's “b” of *beta* fyi

• Virtools Dev 2.1
• Network interface using TCP protocol

If someone would be kind enough to compile this against Dev2.5 we will be able to provide a Dev2.5 version.

Just copy the DLL into your 'managers' directory. When you start Virtools you will find a new section 'Building Blocks - Net' in which you'll find two Building Blocks:

This is the NetSync master Building Block in which you can set the following settings:

• socket_on(boolean): Will enable or disable the socket when playing
• hostname: set the hostname of the slave machine
• port: set the port number to use

The Building Block accepts a vector and a matrix as input to sent to the slave. It outputs the status of the network manager (master or slave).

This is the NetSync slave Building Block in which you can set the following settings:

• socket_on(boolean): Will enable or disable the socket when playing
• port: set the portnumber to use

The Building Block outputs the vector and matrix send by the master. If the master pauses or resets the slave will also stop playing.

This plugin is copyright 2004 sphaero.org/KnP/Lange Poten. All rights reserved. The plugin has been released under the Gnu Lesser Public License for others to enjoy.

We would like to know if people are using this plugin for any purpose. If you make modifications or additions to this plugin you are obliged to provide the source to us to include it into future releases of the plugin.

Problems or questions please contact us by email

# v1.01b 14-01-04
- fixed mixed up defines

# v1.01b 13-01-04
- fixed master socket start when not set on

# v1.0b - 09-01-04
- release date!

We've received the following mail from studentrs from the Aalborg University Copenhagen. Their source code is also available here.

Hi there,

I am a part of a group of Medialogy students from Aalborg University Copenhagen
(AAUC). We needed the possibility of streaming a processed camera image to a
texture in Virtools, and thanks to your open source for VNetSync
(http://www.sphaero.org/projects/ns/), we managed. Based on that code, we added
two more BBs, called NS_Client and NS_EYWServer, which essentially are examples
of a TCP client and a TCP Server. Since our solution builds so heavily on your
project, we would very much like to see our source code be posted on your web
page, together with the VNetTCP sources - if possible.

Please find the package with the source code and example files here (a similar
version of this text is also included there as a readme):
http://www.smilen.net/VNetTCP_source_send.zip

NS_Client is meant to connect to a Max/MSP patch, utilising a flashserver object
(which behaves like a listening TCP server). NS_EYWServer is meant to connect to
an EyesWeb patch, utilising a SendToNetwork block (which behaves like a TCP
client). The current programming reflects those specifics - for instance,
NS_Client adds trailing ";"s which flashserver needs, and NS_EYWServer reads 56
bytes of header that EyesWeb sends at the beginning of each stream. NS_EYWServer
is currently programmed to receive 128X128 grayscale images from EyesWeb, and
display them on a texture of the same dimensions in

The installation is the same as for the VNetSync - the dll has to be placed in
/Managers folder of Virtools installation. For computers that do not have
Visual Studio installed, two more dll's are needed in the windows/system32
directory if the BB's are to show up in Virtools - those are msvcp71.dll and
msvcr71.dll. The current VNetTCP.dll was compiled with VS .NET 2003 against
virtols Dev 3.0. There are example files in the folder, meant to demonstrate
the functionality on one computer (via 127.0.0.1 and different ports) although
we have run the plugin in a LAN context.

To test NS_EYWServer, open both VNetTCPTest.cmo in Virtools and
VNetTCPvinceTestMouse.eyw in EyesWeb (the patch is for EyesWeb 3.3.0). Then
press play in VNetTCPTest.cmo - Virtools will start blocking (for max 10
seconds) waiting for a connection. Immediately switch to EyesWeb and start the
patch - as soon as the connection is established, the received texture from
EyesWeb (in the example, composed out of the mouse movements) will be rendered
in Virtools. The connection has to be established during the 10 blocking
seconds. The ending of the connection between EyesWeb and Virtools is not
properly solved so it ends ungraciously - so restart of the EyesWeb patch is
required once a connection has ended. The texture has to be a target parameter
- it would probably be better to have it as a pOut, if possible. Also, the
socket operation was made non-blocking - it would probably be better to have a
separate thread run the recv in blocking mode, but we did not go there..

To test NS_Client, open VNetTCPflashserverTestFader.mxb in Max/MSP first - since
it will activate the flashserver object, so it starts listening to port 31337.
Then open and start VNetTCPTest.cmo - since NS_EYWServer is present there, it
will still block for 10 seconds upon start, but that is not necesarry to
connect to the flashserver in Max. You may want to try deleting the
NS_EYWServer block to avoid the 10 blocking seconds in this context. Once
connected, in VNetTCPTest.cmo you can click the Connect button (which has a
misleading name - it simply activates the processing feedback loop of
NS_Client) to see the received data from max. The data is received as a string,
although here the block also has an integer output - basically, if the string
describes one number, you will get it as an integer as well, and in the example
in Max, moving the fader creates such a string - and in Virtools, that is mapped
to the z position of the cube in the example. One can send strings to Max/MSP as
well - click the "Send to Max" button in the Virtools example.

The examples can also run together - just run VNetTCPflashserverTestFader.mxb
first, then open VNetTCPTest.cmo, then open VNetTCPvinceTestMouse.eyw - then
run the VNetTCPTest.cmo to start the blocking and switch to EyesWeb and start
the patch. Once started like this, switch ot Virtools, click on "Connect" to
activate the feedback loop for processing Max data, and you can see all of them
in action.

As we are not all that familiar with the Virtools SDK nor the details of
operation of VNetSync, a switch was added which simply bypasses Master/Slave
processing if client/EywServer are present - else it should normally continue
the Master/Slave operation. Maybe it would be better to separate them somehow,
so they can run in parallel? - but in any case, the design demands that a
single Network Manager manages them all?

Well, in any case, if you find it worth your while, you are welcome to introduce
any advances to the code (and we would be happy to see them and learn as well).
We would just ask to be listed as "a group of Medialogy students from Aalborg
University Copenhagen" as contributors, if applicable.

Again, thanks for sharing your great code, and please let me know if we can see
our sourcecode posted on your page..

Best regards,
smilen