JOHNSTON, IOWA
I have been involved in automation projects since I first began working in broadcasting. My first real chief engineer position was at a beautiful music station in Santa Barbara, Calif. We ran a Shaeffer 800 automation system that used subaudible cue tones on reel-to-reel music tapes. It had a couple of carousel audio cart players and a spotter reel with a photo sensor to count the number of windows that passed on the reel to find commercials.
The logic was based on open-frame automatic electric relays and mechanical switches. The purpose of the system was to eliminate the button-pushing errors that DJs often made, and to cut down on personnel. My second real chief position was at an AM/FM combo in Palm Springs, Calif. There, we used a Shaeffer 900 (diode-transistor-logic solid state) with a similar complement of tape sources, but no spotter machine.
WITNESS THE MARVEL
The automation was on a raised platform in the main lobby where visitors could watch this marvel of technology. The receptionist was responsible for feeding the automation system during normal business hours, while the AM jock did transmitter readings for both stations.
The AM jock was responsible for both jobs at night, and it wasn’t unusual to hear the piercing silence sense alarm in the background while the AM jock was on mic, or to hear a Top 40 single play to the label because the jock was out in the lobby loading tapes on the automation.
I realized that based on those implementations, you could run a station with fewer people, but I wasn’t sure we were really reducing errors.
Moving forward to the 1980s. I had left radio and become the director of engineering for an NBC affiliate in Honolulu. NBC had just completed their conversion to the new Ku-band (SkyPath) satellite delivery system. Unfortunately, the Ku-band coverage is continental United States only, but because NBC had some paying customers in the Caribbean (if memory serves) they had an East Coast feed up on a C-band satellite that we could see. However, we were recording NBC programming and delaying it locally for five or six hours, depending on whether or not the mainland was on daylight savings time.
NBC also had commissioned a half-hour, time-delay system for some Mountain Time zone stations; I went to see at 30 Rock. It was a fully redundant tape-based system (MII, of course) that delayed a feed with managed recording and switching. I met with the system designer and put together a propos l for doing a five- or six-hour delay system using Beta SP.
Unfortunately, the station was sold and the new owner was not interested in investing, so the idea didn’t go any further. However, in an effort to at least appear interested, the owner ask for alternative ideas. I put together a plan for a six-hour delay using Belden 8281 and a frame synchronizer… he didn’t see the humor in it. Again, the idea here was to reduce the manpower and eliminate some errors.
ONE MORE TIME
When I was working another NBC affiliate in Huntington, W.V., in the ’90s, conditions came together to provide another opportunity to automate. I had proposed automation again, but this time it was computer based.
A small independent company had developed a product for The New York Times stations called MCAS. I went to see a demonstration in Memphis and was impressed not only by the automation, but by the fact that it could interface to all of our existing hardware, which made it relatively inexpensive.
In addition, we had two master control operator positions being vacated, one by an internal promotion and another by voluntary resignation. I made the case that we could do automation, get all of the benefits, no one would lose their job and payback was less than three years. It happened at last. In our environment, MCAS turned out to be a really good investment, but I had always felt that there was a missed opportunity.
PUSHING BUTTONS
In all of the previous examples, the master control automation represents a sequencer taking the place of a human, essentially pushing the buttons the human would push.
Master control automation has full knowledge of the operation, oversees the content output and logs it. In the other end of the building, a traffic department has full knowledge of all of the content, oversees when it plays and creates the output schedule.
The interface between these two systems is typically a log print file created by the traffic system and delivered to automation. The automation system creates a playlist from the log file, does a little conflict resolution, relays that to the master control operator for action and then implements the playlist.
The automation creates an as-run log, which is then sent back to traffic for reconciliation. Traffic then uses that information to invoice for billing and make to a list for things that didn’t go right.
The most noticeable change in the automation-traffic interface is that the playlist is delivered via Ethernet to a shared folder rather than on a diskette. There had to a way to take these two separate entities and make them a real system.
Welcome to 2007, and a very important piece of work that is making its way through the SMPTE standardization process. It is the SMPTE Draft Standard 2021 Broadcast eXchange Format, or BXF for short.
BXF is a protocol for data exchange among otherwise incompatible broadcast systems. Often, incompatible systems are purchased within a single organization because only the needs of a particular division are considered. BXF offers an interface standard that allows the traffic and master control folks to pick the system that meets their respective needs. As long as both systems speak BXF, they can communicate.
JUST THE BEGINNING
This is just the beginning in my view. My idea for true automation involves dynamic communication, problem solving and taking advantage of opportunities in real time. Traffic and automation still require the log to be etched in stone before it can run. The only difference is that the tools can more quickly etch the stone.
This fails to utilize some of the capabilities of the technologies involved. I see the next iteration as traffic driving master control automation, with dynamic logging and conflict resolution. Why just create the as-run and then reconcile offline? Why not reconcile in real time?
The traffic system would know when a make-good could run. Traffic would tell automation to play it in the next break instead of the promo or PSA or bonus spot. Automation would do the make-good and tell traffic. I can see this level of dynamic interaction working when live events run long.
How many of us have worked with a live sports feed and the various alternative schedules for what happens in overtime. Does the network fill? Do we join-in-progress the syndicated show? All of these scenarios can be automated, and what happened, dynamically communicated.
Why not look at the process from the standpoint of how to change the way we do business so we can focus on developing our audiences rather than making the log and playlist agree.
Obviously the manufacturers are starting to take BXF seriously. I asked Chris Lennon, the BXF committee chair, for his take on where they are.
“The development of SMPTE-2021, the BXF specification, is progressing nicely,” he said. “We are presently in the process of resolving comments arising from our first Final Committee Draft ballot, and are meeting in person in early June to progress this further. I was pleased to see several companies demonstrating support of BXF at NAB2007. It shows that this is a standard that is relevant, and will be implemented by vendors quite rapidly.”
I have had the opportunity to sit in on a number of the BXF conference calls, and I can tell you that some very brilliant engineers are working on this. The one area I feel might be under represented is the end user; the stations. I encourage you to spend some time and effort looking at BXF and getting involved. In all likelihood it will change the way we do business.
