Virtools Network Sync Manager

# 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!

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