Theater automation

Finally we come to theater automation, and a project we're working on to bring to fruition -- the Transportable Cue Text file.

Loch Ness Productions would like to provide our show packages complete with the automation cues we used to program the show when we put it together. Since we go through the effort of producing and recording the visual choreography, we should be able to save every planetarian the hours and days of programming they would otherwise need to spend, trying to recreate what we've already done.

Now it's not likely that theater automation systems will ever become compatible to the point of interchangeability. But everyone's automation systems do basically the same thing: the computers store projector commands and timing information as cues in a list, and run through the cue list in sequence to make the projectors do their thing at show time. They all save their cue lists as computer files. Currently, the cue files from the major planetarium automation systems are all incompatible with each other.

However, some systems can also save their cue lists as plain ASCII text, and can read their cue lists as ASCII text too. The text files themselves are basically simple data dumps of the system cue lists, which aren't usable by systems other than those that generated them. But, again, they all do contain the same basic information, and use universal, plain vanilla ASCII text characters.

That's where we come to the Transportable Cue Text file format; we can use the naming convention *.TQT for easy recognition.

The first step is to see if we can get the makers of the automation systems to agree to incorporate the functionality of saving the information in their cue lists using an agreed-upon format. For example, cues could be stored one per line, with each data field delimited by some visible character (a vertical bar in this example), in the following order:

The details:

Cue Number is obvious enough.

Cue Type can indicate what kind of cue it is, for those systems that need it -- a comment, a marker, a system command, whatever. If an automation system doesn't need it, a null value can be stored, or the field ignored.

Time: the SMPTE time at which the command occurs, in SMPTE format: Hours:Minutes:Seconds.Frames.

Duration | Action | Value: should cover most typical cues

Device: the device receiving the command.

SysEx: A "System Exclusive" field to allow for additional unique data to be included, if needed, or reserved for future uses.

Of course, the automation will need to be able to Import or Read a .TQT file, as well as Export or Save.

This is just a first step, of course. The Device designations will be a troublesome spot. Some form of configuration file will be needed to cross-reference a TQT device name to whatever it's called in a given theater. And there are many other details to be ironed about before we can get to our goal of providing usable cue files for all our customers, regardless of their theater's brand of automation control system.

But the good news is that preliminary support for the TQT file format is already been expressed by:

• Sky-Skan
• Spitz
• East Coast Control Systems
• Joe Hopkins Engineering

whose systems control many of the world's planetarium theaters.

Maybe we can achieve a little standardization before this century is over!