################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally presented at the Third Annual Tcl/Tk Workshop Toronto, Ontario, Canada, July 1995 sponsored by Unisys, Inc. and USENIX Association It was published by USENIX Association in the 1995 Tcl/Tk Workshop Proceedings. For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: https://www.usenix.org ^L Prototyping NBC's GEnesis Broadcast Automation System Using Tcl/Tk Brion D. Sarachan GE R & D Center P.O. Box 8, KW C273 Schenectady, NY 12301 Phone: (518) 387-6553 Email: sarachanbd@crd.ge.com Alexandra J. Schmidt GE R & D Center P.O. Box 8, KW D218 Schenectady, NY 12301 Phone: (518) 387-7271 Email: aschmidt@crd.ge.com Steven A. Zahner National Broadcasting Company, Inc. Broadcast and Network Operations 30 Rockefeller Plaza New York, NY 10112 Phone: (212) 664-7109 Email: zahner@oandtsvt.nbc.com ABSTRACT As part of the re-architecture of their television broadcast transmission facility, NBC is using Tcl/Tk in developing a prototype system, known as GEnesis, for monitoring and editing on-air television broadcast schedules. This paper discusses application of Tcl/Tk and its extensions to rapidly prototype a highly-interactive GEnesis user interface that leverages the power and flexibility of the Tk widget set. In particular, canvases are used to implement custom graphics, while tags and the binding mechanism enable a high degree of interactivity. The ability of Tcl/Tk to work seamlessly with other, heterogeneous software components enables the GEnesis system to combine its custom Tcl/Tk user interface with a Sybase database and C-based device controllers. We address a number of implementation issues including the handling of display updates and managing the Tcl data space. KEYWORDS: Tk-based user interfaces, Tcl-based database interaction, interprocess communication, broadcasting operations. INTRODUCTION NBC's GEnesis project comprises a general re-architecture of NBC's end-to-end television broadcast process. A particularly important part of GEnesis concerns the monitoring and control of program streams--the continuous sequence of television program and commercial events which are combined in varying ways according to local affiliate station needs, then routed by satellite to the correct groups of stations. NBC is presently prototyping GEnesis in conjunction with the General Electric Research and Development Center. This paper focuses on the use of Tcl and Tk in developing the prototype's architecture and display. Several requirements shaped the design and implementation approach. Broadcast schedules are extremely complex and are, in fact, multidimensional; schedules differ for different geographic regions; schedules are modified over time (sometimes up to the last moments before broadcast); alternate contingency schedules are routinely created to allow coverage for world news events. GEnesis poses the challenge of graphically representing and tracking this complexity of schedule information. Although schedules are stored in a database prior to airing, the frequent need for close-to-air-time modifications mandates an intuitive user interface that provides quick access to and understanding of the extremely complex schedule information and also allows easy schedule edits that minimize the need for extensive typing--a common source of potentially-costly schedule errors. Finally, the entire prototype architecture needs to be extremely reliable. This paper presents an overview of the factors influencing NBC's decision to use Tcl/Tk and related extensions in prototyping GEnesis, as well as issues involved in the ongoing design of both the user interface and the system architecture. In addition, we discuss our approach to addressing a number of design tradeoffs we have encountered over the course of the project to date. PROJECT MOTIVATION AND SELECTION OF TCL/TK GEnesis requires quick operator interaction in response to real-time, mission-critical changes within a complex system. As a result, NBC's major goal was to incorporate operator ideas into the user interface and system design. In doing this, two related issues needed to be addressed. First, many different systems were being merged into one unified system and very few operators were able to envision how the new system would work. Second, the systems to be replaced were heavily text based, originally running on VT-100 terminals. As the operators had limited experience with other types of user interfaces, the prototype needed to allow rapid modification over the course of its development, based on user feedback. The prototype system objectives were twofold: demonstration of possible operating scenarios and screen layouts to the operators, and development of a user interface which would simplify data management as NBC transitioned to more complex digital video. Not having the personnel or the expertise to develop a working prototype in the time available, NBC turned to GE Research & Development for assistance. After visiting GE and reviewing various software development tools, environments and interpreters, NBC decided to investigate the possibility of using Tcl/Tk as the development toolkit. Impressed with the speed with which NBC engineers were able to begin building applications, NBC decided that Tcl/Tk presented the best approach to take in developing the prototype. The Tcl and Tk toolkit provided all the functionality NBC was looking for in a development tool: speedy development time, the ability to change software quickly to meet new operator requirements, and the ability to relate data from many different sources both graphically and in a text-based fashion. As one component in a much larger system, it also offered an environment well-suited to seamless integration. As compared to other X-based programming tools, Tcl/Tk made it very easy to access the existing Sybase database using sybtcl, and TCP/IP communications via Tcl-DP. Tcl/Tk offered a best-of-both-worlds approach, leveraging commercial database and semi-commercial control software in conjunction with a custom user interface. These extensions allowed us to remove the mission-critical software from the user interface and create an architecture that provided the reliability required not only for the prototype, but for the final production system. In the past, because NBC's legacy systems were developed with a variety of hardware, tools, and programming languages, software changes or bug fixes have frequently been costly or required out-of-house expertise. Since then, an increasingly complex broadcast control system has evolved, putting greater demands on the broadcast operators. The only way to bridge the gap between increased operator workload and increased system flexibility is to provide better, more intuitive, and more easily customizable user interfaces. The ability for NBC's developers to inherit software from outside contractors such as GE Research & Development, then support and maintain it on a variety of hardware platforms, makes Tcl/Tk very attractive. DISPLAY PROTOTYPING In addition to providing a venue for rapidly trying out new ideas for broadcast schedule displays, the GEnesis user interface needs to clearly show different timing relationships within the schedule. We have found that novel types of screen displays that have been brainstormed on white boards during meetings or simply sketched on paper can generally be prototyped in Tcl/Tk in a matter of hours. Figure 1 shows the main home screen currently provided by the GEnesis prototype. Broadcast operators emphasized the concept of a home screen, since they need to be able to quickly jump to a known context during emergency situations. This display is based on early paper sketches for the GEnesis user interface and conveys a clear, intuitive view of an integrated broadcast schedule for a main group of affiliate stations together with several regional groups that differ from the main group in some program content--typically, different commercials. The integrated schedule, sorted chronologically, is displayed in the text widget on the left. The smaller text widgets on the right show the same aggregate schedule, but here separated by regional group. Initial Prototyping This basic display was quite easy to create in Tcl/Tk, and a first mockup was put together in 20 minutes. This initial mockup even included a live clock that was easily implemented by periodically calling "exec date" and displaying the results in a label widget. (This clock was the early precursor to the more sophisticated timing mechanisms added later.) It then became a weekend project to build a mechanism that fills the integrated and regional schedule displays with sample data, and at this point it became clear that Tk's binding mechanism and text tags could be leveraged to good advantage. Figure 1. GEnesis prototype main screen The integrated and regional displays are implemented as text widgets that display broadcast information including program title, start time, source video device, regional group, status, etc. A color coded text tag was added to each text field, and and bindings were created for each named tag. The result is that, as the cursor is moved within a schedule display, all like items (i.e. all programs having the same title or using the same video device) highlight together when any are touched by the cursor. This mechanism was further extended by creating bindings that leave the selected item highlighted when the left mouse button is clicked. Generally, the tag bindings are creating as shown in figure 2. Figure 2. Schedule display tag bindings The selection in the pseudo-code of figure 2 differs from the usual Tk selection, which refers to an individual user interface item, only. The selection here refers instead to an item in the broadcast schedule which may be broadcast material, a video disk machine, etc., and which may appear in multiple places in the user interface simultaneously. The current selection is indicated in the main screen. (See figure 1.) A simple loop applies the interactive highlighting to all currently-displayed text widgets: foreach win $GEnesis_displayed_text_widgets{ foreach tg [$win tag names] { if {[string match $tagname $tg]} { $win tag configure $tg -background $color } } } The color-coded analog clock face in the upper left of the main screen also resulted from brainstorming intuitive, novel ways to display time. The color-coded wedges within the clock face correspond to particular, pre-defined segments of the broadcast schedule. This clock face was easily prototyped in a few hours using a canvas widget with filled arcs, and a little simple trigonometry to derive the angles of each arc from times within the broadcast schedule. Also, tags were assigned to each clock wedge and associated with the tags in the schedule displays described above. This provides a mechanism by which clicking in a clock wedge causes the corresponding portion of the broadcast schedule to highlight in each of the schedule displays. The toolbar provides various commands for requesting more information about the current selection. For example, if the current selection is an affiliate station, then the Schedule toolbar button will create a new window containing the schedule of material played for that affiliate. (See figure 3.) Note that the affiliate schedule popup contains buttons for e-mailing or faxing the schedule directly to the affiliate, thus leveraging Tcl's ability to seamlessly call upon other software services to easily give additional capabilities to the user. Figure 3. Affiliate station schedule accessed using current selection and toolbar As the previous discussion suggests, the GEnesis displays use quite a few tags for interactive highlighting and selection. This leads to some issues in tag management. First, we use a naming convention in which each tag's name indicates: its corresponding item in the broadcast schedule (i.e. which device or material), its corresponding event in the broadcast schedule, and whether the tag has interactive bindings, or is used for highlighting, only. For example, a tag name may be something like: my-favorite-sitcom_button_event_33 Since the Tcl "string match" function accepts wildcards, it is easy to then highlight, for example, all tags matching: my-favorite-sitcom_button_* Another issue in tag management is that of garbage collecting old tags as the display contents change over time. When portions of text are deleted from a Tk text widget, Tk does a very good job of also deleting the corresponding text ranges from the widget's tags. However, the tags themselves remain defined, even after they are no longer associated with any text in the display. (This is probably the most appropriate default behavior for tag deletion, since in some applications it may not be appropriate to delete text tags automatically.) However, in GEnesis, we would like "expired" text tags to disappear. Our current approach is to recreate the contents of each text widget from scratch periodically. The alternative would be a rather elaborate scheme tracking the usage of each of many text tags. Timing Mechanism After prototyping some initial GEnesis displays as described above, the next step was to add a timing mechanism to the user interface to simulate the execution of the broadcast schedule. For example, it made sense to remove each broadcast event from the schedule displays after execution of that event was complete. Rather than implementing a specialized timing mechanism that would work only for certain displays, a very general and extensible timing mechanism has been implemented, and subsequently leveraged for additional types of animated displays described below. Generally, the broadcast schedule is organized as a list of events, where each event has a duration and either a specific start time or conditions under which the event begins. A general timing loop was implemented that steps through the list of broadcast events and recognizes when events are beginning and ending. This timing loop then calls several procedure stubs at the appropriate times: at each clock tick as well as at the beginning and end of each event period. Code that animates each type of display is then inserted into these procedure stubs as appropriate. For example, the integrated and regional schedule displays were animated using simple procedures that remove events from the display after they are completed. The result is that these schedules automatically scroll with time such that the current event is always on top. This timing mechanism also made it simple to add the on-air and next event displays to the main screen. (See figure 1.) These displays are crucial so that the broadcast operator always has the on-air information immediately available. Also, the countdown timers were easily added by simply subtracting the current time from the next event times and displaying the result in label widgets using the "textvariable" option. The general timing mechanism was extended to include a flashing mechanism that allows an arbitrary periodic event to occur for a specified amount of time before each event transition. In the current prototype, this mechanism is used to flash next events in yellow (in each schedule where they appear) for 5 seconds before they go on-air. Early prototypes of the GEnesis timing mechanism continued to use the call to "exec date" mentioned above. Recently, this has been replaced with a C-based custom timer module for a more smoothly-running clock. Simultaneous broadcast events are not always synchronized. Therefore, the timing mechanism must allow multiple events to be initiated, where each has its own separate duration and countdown. (See again figure 1.) Also, whereas early GEnesis prototypes supported only broadcast events having specific, scheduled start times, in practice, many broadcast events are linked by dependencies on one another and initiated manually by the broadcast operator. The user interface timing mechanism now supports this additional flexibility. Animated Displays The GEnesis user interface timing mechanism enabled the creation of several other time-driven custom displays. Figure 4 shows a sample map of affiliate stations and their current connections to four satellite transponders. Figure 4. GEnesis Satellite Display This display is animated with time; the satellite connections change as the schedule executes, as does the label indicating the program being transmitted by each satellite. Also, the program titles and connecting lines are color coded to easily differentiate them visually. The resulting display shows the current satellite connections to affiliate stations. Initial user reaction to this display suggests that it is extremely intuitive and provides a useful graphical supplement to the schedule information text shown in the main screen. The animated satellite map display was implemented in Tk using the GEnesis timing mechanism described above, along with a Tk canvas containing bitmaps (for the map and satellites), text (for the affiliates and program titles), and connecting lines. The data associated with the display was organized as described in the "Object Mechanisms" section below. Yet another custom display shows satellite transponder allocation as a function of time. (See figure 5.) Again, this display is animated using the general timing mechanism described above. The time indicator moves horizontally across the screen, and transponders currently in use change color such that the colors match those used in the satellite/station map shown in figure 4. These timelines are implemented with a canvas containing text, lines, and rectangles, animated in time. The duration of the event determines the width of each rectangle, which is tagged with the transponder name and the event start time. When the timeline updates at the end of its period, the tags are updated as well. Figure 5. Satellite Resource Display Object Mechanisms in Tcl Complex data structures and operations are conducive to an object-oriented approach. Although Tcl does not have built-in support for an object system, Tcl is so flexible that it is easy to simulate object-like mechanisms in Tcl. This has been done where appropriate in the GEnesis prototype using associative arrays for object-like data and using the Tcl interpreter as a means of generating procedure names and obtaining polymorphic object-like methods. The general approach is to use associative arrays with a fixed naming convention for the indices, such that each index of the array has the form object-name%attribute-name. For example, both the satellite map and transponder timeline displays shown above have fairly complex sets of data associated with them. For a given widget named $w, we define an associative array called ${w}_data. The array indices follow the convention described above, where the objects are things relevant to the type of display, such as satellite transponders or affiliate television stations. Attributes in these cases include transponder or affiliate name, and x,y coordinates in the Tk canvas. (See again figure 4.) A benefit of this approach is that it is extremely easy to clean up object data when a widget is destroyed. There is simply a binding to the widget's event that calls unset ${w}_data and this destroys all the object data at once. It is also desirable within the GEnesis user interface to have polymorphic methods that update each display with time, regardless of the type of the display. The convention used is that each displayed widget has a name that ends in widget-type%widget-instance. For example, the text widget that displays the schedule for the first regional group has the widget name: .regional_schedule%regional_1 A loop that updates all time-dependent displays parses the name of each displayed widget to determine its type and instance, and then calls: GEnesis_redisplay_${widget-type} $w $widget-instance Here $w evaluates to the actual Tk widget name, and $widget-instance is a logical identifier for the widget, such as "regional_1" in the example above. Note that this sort of dynamic generation of procedure names is possible because Tcl is interpreted rather than compiled. The convention described here for structuring object data and methods has been used throughout the GEnesis prototype. We have found that this approach enables us to write code that is almost self-documenting; the structured array indices described above clearly identify the attributes of each object. This approach has also allowed us to prototype an object-oriented design in Tcl. Much of the logic for broadcast schedules implemented in the GEnesis prototype could be readily ported to other implementation languages, such as C++, while still retaining its current design. SYSTEM ARCHITECTURE The preceding section provides an in-depth look at the user interface. This section focuses primarily on the data server, the controller, and interprocess communication in both C and Tcl. The overall system architecture for the prototype is partitioned into several distinct elements, each of which is a separate process and can be launched separately from a system startup display. Each element needs to communicate with the others but be capable of a decoupled restart in case of a partial system failure. Furthermore, the system needs to handle internal checking to confirm operational status of all connected devices and switch to the appropriate backup options if necessary. Figure 6 indicates the system architecture elements. Tcl's ability to integrate easily with disparate software system components in a hybrid architecture allows the GEnesis Tcl/Tk user interface to work seamlessly with other third party and custom software. Figure 6. GEnesis prototype system architecture elements Data Server Prototype in Tcl Several factors motivated the decision to implement a data server interface between the user interface and the Sybase database. The server handles data requests from the rest of the system, and distributes changes made at the schedule database level to the controller and the user interface. It provides a flexible layer designed to minimize the modifications to the rest of GEnesis with the use of a different commercial database system. Also, since GEnesis must be highly reliable in a real-time environment, the data server monitors the status of the database and switches to an alternate database if necessary. The server process can handle lengthy database transactions asychronously from the user interface, so that the user interface need not pause during these transactions. We have used Tcl to rapidly prototype the data server, and intend to port the data server to C once the data protocols and database schema are well-defined. We have used two Tcl extensions: Tcl-DP (for TCP/IP socket management) and sybtcl (which accesses the Sybase server in a manner similar to Sybase tools such as embedded SQL and Open Client). Using these extensions, we have found it to be extremely easy to prototype the data server, due to the convenient APIs provided by Tcl-DP and sybtcl, and to the extensive string manipulation functions inherent in Tcl. Sybase queries generally return a table of data. Sybtcl provides an interface to Sybase similar to that of Sybase Open Client. Sybtcl and Open Client both store query results in their own data structures and allow these results to be accessed one row at a time. However, sybtcl worked particularly well with the format of the GEnesis broadcast events and SybaseUs string-based query structure. Within Tcl, GEnesis events are stored as string lists; sybtcl returns query results in the same format. This greatly simplifies much of the GEnesis database interface code. To illustrate, the code below uses the information in a Sybase table called GEnesis_db_event to update a global array variable called GEnesis_events The code handles particular request criteria by specifying the conditions as a separate string variable called $criteria. global GEnesis_events sybsql $sybase_handle select event_id, from GEnesis_db_event where $criteria sybnext $sybase_handle Rlappend event_list @0 foreach event $event_list { set GEnesis_events([lindex $event 0]) [lreplace $event 0 0] } The sybnext call provides the flexibility of an optional third argument which can be used to append all columns of the returned query to an arbitrary internal variable. We then update the global array, indexing the array elements by the event identification number. In actually implementing the above example, we wrote our own wrapper for the sybtcl sybsql procedure, incorporating Tcl's catch error-trapping facility and bringing up a Tk error screen explaining the cause of the error. This type of added functionality is valuable to the prototype because GEnesis needs to flag not only internal scheduling errors at the database level, but also database querying errors. The internal event storage in Tcl provides an extra measure of security in the event of a total database or server failure. Once the query results are obtained, they are then formatted within a GEnesis-specific protocol and directed to the requesting process--the user interface or the controller--via Tcl-DP socket links. Device Controller Implementation in C, Simulation with Tk The device controller poses unique challenges of the three major system components because it communicates with an arbitrary number of drivers for different devices (for example, different types of video players). While the types of actions to be taken fall into a manageable number of categories on the controller side, their implementation on the device driver side is primarily device-specific. We chose to address this issue by retaining a simple, string-based protocol for communication, while implementing the controller and drivers in C for reliability and customizability. This approach is particularly natural for the device drivers, which are designed to be most easily controlled via C. The string-based protocol contains both delimiting characters and byte-count information to facilitate its use in C as well as in Tcl. All communication is done with Berkeley sockets, using a client-server model in which each device listens for connections from the controller and then subsequently executes its specific list of events. Similarly, the user interface acts as a server for controller connections. In this case, the Tcl/Tk user interface uses Tcl-DP; it communicates seamlessly with the C-coded controller. Many commercial video devices can be controlled using a socket interface, typically under a Windows NT operating system. For preliminary simulation and testing, we simulate the socket protocol supported by a typical video device. We are using Tcl/Tk for this device simulation, so that the simulated device status can be graphically displayed, and so that simulated error conditions can be interactively created. These initial device simulators have been implemented under UNIX-based workstations, but Tcl/Tk's portability offers promise for running similar experiments on the PC interfaces packaged with many of the devices being used in GEnesis. In negotiating the tradeoffs between using Tcl-DP and directly coding the sockets on the controller and device side, we found that the purpose of the particular system component largely dictated the approach. The added flexibility of C coding (for example, in handling blocking and interruptions) was necessary for real-time execution on the controller side and less crucial on the user interface side. However, the coding speed advantage of Tcl-DP has proved very valuable, and an incentive to use it as much as possible. Communication Protocols Tcl's native use of an easily-readable string datatype, and Sybase's string-based data query results, led naturally to a string-based protocols for data transfer between the three main system components. By isolating the device-specific parsing to the level between the controller and the devices and handling it all in C, the protocols being used to communicate to the controller can be made much more general. This builds in a much easier extensibility as different types of devices are added to the controller. We have designed specific protocols for data server communication, regular checking from the process monitor to make sure that all devices are alive and on-line, local configuration and logging information, and control. All protocol messages use newline characters to delineate message lines, and tabs to indicate separate fields within each line. We have not yet encountered a need to represent non-printable characters--for which Tcl has no representation--within protocol messages. Should this be necessary, this functionality could be provided via C support code. KEY ISSUES Speed and Display Updates The GEnesis Tcl/Tk user interface is used primarily on a SPARCstation 20 with dual processors. Although this hardware is very fast, the animated nature of the GEnesis user interface creates some unusual user interface performance issues. The user interface provide real-time clocks and event countdown timers. It is important for these to run smoothly, since the broadcast operators are accustomed to precise second-by-second timing, and would find any delays or jumpiness in the clocks unnatural. Initial implementations of the GEnesis user interface did in fact have deficiencies in the smoothness of the clocks. The situation was somewhat improved by replacing the initial, crude time driver (explicit calls to "exec date") with a custom, C-based timer handler. This resulted in smoothly running clocks during periods of time with no other display updates. Some slight clock pausing still occurs during instants of time when many of the text and canvas widgets are being updated at the same time. We suspect that this delay is due in part to the queuing of X updates, and hence cannot be greatly improved from the Tcl level. We have improved performance further by staggering the updates to individual widgets, and the clock smoothness is now acceptable. Structured Versus Unstructured Language Tcl supports one basic datatype, the text string. The GEnesis Tcl code makes extensive use of the two primary data structures available: lists and arrays. Most primary data read in from external files or Sybase queries is initially formatted as lists, but the majority of the global variables are arrays indexed by either time or event identification number. Because Tcl does not explicitly support a constant declaration, variables whose values are essentially static are also global. As compared with other X-based user interface and application work we have done using C-based toolkits, the key programmatical difference has been Tcl's inability to provide user-defined datatypes, constants, and other traditional C header information. As a result, we have had the options of either passing a large number of parameters to our procedures (particularly those doing significant drawing), encapsulating the parameters into an array structure and passing the arrays, or simply using the arrays as globals. In the majority of cases, we have created global arrays, even when the array information is specific only to one particular display. (Refer to "Object Mechanisms in Tcl" for examples of this usage.) The tradeoff has been one of rapid development time versus using encapsulated data structures tailored to the application. Tcl's speed and flexibility have allowed us to build the prototype quickly using array structures, largely because the GEnesis project did not mandate application-specific structures from the beginning. We will be following the development and use of structured Tcl extensions such as {incr tcl} with interest. In addition, the associative array naming conventions we use could eventually map to a C or C++ structure or class. Global Variable Use As discussed above, the GEnesis prototype makes fairly extensive use of global variables to ease data accessibility while reducing extensive parameter passing throughout the Tcl code modules. Global variables fall into several major categories: those associated with broadcast schedule data, those associated with timer handling, those associated with the user interface, and those associated with particular displays. In managing the development code, we have kept separate version-tracked documentation listing all global variables and their usage. This has been necessary to track the variables being used within a growing number of Tcl modules, since Tcl does not provide a way to create a header applicable to all procedures in a file. Preliminary investigation has not indicated any speed decrease attributable to global variable use. However, this remains an issue that concerns us long-term as the prototype continues to be extended. CONCLUSION In applying Tcl/Tk and its extensions to the GEnesis prototype, we have been able to quickly design an integrated system which handles and displays schedule dataflow and execution, allowing manual data editing and command execution. The Tcl/Tk toolkit has not only been an effective approach in the GEnesis prototype development, but appears very promising as a tool for the final long-term system implementation. We have found several major advantages to using Tcl/Tk: powerful widgets having unusual flexibility (i.e. tags and binding mechanism), easy to rapidly prototype and modify the user interface, seamless integration with disparate software components, and portability to many platforms. The ability for NBC to quickly and easily inherit and extend the GEnesis prototype software initially developed in collaboration with the GE Research & Development Center will be a major factor influencing the NBC decision to continue production system development with Tcl/Tk. Over the short-term, Tcl/Tk has provided an excellent environment for rapidly prototyping many system components in the distributed GEnesis architecture. For the long-term, we expect that Tcl/Tk will provide the GEnesis system with a powerful and flexible interactive user interface. ACKNOWLEDGMENTS The authors would like to thank Joe Amaral of NBC for the many hours he has spent with us discussing display and architecture requirements, while simultaneously maintaining a broad system view of how the GEnesis user interface will interact with the rest of NBC's broadcast automation system. Kevin Kenny of GE Research & Development deserves extra special thanks for showing us an initial vision of what Tcl/Tk could bring to GEnesis, contributing many valuable ideas to the GEnesis system architecture, and for being available on a daily basis to share his expertise on seemingly every aspect of Tcl/Tk. Particularly in the case of an emerging engineering or software approach, one is very much aware of the contributions of those on whose work one is building. In this light, we also wish to acknowledge and thank John Ousterhout, Tom Poindexter (for sybtcl), and Brian Smith and Lawrence Rowe (for Tcl-DP).