Message-Id: <9010252350.AA01674@jenzy.labs.tek.com>
To: dcc@ATHENA.MIT.EDU
Cc: vex@EXPO.LCS.MIT.EDU
Subject: Does VEX provide frame accuracy
In-Reply-To: Your message of Fri, 19 Oct 90 16:06:45 -0400.
             <9010192006.AA28650@BOOM> 
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:00 -0700
Sender: toddb%jenzy.labs.tek.com@RELAY.CS.NET

>   The basis of my position is that VEX does not support frame accurate
>   synchronization.  If Todd is achieving frame accuracy, it is his
>   equipment and implementation that achieve it despite the lack of
>   synchronization semantics between independent VEX requests.

I'm disappointed by this statement.  As before, you have reached a conclusion
without proving it.  Nowhere in this or other messages do I see an example
giving a sequence of events with a narration that proclaims "here you cannot
acheive frame accuracy".  So let me see if I can help you out.

As the current documentation stands, the VEX protocol document defines video
input, output, connectivity and a raw mechanism for device control.  The VEX
Devices and Controls document defines 16 rather low level controls, including
mechanisms for shuttling video players/recorders and one for adjusting the
hue, brightness, saturation and contrast.  These by themselves do not define
any mechanism for frame accuracy, but what I may have wrongly assumed it was
intuitively obvious that such a system could be used to acheive frame
accuracy.  I was, at least, to some people I have talked with.  My mistake.

From a practical standpoint, I defined the mechanism first that I needed
just to get a demo system running: the ability to jog, play a segment
of frames, etc.  Currently, I am working on a higher level set of controls
that would address some of the things I'm talking about.  For example:
    VEX_SYNCHRONIZE
	This defines a frame of interest for a following RenderVideo
	or CaptureGraphics, meaning that (if your hardware was capable)
        you could digitize a particular frame from a full-motion segment.
    VEX_EDIT
	This defines edit sequences much the same way that an edit
	controller would, such as a Grass Valley 141 or 151 edit
	controller.

Had you not realized that you could use this mechanism to do these tasks,
or you thought that what was defined in the VEX Devices and Controls
document was the final set (or you were playing devil's advocate),
I can see the reason you think I did not have frame accuracy.

Let's dig deeper.

You say if I am
  "achieving frame accuracy, it is his equipment and implementation that
   achieve it despite the lack of synchronization semantics between
   independent VEX requests."
Well, a system's design defines the scope of its implementation.
Consider the multi-buffering extension.  Essentially, it defines a
mechanism to switch buffers, and that definition gives you the
ability to have real-time animation; real-time in the sense that
each frame of graphics can be displayed synchronous with the vertical
retrace of the workstation display screen.

The one request to "switch buffers" enables the X system to gather
all the graphic requests preceeding it and display them in a single
instant.  The request essentially marks the end of a frame.
If that request didn't exist, there would be no way for the X server
to infer where the frame ended, or started for that matter, and therefore
it wouldn't matter how good your hardware or implementation was,
frame-synchronous animation would be impossible!

In summary, we have three elements
  - an implementation that handles real-time aspects
  - hardware capable of real-time response
  - most important, a system design that allows you to express something
    that happens in real time.

Certainly I have the first two, but without the third, I have nothing.
And this is what the control mechanism will allow me to do.

Take any of the examples I have mentioned before and imagine a control
designed to accomplish it, something that would pull together all the
elements needed for whatever the real-time task is that you want to do
(like the multi-buffering extension's "switch buffer" request).
I'm sorry I don't have one published for you to see.  Soon.
Remember, our workstation division was canceled two weeks ago today,
and the research laboratories is just now realigning the VEX effort
with other interested Tek divisions.

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