Besides a offering a chance for you to comment on these ideas, my fantasy is that some large institution, like an opera or ballet company, will subsidize the completion of these programs!
These concepts, ideas, and proposals are not offered, approved, or supported in any way by Electronic Theater Controls, Inc.
As you can see at the top of the shot above, an error was deliberately introduced into the ASCII file. Should the patch import process be abandoned, or should the remaining "good" data be patched?
The most significant problem (for Obsession II© users, anyway) is that Obsession II© files are compressed. Even if I am eventually able to expand the entire show file, edit the patch, and compress the modified show, I'm uncomfortable with (as a third-party developer) manipulating a proprietary format to that extent. It's a bit like mixing your own nitroglycerine. By comparison, developers who "work with" Word® or Excel® files can use "automation" features of those programs to have the internal manipulations done for them. This is slow in execution, but it represents a less risky form of tampering with a complex file format. Whenever I write a program that does this, I recommend that the user make a new "native" file on the light board, immediately after loading a "tampered-with" file.
I can see that this would be helpful in an institutional situation, where a rep plot has a new patch applied frequently. The best example would be The Joyce, where I was the TD some years ago. But in fact, it was so hard to get the paperwork in from many companies at all that it may be too much to expect a machine-readable hookup from everyone! An opera house is more certain to find this useful.
I've been told that this is not a salable product unless it can handle Obsession II© diskettes, so I've suspended work on it.
Current Status: Working Obsession I© prototype repatches console diskettes offline.
Sure, you can run cues on an Obsession© by sending it MIDI commands. But what about all of the other commands you'd like to give the board? How about patching from paperwork, inserting cues or groups from other shows? How about a wireless RFU?
The first step was to write a Windows program that emulates the RFU. The shot below shows the window, consisting mostly of pushbuttons.
Naturally, you can't just plug a PC into an Obsession©. There seem to be two ways to operate an Obsession© by remote control. You can buy an RS-485 adapter (I believe you can just dismiss the personal information inquiry and then view the B&B file in the link), and build an RFU cable adapter for it, or you can buy a keyboard emulating device and plug it into the keyboard port of the Obsession. Either costs between US$69 and US$169. Here are some USB examples.
Needless to say, just buying the hardware is not enough--A huge amount of programming is necessary. Although I've been able to make both work, the RFU adapter seems more robust and reliable. On the other hand, there are some keys that can't be "pressed" directly from the RFU port (although you can create Macros for them.) You can find the RFU plug pinout in the Obsession manual under "Setting up a hard-wired Remote Focus Unit", or by searching for the sub-heading "RFU pinout" in the .pdf manual file.
Of course, I can't assume any responsibilty for plug-in connections you might make to your light board. I think that means you'd have to build your own adapter cable, at least. See below for a discussion of the simpler hardware connection to the keyboard port.
Current Status: RFU emulation program operates console, at about the speed of a running Macro. (This means the PC has to be held back from sending too many commands per second.) The next step is to make it operate over the office network, and then to chose a radio control system. I also plan to write a utility that inserts (i.e. types in) a cue at a time from another console diskette. Eric Cornwell sells FocusPhone®, which provides similar functionality off the shelf for several consoles, including Obsessions.
All of this suggested, if you can't (or feel it's too risky) to get into the file format, why not manipulate the hardware instead? Assuming you have a paperwork program, you'd like to simultaneously patch the show, while updating the paperwork so that the dimmer numbers print with it. Unlike the first example ("Offline ASCII Patch"), the patch does not exist yet, so the job (one way or another) has to be done at human typing speed. Since many theaters have multicables or raceways that "increment" the dimmer number in predictable ways, can some of the typing be eliminated?
In the shot above, the user has imported a comma-delimited file of the paperwork. Using the auxilliary window at the right, (roughly) ascending dimmers are being patched into successive lines of the (by position/unit number) paperwork. You can press the appropriate button, press <Enter> to press the currently highlighted button, or double-click on a new dimmer number to go out of sequence. Once the ListBox has focus (like other Windows® applications), you can use the up and down arrow keys to move to another dimmer number, and press <Enter>.
As you "Enter" each dimmer number, the PC sends the patch command to the Obsession©, and inserts the dimmer number into the paperwork file on the PC. You might ask, "Why not batch all the edits and patch the whole show at once?" The way load-ins are done in my theater, it's important to have the board's patch up-to-date at all times. For example, the FOH may get focused while upstage pipes are still being hung and patched.
In fact, this program is something of a disappointment. Although it works well, it doesn't patch that much faster than typing on the Obsession©. I believe it's more accurate, because you don't have to type either the channel or dimmer numbers. But the way work is divided in the U.S. professional theater today, a lighting assistant is going to type the dimmer numbers into the paperwork (later) anyway. So not much advantage has been gained.
Current Status: Working Obsession I© prototype repatches Light Board through Keyboard port. Comma-Delimited files updated on PC. Initializing Keyboard port not as reliable as RFU port. Work suspended.
I use the title term to refer to the attractive option in Strand's later software that lets you specify just exactly which Cues, Groups, and so on you want to import from a show on disk. When you're doing a gala performance or a composite show like "Ailey® Classics", you'd love to assemble several shows into one.
Most operators do this by copying the cues into Submasters or Groups, and then reloading the gala show. The Groups/Subs are then copied into new cues in the gala show. This works, but it is slow and tedious. There's also danger of making a disk management mistake.
I've occasionally done this job for road persons in my theater by translating all the shows into USITT/ASCII, putting them together, and using a small utility to renumber them. (This last is the kind of job that Trackmaster 2 is very good at.) Then the big show is translated back into an Obsession© show on a floppy, which is pulled into the board with "Read Cues".
This is practical for a predetermined group of big shows. But it's time consuming for 6 pas de deux with 5 cues each, of which we only need 1. And if a designer wants two cues from yesterday's show version, and five cues from the disk from two days ago, it's not worth it.
Once I was able to operate the RFU port from a PC, it seemed logical to insert cue data in a more flexible way. Even if it takes the same amount of time, they like to see the design table monitors flashing with activity! Here's a (cropped) screen shot:
The user has chosen an ASCII file from the usual File | Open menu. The whole file was read, and the Cues, Groups, Subs, and Patch were put into the ListBox on the left. When you click on one of them (or move up and down with the arrow keys), the ASCII data for that Cue/Group/Sub is read into the RichEdit box on the right for your inspection. If you double-click on your choice in the ListBox, the Cue/Group/Sub is typed into the Obsession©, by way of its' RFU port. If you have selected the "CHANNELS only" option in the small ComboBox at the top, the line that says "CUE 101" is not sent, on the assumption that you have created the new and different Cue number desired yourself. As each ASCII line is sent, it is "bolded" on the screen.
Like the projects above, this requires some hardware: An RS-485 port for your PC (I used one from B&B Electronics specially designed for laptops), and an adapter cable from the port to the RFU plug. (You can't buy those! By the way, it looks to me as if the pinout for the RFU plug, in the Obsession© manual has the transmit and receive pairs reversed.) Unlike the keyboard port, I have found the RFU port to be rock-solidly reliable in establishing communication.
The input to the RFU port has to be limited to 8-10 keystrokes per second. At least you're not typing in the cues. Unfortunately, the RFU does not have all the keys you'd like. Because it has no "/" key, "DOWN n" ASCII records can't be typed in. Because it has no Softkeys, "GROUP n" ASCII records can't be typed in. I may add an option to use macros to make those keystrokes, but someone has to put them into the show that's in the board.
Current Status: Working program performs well. I've combined it (in a batch file) with my Obsn I Console Diskette-to-ASCII program so that you put a diskette in the drive, and 20 seconds later, can chose which cues to "type into" the light board.
Dance companies (and others) who carry their own equipment and play one-nighters know how to focus quickly. It's common to use a "Focus Disk" to decrease talking at a noisy load-in, and to reduce errors. This assumes that the plot (each position, that is) is the same everywhere. Instead of calling for channels, the focus show brings up each unit in unit-number order. These shows are usually built by the Head Electrician by hand.
Since most hookups are machine readable today, you have an Instrument Schedule from which a (very) few lines might look like this:
(23) 271 LAV HI-SIDE #3 ELEC 2 S4 26° 575 R55+R132
(13) 270 BLUE HI-SIDE #3 ELEC 3 S4 26° 575 L161+R132
(23) 269 LAV HI-SIDE #3 ELEC 4 S4 26° 575 R55+R132
(13) 267 BLUE HI-SIDE #3 ELEC 5 S4 26° 575 L161+R132
Now, if you ask your paperwork or database program to output this in a comma-delimited file, it looks like this in a text-editor:
23,271,LAV HI-SIDE,#3 ELEC,2,S4 26°,575,R55+R132
13,270,BLUE HI-SIDE,#3 ELEC,3,S4 26°,575,L161+R132
23,269,LAV HI-SIDE,#3 ELEC,4,S4 26°,575,R55+R132
13,267,BLUE HI-SIDE,#3 ELEC,5,S4 26°,575,L161+R132
But it's machine-readable, so a program can read this file, and output an ASCII show that includes these cues:
CUE 171
UP .5
TEXT #3 ELEC 2 (23)
CHAN 23@100
CUE 172
UP .5
TEXT #3 ELEC 3 (13)
CHAN 13@100
CUE 173
UP .5
TEXT #3 ELEC 4 (23)
CHAN 23@100
CUE 174
UP .5
TEXT #3 ELEC 5 (13)
CHAN 13@100
Note that the Cue Comment contains the answers to the questions most frequently shouted to the board operator. Since running cues does not switch channel pages to show the current channel, having the channel shown is essential. As a bonus, the ASCII focus show program can even generate slightly intelligent, useful groups like:
GROUP 603
TEXT #3 ELEC*ALL*
CHAN 203@100 4@100 13@100 14@100 23@100 24@100 93@100 94@100
CHAN 131@100 132@100 133@100 147@100 148@100 149@100 157@100 158@100
CHAN 159@100 306@100 343@100 357@100 381@100 413@100 424@100
GROUP 678
TEXT **R55+R132
CHAN 21@100 22@100 23@100 24@100 25@100 26@100 27@100 28@100
GROUP 655
TEXT **L161+R132
CHAN 11@100 12@100 13@100 14@100 15@100 16@100 17@100 18@100
GROUP 727
TEXT ->LAV HI-SIDE
CHAN 21@100 22@100 23@100 24@100 25@100 26@100 27@100 28@100
GROUP 698
TEXT ->BLUE HI-SIDE
CHAN 11@100 12@100 13@100 14@100 15@100 16@100 17@100 18@100
Naturally, the accuracy of these groups depends on your having properly made sure that all units have the exact same text for their position name, their color,and so on. I think a clever word processor user could devise a macro to do this. My C++ Builder program does a few more difficult tasks, like abbreviating information to fit in the Cue Comment fields, and eliminating cues for immediately adjacent instruments with the same channel.
Drawbacks: You have to be able to generate a board diskette from an ASCII show. That's not as hard as it used to be, but it's not always easy. Some formats can be generated by contractors (Like me!). This produces a very large show, that takes a long time to read into slower boards. A really big plot might generate more groups (or even more cues) than the board can handle. The program doesn't account for focusing every other pipe backwards. In order to do that "automatically", you'd have to recognize that "1P", "#1 PIPE", "#1 ELEC", and a dozen other variants represent left-to-right overhead pipes that should alternate focusing directions. It might be more sensible to ask the user to select every other position in a spreadsheet and sort them in reverse, before sending the comma-delimited file to this program. But this certainly is an example of an excellent side benefit of computerized paperwork.
Current Status: Output of a "Focus Show" is one of the options of the "Local Repatch With Paperwork" program described above. It could be separated out into a single-purpose, low-cost utility. I've tried out the shows, and found that they helped some designers who might have forgotten to call for a few channels. You still have to bring up "related" channels that help focus like purposes (a full stage of gobos, pipe-ends, and so on.)
|