[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AG-TECH] mute control.

Your message:
> Is the tcl server available?
>
> -randy

Randy -

Yes, the code is all in the Open Mash CVS archive.  It is not
well-structured or documented, but as I said it is pretty easy to learn
and modify.  We have built clients and servers that run as Open Mash
scripts and that run as Tcl/Tk scripts.  The mash scripts are in
mash-code/mash/tcl and the tcl/tk scripts are in mash-code/apps.  here
is a list of a couple of the applications:

1. mash/tcl/{rcc,rccd} - wei developed a camera client/server that
defined the model for a general camera server.  we use the Parkervision
controls here for webcasting classes from several classrooms.
2. apps/vcc3 - client/server app for controlling a canon VCC3.  i had a
student working on support for the newer VCC4 this semester, but i don't
think it got checked back into the archive.
3. apps/rswitch - gui for a routing switcher.  this is the client.  it
uses the nway server which i don't know where it is. 

(Peter, do you know where the nway server is and the other client that
we use for webcasting in Soda?)

4. apps/amx - server to execute operations in an AMX control computer
through an rs232 interface.
5. mash/tcl/applications/avswitch* - client/server for a routing switch.
6. mash/tcl/applications/powerswitch* - <not sure what this does, it
probably controls the lutron lighting system installed in our building>
7. mash/tcl/applications/camera-* - an early camera client/server.

some of these control apps were designed to work with the Director's
Control (dc) application we developed for producing a webcast.  As such,
they fit into a larger framework that included a service discovery
protocol and a soft-state protocol (Announce/Listen) that was very
reliable.  if you want to read about the research behind all this work,
the paper on Streaming Media Middleware surveys the systems and
requirements for building and maintaining it. The paper is at
	http://bmrc.berkeley.edu/papers/2001/159/
Other papers on dc and the automated control of webcasts are available
at http://bmrc.berkeley.edu/papers/.

So, which system/package should you start with.  I would recommend you
look at mash/tcl/rcc*.  the server is very simple and it shows how TclDP
is used to setup a client and a server and how RPC commands are done to
control things.

We have implemented a number of apps for our AG colab.  I am not sure
they are in the current archive.  We will do that shortly.

This code probably looks like a mess since it is all ad hoc.  We found
the dc implementation and model hard to extend to other applications, so
we began development of a middleware package for controlling distributed
media resources.  The goal was to simplify the development of
applications that required control of conventional a/v equipment and
streaming media applications.  Rather than building a bunch of
customized special-purpose apps, we wanted to create a common library
and infrastructure for doing a variety of control and automation tasks.
My biggest objective is to reduce the need for human operators because I
believe that limits the widespread deployment and use of this
technology.

The system we designed and began to prototype was called INDIVA, which
is described at http://bmrc.berkeley.edu/projects/indiva.

If you have any questions, send them to the Open Mash developers list
which you can join at http://www.openmash.org/.

Enjoy!
	Larry
-- 
Professor Lawrence A. Rowe          Internet:  Rowe@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

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@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