Message-Id: <9010252350.AA01690@jenzy.labs.tek.com>
To: vex@expo.lcs.mit.edu
Subject: The review process of VEX
Reply-To: toddb%sail.labs.tek.com@relay.cs.net
From: toddb%sail.labs.tek.com@relay.cs.net
Date: Thu, 25 Oct 90 16:50:10 -0700
Sender: toddb%jenzy.labs.tek.com@relay.cs.net

Although I have voiced and written this to individuals, I should say this
here.

The VEX protocol document defines fairly rigid semantics for video input,
video output and connectivity.  The device control described in the VEX
protocol is a raw mechanism whose semantics are defined elsewhere, so if you
look at just the protocol document, there is not enough information to guide
you.

The VEX Devices and Controls document defines a partial set of device
controls that conveniently address the first problems I had to solve:
namely, operating a shuttle on a video recorder/player, and adjusting
the hue, brightness, etc., of a decoded video signal.

Privately (and I intend other companies to do the same), we had defined
some controls that adjusted other aspects of Tek's video input and
output devices, such as warp, skew and other filters.  These controls
are interesting to us, but I don't see them yet as interesting to
the rest of the VEX/X community.  Similarly, other companies
will define controls for their video devices to adjust or accomplish
non-X tasks that directly affect what happens on the X display.
And I suspect that there will be some that define controls that
flush the toilet, dial a modem, and check their car's fluid levels,
but I can't stop that.

I believe that the VEX protocol, is well defined and except for a small change
for the sake of connectivity that I'll propose shortly (another event), it
doesn't need more changes.  I'd like this forum to endorse that view, or at
least help me adjust it to the point of endorsability.

However, as I've intimated above, the VEX Devices and Controls document is not
yet ready to be standardized.  As I talk with video experts I find small
things to change and other basic controls that are missing.  I envision the
final set of (standard) controls to address the following classes of tasks:
   Video Record/Playback
	This is fairly complete in the current document, but needs more
	functionality, such as pre- and post-roll.
   Video input/output synchronization
	This is one of my current tasks, and defines what frame a
	following RenderVideo or CaptureGraphics refers to.
   Video input/output adjustments
	This addresses non-X things like signal hue and saturation.	
   Edit ability
	This class of controls would address the functions performed
	by an edit controller.  I'm trying to get a Grass Valley edit
	controller so I can learn what the production industry already
	knows about this, rather than making it up from scratch.
   Sound
	Most production switchers/routers/etc view audio media the
	same way they view video media; i.e. play, rewind, record
	is all the same operation, but a different device.  For this
	I need to review the first class (above) and see that it
	is general enough for sound, too.
   Sound Synchronization
	This kind of control would express how a sound track
	is supposed to fit with a video track.
   Sound input/output adjustments
	This addresses non-X things that correspond to video, such
	as volume and tone.

In summary, what this group should be standardizing is the VEX protocol,
not the Devices and Controls document.  But as a paradox, the Devices
and Controls document must serve as an example for how the raw
control mechanism in the VEX protocol should/can/will be used.

Then later, after the VEX protocol is settled, or nearly so, and I
have a more complete set of controls, we can standardize it.

I pray this makes sense.
---------------
internet: toddb@sail.labs.tek.com                                   c--Q Q
US:       Todd Brunhoff; Systems Architecture and Imaging Lab;          `
          Tektronix, Inc.;  Box 500  MS 50-321, Beaverton OR 97077      -
Phone:    (503) 627-1121