Frequently Asked Questions

Live satellite game or special event programming

How to program for a live satellite game or special event

There are many ways to get a live game feed into your daily programming. Here are some ways to do that. I will use a Eugene Generals junior hockey game as my example.

BUILD SOME CARTS:
Let's start by creating a "GAME START" cart and a "GAME END" cart.

The GAME START cart should contain macros to turn on the trigger set for your game (which I'll cover building the trigger set later) and a macro to turn off your normal daily scheduled event that contains the CHAIN macro. We move away from the scheduled event with the CHAIN macro in case the game goes past midnight and we don't want to continue with normal programming while the game is still in progress.

If you don't have any other back ground recording or need get weather updates during the game, simply load the none.skd that has no commands. For the trigger set, we will use a Generals.trg (that we will create later). So the GAME START cart will look like:
GAME START cart

Notice how the first item in a cart is a blank cue type and the following item(s) is a + autostart cue? That is so the entire cart contents are processed when the cart is played.

The GAME END cart gets us back into normal daily settings and back to daily programming. The tricky part is getting back into the daily log at the right spot. In my scenario, I play music from hard drive and don't use triggers from a satellite, so I'm going to load "none" triggers. Since I'm using a Broadcast Tools 8.2 switcher, I'm going to use a SERIAL command to switch back to the Simian as the audio source. If you instead use an audio pass through the computer's sound card, you would use a MIXFADE command to mute the satellite pass through mixer. My normal daily scheduled events with the CHAIN macro is named daily.skd, so I will load that up.

We want to use the LOG LOAD command to take us back to our normal daily log (which mine is named on the two digit month, day, year so I can use the date meta-variables). The difference between the LOG LOAD command and the CHAIN command is that the LOG LOAD doesn't offset the day/date so it will always load the current day/date. We use it because if the game ends before midnight, say at 11 PM, we will load the current day's log. With the CHAIN, that would instead put us in the next day's log which we don't want. After the correct log is loaded we want the GOTO command to get us to the correct time in the log. We have to reverse the order in the cart because jumping to a new log will cancel any commands that were after it in the cart. But since we want the GOTO to fire on the after our normal log has loaded and not in our game log, we have to use the DELAYEXECUTE macro, which will delay the GOTO macro until after the LOG LOAD macro fires. Here is the GAME END cart:
GAME END cart

It's critical that the GAME END cart is run to return to the normal daily log, scheduled events, triggers, etc. I've seen satellite providers not send down the correct relay or amount of relays to get the GAME END cart to run. An operator caught this and just loaded the correct log under File > Open Log. The log was correct but they later missed the CHAIN command from the scheduled events and responded to the incorrect triggers, etc. I suggest placing the END GAME cart on a Hot Key so if this scenario presents itself, an operator can recover all settings and load the correct log with a Hot Key press.

The other carts I like to build are ones for toggling your audio sources between Simian and satellite, as well as magic calls/station identifications/legal IDs, etc. Placing SERIAL and MIXFADE macros in carts instead of directly in the program log has a couple benefits. First I can give the carts a description that me and my operators can identify the command in the program log without needing to know the unfriendly syntax of a macro. With the cart scheduled in the log instead of the macro, if needed I can change the macro in the cart itself and not have to touch the program log since it's calling to the cart.

So, the next cart is SWITCH2SIMIAN which contains the serial command to move the switcher to Simian as the audio source:
SWITCH2SIMIAN cart

The following cart is SWITCH2SAT which contains the serial command to move the switcher to the satellite input as the audio source:
SWITCH2SAT

For legal IDs, station identifications, magic calls, those type of relays the broadcasters will be sending down for you to play, it's easier to have audio play when the trigger is fired versus creating places for them in the program log. So I create a cart to place in the trigger set that will switch the audio to Simian, play the file (named LEGAL ID), and then switch back to satellite. Let's call the cart GENERALSID and fill it with:
GENERALSID cart

That does it for the carts we'll need.

BUILD A TRIGGER SET:
Local breaks and station ID's are generally dictated by the flow of the game, not extact times. You should have a "clock" or radio format document that lists the number of breaks and identifies what relays will be sent. There should be atleast 2 relays - one for breaks and the other for network IDs. Your engineer can tell you how the relays are wired to their corresponding triggers. With that information, create a new trigger set. The trigger that starts the break will be populated with the STARTNEXT macro. The trigger for the network ID will be populated with the ID cart we made. In my scenario, that would be the GENERALSID cart.

Generals trigger set

There may be other relays as well. Some sports broadcasts will send a specific relay that denotes the end of the broadcast, especially if that event can be cancelled due to a rain delay. If that is the case, then put the END GAME cart on that trigger.

BUILD A LOG:
Have your normal 24-hour daily logs programmed as normal. Build a log specific for the event you will air live and place a LOG LOAD command with a @ Time Immediate cue type in the at the scheduled time. Don't worry about cutting out the events from the daily log that won't air as they will simply be skipped. So if the Generals game starts at 7:35 PM and I've built a program log for the game named "Generals", it would look like this that day's daily log:
@ 19:35:00 LOG LOAD, Generals
And it would be placed in in the 7:35 PM time range of my daily log.

Daily program log

In the Generals.bsi log, the first item will be the GAME START cart with an autostart cue, so it immediately fires with the log is loaded. The next item will be an autostart SWITCH2SAT cart so you get right into the game feed. The remainder of the log is going to be a repetitive pattern that matches the number of local breaks in the game's clock. We don't account for network only breaks, just the local breaks. With Simian's default settings of color by continuity, the breaks should alternate between white and yellow.

Since we are relying on the game broadcasters to fire our local spots on Simian, our first item in our break will be a manual cue type (which a blank cue field). This means Simian stops at the item and will only play the item if an operator or STARTNEXT trigger plays it.

I'm going to recommend that you insert a COMMENT from Event Builder as the first event in a break/stop set. The game clock will give each break a number and we're going to use that as the text in the COMMENT macro. This will be placed in the program log, followed by a SWITCH2SIMIAN cart, your commercials, and ending with a SWITCH2SAT cart, all of which are autostart cues. Like so:
Generals program log start

When the STARTNEXT trigger is received, it will play the comment and all the events that follow that are autostart cues. The last being the SWITCH2SAT cart with the command to switch back to satellite, at which point we will rejoin the satellite feed until the next STARTNEXT trigger. Place as many commercials you need between the SWITCH2SIMIAN and SWITCH2SAT carts as needed.

TIP - create a skeleton log (for example, Generals_skeleton.bsi) with everything except for your commercials. That way, you can always go back the skeleton log with it's basic frame work should you need to.

Since we are completely reliant on the relays from the game to advance the log, there will be no time event (# and @) cues.

If your broadcast doesn't send a relay that indicates the end of the game broadcast, then they will send a specific amount of STARTNEXT triggers for each stop set (even if the game goes to overtime) and instead of switching back to satellite with the SWITCH2SAT cart after the final break, you will put the GAME END cart with an autostart cue. Like so:
Generals program log end

And that does it for one way to program logs for live satellite sporting events.


 Last updated Thu, Jul 10 2014 1:25pm

Please Wait!

Please wait... it will take a second!