Special events programming while operating in Satellite mode might include satellite-delivered sports broadcasts, music specials like count-down shows or any other satellite-delivered programming that varies from normal operations. This example assumes you are familiar with and have constructed all the needed elements for your normal satellite programming operations.
The basic changes needed to transition to special event programming from "normal" programming in Satellite mode and eventually resume normal programming include:
•Changing how XStudio responds to relay closures during the time special programming is airing.
•Setting up Actions to handle the special event's join, local commercial break and program end signals. Depending on the type of program, there may be additional requirements.
•Revising the log to reflect the correct number and length of breaks to be used for the special program.
•Revising log directives so that local commercial breaks are handled strictly in sequence rather than being driven by time.
•Restoring normal operations at the conclusion of a special event program.
|
To make things as simple as possible for this example, the special event program we'll be working with is just one hour in length. When broadcasting a football game, for instance, it is likely the event would last up to 3 or more hours. The principals of setting up and executing the programming are the same, though. For longer events, there are just more commercial breaks and other requirements, like joining the game and finishing up the game, are the same as in our example. |
Transitioning to a Special Event Program
When running satellite-delivered programming, there are normally a number of relay closures signaled by the programming service to do such things as play a liner, play a station ID, and play a commercial break to name a few. To transition to our example special program, we'll assume that a relay closure will be used to start the event, signaled by the program provider. If no such signal is available, you could perform the transition (or join) using a log directive or a scheduled event.
To join the special program, we need to open the correct channel on an audio switcher, disable response to relay closures for our regular programming, and make active relay closures that will be used to signal commercial breaks and and the end of the event. Here are the steps for our example:
1.Create an Update Switcher task to open the correct audio channel used for the event.
2.Create a Remap Input Relays task, which has the effect of "unhooking" relay closures you don't want to respond to during the event and connecting Actions to input relays so you do respond to the special program's relay closures. See step 5 for information on the special event relay closures - you may want to create those items ahead of time so you don't have to go back to this task item and revise it.
3.Create an Action that contains the two tasks described in steps 1 & 2.
4.Attach the Action created in step 3 to the input relay that will start the event. Note that we're attaching the start event Action to the default switcher input relay mapping. It is done this way since the default switcher input relay mapping will be in effect when the special event start is signaled.
5.Create any needed Tasks and Actions to handle things that will happen during the special event. Typically, there would be an Action to perform the breaks and an Action to resume normal programming at the end of the event as a minimum. You might also have a requirement for a station ID or audio bumpers. Any Actions that are to be active and signaled by the program service will need to be attached to the correct input relays in the Remap Input Relays task created in step 2. In our example, your Action to resume normal programming will include a second Remap Input Relays task which restores the default input relay mapping to the switcher.
Now, we're ready to join the special program when the program start is signaled by the provider. When program start is signaled, the Action created in step 4 above will be executed. The program's audio channel will be opened on the switcher and all normal relay closures will be inactive and just the special event relay closures will be responded to by XStudio.
Revising the Log
The main difference between normal programming and special event programming is how the log is constructed. Special events like sports broadcasts present a challenge in automated execution because the timing of commercial breaks is not predictable. The timing of local breaks is dictated by the flow of the game and they could occur at intermittent intervals. However, most events of this kind do have a fixed number of breaks that will be taken during the course of the event and the breaks will occur in order.
In order to tell XStudio that breaks are not time-sensitive, we use time approximate load directives for the in-event commercial breaks, as shown in our example log.
Special Event Log with Time Approximate Directives
In our example, the special event begins at 4:00 PM. The log has a standard load directive at that time, so at 4:00 PM, the first break of the special program becomes the "active" directive (active break). At this point, we will have received the start event signal from the programming service and the program is one the air. XStudio is positioned on the log for the first break and is awaiting the break relay closure.
You'll notice the next 3 directives on the log are time approximate directives and that the first of them is marked as the "NxtA" (next time approximate) directive. The 5:00 PM directive is a standard load directive - it's at that time we'll be returning to normal programming in our example.
When the first break is called for by the program provider, the 4:00 PM break in our example is played. At that point, XStudio marks the 4:10 PM time approximate directive as the "active" directive - meaning it will be the break played when the next relay closure for a break arrives. Unlike normal programming using standard load directives, though, XStudio "locks" onto this directive and will not move from it until the break plays. This means the break could com as late as 4:25 PM and unlike normal programming, the "locked" break will play even though there's a directive at 4:20 PM. In effect, once XStudio starts processing time approximate directives, the breaks are now played sequentially without regard for the time.
In our example, for instance, all three of the time approximate breaks could be called in the first 15 minutes of the hour or the last 15 minutes of the hour and all would be performed in sequence.
While all breaks in our example are of the same length, they could be different with no difference in how XStudio performs them. The key in that case is to match the lengths of the breaks in sequence to what the program provider will be doing.
Resuming Normal Satellite Programming
In our example, we handled a 1-hour program. You'll see on the example log that at 5:00 PM, we have a normal load directive (not a time approximate directive). The effect of this directive is that at 5:00 PM, regardless of where we are in terms of the playback of time approximate breaks, XStudio makes this directive the "active" directive. In short, our log is back to normal.
The program service sends its program end relay closure at the end of the event. In our example, that closure comes at 4:59:50. When XStudio detects the closure, it performs the end program Action you defined earlier, which in our example includes playing a 10-second station ID, a Remap Input Relays task that restores responsiveness your default relay closures, and an Update Switcher task that puts our normal program service back on the air.
