[AG-TECH] mute control.

[Lawrence A. Rowe]

hi -

we developed our AG facility so that *every* a/v device and computer can
be controlled from a computer - that means implementing an rs232 or IR
interface to each device.  then, you can use tcl/tk to write GUI
interfaces to control anything (e.g., routing switchers, pan/tilt
cameras, mixers, projectors - such as switching from RGB to NTSC/PAL and
turning them on/off, etc.).

we have a generic tcl server that can be easily modified/extended to
send the appropriate text commands to a device over the interface.  the
rs232 interface code is simple since tcl has a socket abstraction that
allows you to talk to serial ports. you can also purchase a board for
linux or windows that sends text commands out over an IR interface to a
device (e.g., tape the LED to the remote control window on the device).
i think that board also looks like a serial device.

the gentner audio mixer has an rs232 interface so it would be easy to
implement the server to talk to it.  now, you need user interfaces.  we
typically develop small tcl/tk scripts with GUI's that provide the
operational interface you want.  these commands do TclDP RPC's to the
server which pass the commands on to the device.  so, you could
implement several different scripts -- one for master control operators
and one for participants.  the participants could run their scripts on
laptops or pdas connected via wireless network so that RPC's can be sent
to the server.  you could even allow the master control operator to
configure the state of the control system so participants cannot
override his/her decisions.

for example, we use multiple routing switchers to manage webcasts
produced from different classrooms.  we have one client script that
gives a guru complete control of all sources and destinations w/o having
to know the actual connections between the switches.  however, webcast
operators, who are typically undergrads trained in 1-2 hours, only need
to control the sources in a particular room -- so we wrote a different
client that just provides the controls for the sources in a specific
room with the interface identifying the various cameras and video
sources (e.g., "Speaker", "Stage", and "Audience" cameras, VCR, and scan
converter).  most webcasters find it easy to learn and use.

developing these client/server scripts is relatively easy.  we have
undergraduates write new services and client scripts after 2-3 weeks of
training and giving them one of the existing client/server programs as a
starting point.  the good thing about all this is that it is extremely
portable.  we run client programs on any platform and connect to servers
that run typically on the control computer in the AG configuration -
which given modern processors also serves as our audio machine.

i have had a lot of experience with traditional a/v control systems
(e.g., amx, crestron, etc.).  i find them expensive and difficult to
modify - you have to use their proprietary cruddy scripting language
and, if you want to connect it to the Internet you need another server
sitting next to it to forward commands to the control computer through
an rs232 interface.  this configuration introduces significant latency.
also, having the control software in a specific computer that may or may
not be easy to modify makes it much harder to manage the sofware. 
change is difficult and error prone -- hence, most operational folks
don't want to change it very often which impedes new development and
experimentation.

that's why the model should be "use a general purpose computer" with a
open source scripting language for control rather than using an "oem
customized computer" with a proprietary scripting language.
	Larry
-- 
Professor Lawrence A. Rowe          Internet:  Rowe at BMRC.Berkeley.EDU
Computer Science Division - EECS       Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776            URL: http://bmrc.berkeley.edu/~larry