(Those of you that don't know what XML is, it's basically a language or set of rules used to design markup languages such as HTML.)

Therefore, a couple of questions for those of you that use some kind of automation today:

Do you use a "pulse-based" system (that is, do you have a step-programmed system that performs a step on cue from a foil tape or equivalent placed on the print), or do you use a time-based system? Or do you use some other type of automation? (I can't conceive of any other type, but...)

How do you program a show today? Which of you do it using a computer, if any? Is there something you'd want to change to make the process easier?

If you move a print from one screen to another at your multiplex, how much extra programming work does this require from you? Again, is there something you'd want to change to make it easier?

And more generally, are there any features you'd like to see that you don't have today? What's on your wish list?

I will not go into any details because I am not an expert on it. Also most of this is made up as I am not at work so can't check the timings.

Our automation (Panalogic) is a pulse and time based system. It may get a cue from the last slide which will start the dowser opening, it will wait say 5 seconds, then start the projector motor, after a further set time it opens the zipper, changes sound from non-sync 2 to Dolby digital etc...

The only problem we have mving prints around is that 2 auditoriums have screen curtains and 2 don't. The ones with curtains require an extra cue (foil) to start them closing slightly before the last credit goes through. If someone forgets to add this cue then the automation thinks the End Show cue is the curtain one and doesn't shut the dowser, zipper, return house lights to fully up or change sound back to non sync. This creates very poor presentation and not even film guard would be able to cover it up. That was a joke to any humourless person who reads it.

Seriously though download the Panalogic CA2000 manual and read through it to get some ideas.

Ari, there is another way, and it is the basis of our TA-10 system. The initial desire was to create a system whereby the film itself carried the programming information. This got to be too cumbersome and so a hybrid evolved. What we ended up with is the concept that, excluding special presentations, every show has the same basic format, but there is the potential for variations within that format. Therefore, we have what we consider to be five essential events: 1. "Start", 2. "Start" plus seven seconds (douser open), 3. The beginning of the end of the show (curtain close etc.), 4. End of show (douser close), and 5. Film runout.

What about the mid-show changes? Because our FM-35 cue detector reads up to three cues we can interpret them as a three bit binary code and derive seven active states. These seven possibilities are assigned to whatever functions the theatre wishes.

Therefore, the basic running of the show is driven by the software of the microprocessor which creates the five events, but the things unique to the particular program are carried by the film itself. This means that when that print is moved around from screen to screen the program goes with it and if all the automations within a complex are set up the same it all works automatically. This scheme also allows for easy changes of trailers as there is no problem with variations in timing.

One of the my earliest attempts at making an automation system used the "count the cues" system, but was rejected as too labor intensive when considering the skill level of some film threaders.

For more of the story, please check out: http://www.componentengineering.com/webdocs/ta-10complete.pdf

A few thoughts I had at the time (which may or may not help you.)

I thought that an automation run on a "time-based" method was the way to go, or a combination (time and cue.) When I mean "time" I don't mean a regular clock, but rather a frame counter (or a simple pulse generator) on the projector. While a clock would probably be accurate enough to dim lights, change lenses, etc. at the beginning of a film, it will be too far off at the end to bring up lights or end the show.

(Years ago, advancing the automation system with cues was a much cheaper design, but today, this should not be too much of an issue.)

Cues get old/dirty/worn out/etc. With a time based system (controlled by a microprocessor) an operator could run the show manually once, and the system would remember from then on (even save the data in case they get the film back at a later date.) Or maybe, both counter and cues; the cues would tell the system when to function (that data would be recorded and saved), but then the cues could be removed- or, if later they get unreadable, it dosen't matter.

If trailers are changed, the automation could be "retrained" up to the beginning of the feature; after that, the opreator would "tell" the automation that the rest of the show is the same as previously set.

Another advantage (using "time" rather than physical cues) might be that different auditouriums could have different equipment. The automation creates a "cue" file that can be copied to other automations. The automation itself deals with the differences in equipment; the "cue" file remains the same. So, not only are there no physical cues on the print, but the file is the same. Sort of like using Java and a Java virtual machine.

Getting a "count" from the projector shouldn't be too hard; either an encoder mounted on the projector or a light sensor mounted on the wall next to the port window that might count flashes from the projector.

Getting rid of cues placed on prints (I feel) is an important goal. Having a "standard" way of "cuing" (so you could move prints around) would be good also. Wouldn't it be nice to download a file into your automation that has the sound/picture formats and running time- and you could pass those files to other operators. (Too bad that film-edge coding system from Dolby didn't take-off.)

We have used microcontroller pc boards with those "Microchip" controllers on them. They use "relay ladder logic" to program them.

John, one of the program timing ideas I'm going to use is to use a frame count, as it happens. It is the sort of time-based solution that just might work. your reasoning is very similar to mine in this case. The basic ruleset (the XML DTD, for those of you that know what that is) provides means for projectionists to use a pulse- or time-based system (that is, a frame-count system) depending on what kind of hardware the theatre is equipped with.

My basic concept is that every film (trailer, Dolby tag, feature, whatever) is treated as exactly one set of information about that particular film; in more specific terms that set is an XML document or document fragment (I'm not sure of just which yet but I'm getting there). The film's aspect ratio and sound format are included, of course, but also an exact frame count including times like when the end titles start, how many frames from "3" is the first image, etc.

Now, a theatre (I'm referring to one auditorium here) is treated as another, rather static, set of information, an auditorium document; this document is also an XML document. If you like, you could regard this document as a template for a show because it provides specific characteristics about a show in that auditorium. Basic questions like "is there a curtain and how long does it take to open it?", "what kind of house lights are installed and how long do they take to go from 100% to 0%?", "is some kind of light show or special arrangement run prior to each show and how long does that take?", and so on, are answered. This document provides a template for how a generic show is run in that particular auditorium. It doesn't limit the number of included films, but it does give specifics about how a show is started, how it is ended, and what happens, generically speaking, in between.

If a number of "film documents" are compiled to a whole show (a "show document") and then combined with a document describing a particular auditorium, then that's it. That's all the programming you'll need for that auditorium unless you'd like to do something out of the ordinary during the show. For example, you might want to change the volume (format changes are handled simply by including a new film document into the show program but volumes cannot be that easily standardised) in the middle of the show every time the film is run because there is a thunderstormn that is simply so awesome that the audience needs to really feel it and then change the volume back again. In that case, you'd want to include an instruction in the combined show+auditorium document, which you could insert manually during the actual show and adjust the exact timing later, or hack the computer using pulses or a frame count during your coffee break, whatever.

Moving that print (or rather, that show) is then to simply take the compiled show document and combine it with another auditorium document. If your new auditorium doesn't have a curtain, then the template for that auditorium will reflect that; you won't have to reprogram anything.

Obviously, reprogramming the show in this manner won't remove the leader that was required for the curtain, but once the leader was physically removed, it would be easy to do the same in the compiled show document, simply by removing that piece of leader from the document.

These documents are to be written using a markup language that I've created called the Film Markup Language or FML. FML defines the rules for describing a film, just as it defines how to describe an auditorium and how to insert all those special instructions. I'm also thinking about including more information about every film and auditorium than just the data necessary to project films. For example, it could be useful to include a press kit, photos, trailers, and just about anything else in a film document.

It is not very difficult to include a lot more information about an auditorium, either, but I don't want to go into detail there just yet.

The neat thing about FML is that it is defined using XML. Therefore, FML documents can be written using any XML editor. FML requires a stylesheet, some linking mechanisms, and some other things to function, but just about the only thing connected to it that is not a standard solution is the interface to the hardware, which, of course, is pretty hard to standardise.

If you are considering designing hardware (PC boards, etc.) I can help out there. I have schematic editors and pcb layout tools, and can do a little hardware design. But, really, the easiest and cheapest thing to do is to use a regular IBM-PC type platform. Even an old 8088 IBM could run several auditoriums at once, if you don't mind trusting everything to one computer.

And even hardware interfaces for PC's are easily avaiable, and they are more standardized then you might think. All hardware can be bought "off the shelf." Many of them are regular ISA or PCI cards that plug into the buss and have relay contacts for your use, with example code to modify and drop into your application.

In the idea I had, I was going to use one IBM PC to run everything. I was going to use BASIC to program it. There would be a small hardware interface at each projector connecting to the PC. This interface (I would design it) would have a very small processor of it's own, with relays to drive the functions. This interface would also have supervisory functions, like a watchdog timer. A simple serial UART (I was going to use a 6402) would commuicate between the PC and each interface. Normally, the PC would instruct the interface processor what to do, but if the PC locked up and needed to be rebooted, the interface processor would perform like a simple automation (in case there was, say, a film break while the PC was down), until the PC was back on line. The PC would have to hit a one-shot to tell the interfaces, "I'm alive"; and the interface processors would have to hit their own watchdog timer to tell the PC that they were alive.

One reason I never worked it out is bacause I agree with what Bill P. said about a previous design concept being scrapped because it may be too much for many operators to learn. I'm guessing that while an XML-based theatre automation is a fun project now, you would like to make some money with it sometime.

(A short story, if I may.. I was once asked to design a fire alarm system. I thought I would have the different sensors each go to a control box- that way you could tell which sensor went off. Of course, each sensor had to be individually wired to the box. When I explained my idea to the contractor, he got a little angry. He said the wire and the labor to pull it was the biggest cost, and that everything is done by a bidding process. He wanted the cheapest thing possible to get the bid; he could care less about features. And, I'm sorry to say, I think the motion picture exhibition industry is in the same frame of mind.)

Anyway, not to dissuade you or be mean or anything, but most theatres are happy with just a box full of relays and a cam timer.

>>The only comment I have about the XML coding idea is I would separate the "template" from the film/show document (hope I'm using the terms correctly..) so operators can't normally edit the "template." I'd be worried that someone might write it wrong and screw up a show or maybe even damage equipment. That's why I thought the automation would be designed to take a file that only had information about the film- and each particular auditorium would have it's parameters "hard-coded" in the automation.<<

You're right, absolutely right. This is something I haven't thought about much. I tend to trust the projectionists in certain ways, but that's probably somewhat naive in some respects.

That would get around the problem of frame counts being off when a damaged print is spliced, trailers are changed, etc.

 |  IP: Logged

DTS is already counting frames, & since it's switching audio tracks for different trailers, it's counting trailers. It knows the difference between a trailer & feature. If DTS put some data on each track at the start of the credits & at the end of the credits, some interface could be set up to just adjust what to do at start of show, , start of policy trailer, start of feature, start of credits, end of credits, & adjustable +/- X minutes or seconds at those times to do whatever the little local relay army should be told to do.

And it could follow the show from platter to platter...

Yes, that is what my system is meant to do. I actually started out wanting to create a simple reel-by-reel sheet structure for projectionists to follow in a c/o theatre (since that is my principal background, even though I've worked at multiplexes) but realised that my method was easily expanded to do just about everything else except for the coffee.

But now that I think of it, it could do that, too.

Re DTS timecode: I would love to use it for the reasons you list; if it was present on every film, it would take care of everything I need to synchronise any show. The frame count in itself is not a big problem but requires hardware no matter how it's done.

 |  IP: Logged