Great work, Dana!

We already have some programs that monitor events in the VR world and send
data over a socket to PD programs, which then write this data to the
parallel port.  It's no harder to go in the other direction (MIDI keyboard
-> PD -> socket -> VR agent).  Also, I think that Glenn has been working on
self-contained PC clients, which will eventually eliminate the need for PD.

I haven't tried using PD for MIDI input, so I've never seen the "clogging"
behavior you describe.  This seems like something we should look into this
week. 


Robert


   Date: Mon, 02 Aug 1999 19:23:01 -0400
   X-PH: VBU-4.3.UCUSSP.RESOLVER@bu.edu
   From: Dana Moser <dmoser@massart.edu>
   Reply-To: dmoser@massart.edu
   Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   Sender: owner-hipart-list@bu.edu

   Greetings-

	I got a motion detector (electrical switch) to play
	a note on a MIDI keyboard, which sent a note-on event
	thru a standard MIDI interface into a win95 PC running pd.
	Then pd used "netsend" to pass the note number to another
	machine on our campus network, also running pd. It, in turn
	used "netreceive" to get the number. Then thanks to Etienne's
	DLL, pd was able to pass the numerical value to the parallel
	port as a binary ascii pattern. Since the port was attached
	to one of the I/O boxs we built here at MassArt, the binary
	pattern was converted into a pattern of individually
	addressable output voltages (translates into on/off switches).

   This means:
     1- Any sensor-driven on/off switch we can make in the physical
	world can send information to a PC or Unix machine on the
	same network. 
     2- And also- by interpreting change-of-state information into 
	numbers that pd can send over the network, events in the 
	virtual world can switch devices off and on in the physical world.

   A few of questions I had:
     1- Has Robert or someone written the necessary "translator function"
	that can take the data sent from a machine running pd and output
	it in a form that makes sense to your VR network protocol?
	Or is that even necessary, since pd is just opening a socket
	and sending integers, strings, floats, or whatever...?

     2- When pd is initialized with the parallel port ExTest lib, the
	pd window prints the message, "dacs died... Switching to alternate
	time source." Does anyone know what that means?

     3- With the I/O box I have here and the one at BU, we have a total
	16 switches that can be controlled by the virtual world. I have
	a Grad student working on finishing a couple more, but I don't know
	how long that will take. My question is: "Are we even close, or
	is there something that is going to need 2 dozen inputs or more?"
	There are commercial products in the $100-$200 range; I/O boards
	with many more ports, if we need to get such a thing in a hurry,
	but even then, it's not clear what will be involved in writing
	the code necessary to interface it with pd.

     4- pd has been running in a way that I can only describe as "flakey".
	(Suddenly clogging-up and not receiving midi data, having to
	do re-starts, etc...) Robert, if it seems to be relatively stable
	for you, can you tell me the configuration of the machine you're
	running it on? We're using a 450mhz AMD K-6 -but with only 64 megs
	of RAM. Maybe pd needs a lot of RAM?

   I'm putting together some toys that might be fun for thursday; just to
   see some interaction between physical objects and the virtual world.

   Hope you are all staying cool.

   -Dana Moser

Created for the Boston University/SCV Projects Page.

Created by The CoCoBoard.