TUNETRACKER SYSTEM IN ACTION - TuneTracker

# Switcher (Command Center Only)

If you broadcast satellite programming, pay close attention to the information on this page, since the "Switcher" command is probably what you will be using extensively in your TuneTracker format clocks. You might even want to print this page and keep it handy for reference.

"Switcher" is a very powerful command for use by owners of our ChannelCaster switcher packages, such as the ChannelCaster 4™, the ChannelCaster 8™, and the ChannelCaster 16™. It is used to switch among different inputs and outputs on the Broadcast Tools line of switcher boxes to put channels on the air, and to respond to relay closures in various ways. Regardless of which of the switcher boxes came in your ChannelCaster package, you will use the same Switcher command and "syntax."

Switcher is the primary tool you will use when broadcasting syndicated, satellite-based talk or music programming. It is extremely powerful, accomplishing a number things in a single, brief command. Switcher routes audio channels while listening for relays. One of the relays it monitors will signal Command Center that it's time to cut away from the network and advance to what's next on the log. The HotTrack option (described near the bottom of this page) allows the Switcher command to also monitor a list of other relays, and respond by playing liners, IDs, jingles, etc. When the Switcher event is completed, Command Center goes back to ignoring the relays.

When you are using the Switcher command, you will not need the following older TuneTracker commands, which all still have their uses, but are more limited in scope: Route-For, Listen, Ignore, and HotTrack. For example, if you just need a time-based switcher event and don't need to listen to a relay, you can use Route-For instead of Switcher.

Don't be intimidated by the examples below. They just supply some very basic, straightforward information Command Center needs in order to fulfill your wishes. It'll make sense as soon as you read the descriptions beneath the examples. We've color-coded the first one to make it a little easier to "pick apart."


EXAMPLES
  1. # Switcher 00:20:00 Input 2 to Output 1 Listen 3 Blab Show Segment Three

    In Example 1, the Switcher command is followed by 00:20:00, which is the maximum length the event can be allowed to stay on the air. It's expressed in hours, minutes, and seconds. At the end of that time, Command Center will advance to the next event on the log, if it isn't interrupted sooner by a "relay 3" from the satellite network.

    "Input 2 to Output 1" just indicates which audio input on the switcher should routed to which audio output.

    "Listen 3" tells Command Center that it should advance to the next event on the log when a closure is received on relay 3.

    The audio routing and relay wiring numbers are information you should get from your Station Engineer, or whichever other person wired up your system for you.

    The final words in the line, "Blab Show Segment Three" are simply the label that will appear in Command Center while the switcher event is running.

  2. # Switcher 00:07:00 Listen 3 2-1 Blab Show Segment Three
  3. # Switcher 00:07:00.3 Listen 3 2-1 Blab Show Segment Three
  4. # Switcher 00:07:00.38 Listen 3 2-1 Blab Show Segment Three
  5. # Switcher 00:07:00.387 Listen 3 2-1 Blab Show Segment Three

  6. # Switcher BlabShowList 00:20:00 Input 3 to Output 1 Listen 3 Blab Show Segment Three

  7. # Switcher 00:29:00 Listen 3 2-1,7-2,16-3 Salvo Switcher Event
Example 2 is identical to Example 1, except we are using "shorthand" for the switcher routing, just saying 2-1. When you use the shorthand approach, you must put it after the relay Listen part, or it won't work properly.

Examples 3, 4, and 5 show you that you can get very "granular" about your expression of the length of the switcher event, down to a thousandth of a second if you like.

Example 6 adds a HotTrack list for responding to relays that signal the playing of liners, etc. That is described in more detail, just below. Note that we do not use shorthand switcher routing instructions when there's a HotTrack list in the Switcher command, and the HotTrack list's name immediately follows the word, "Switcher" in the line.

Example 7 demonstrates how you can do multiple audio switcher routings using a single Switcher command. If you want to do this discreetly, and without displaying the switcher routing onscreen or specifying a length of time, see the Route-on/Route-Off command instead.


NOW, LET'S TALK ABOUT HOTTRACK LISTS

In the TuneTracker System, HotTracks are audio files that play over the top of other programming. A perfect example is the traditional satellite element, the "magic call." Also known by other names, it's a custom station liner that is played over satellite programming when a certain relay closure is received from the network. Some networks have a variety of different liners they require you to play, and each one is triggered by its own unique relay closure. Our system handles that using a simple list, stored in a text file, that can look like this:

Listen 3 Comment ReturnLiner
Listen 4 Comment StationID
Listen 5 Comment Jingle

Each line in the list mentions a relay closure Command Center should listen to, and what it should do when the relay closure is received. In the first line, when a closure is received on relay 3, Command Center will play a file that has been given the Comment, "ReturnLiner." If there are several with that comment, Command Center will rotate through them, cart-style. In line two, when a #4 relay is received, Command Center will grab a file with the Comment "StationID" and play it, and so on. Simple as that.

You can create the HotTrack file using either the Pe or StyledEdit text editor (both included in your system). Then, save the file in the following, very specific folder location:

Station/Logs/HotTracks

If your installation doesn't have a HotTracks folder inside your Logs folder, create one. Put your HotTracks list in there, using any filename you like. Then specify that exact same filename in your switcher command. If the file is called BlabShow then in your Switcher command line, you should mention it as in this example:

# Switcher BlabShow Input 3 to Output 1 Listen 4 Label For Your Network Feed

Note that the filename of your HotTracks list must be the very first thing in the line after the word, "Switcher." Also note that you aren't restricted to a single HotTracks list, nor should you be, since stations with multiple networks often need different relay responses for each.


A SAMPLE LOG SEGMENT

The following format clock example assumes a satellite network that sends a closure on relay #4 when it's time to advance. We have made the length of the network segments a few minutes longer than we ever expect them to actually be, so the event won't time-out unless the netork fails to send the relay...in which case the time-out acts as a fail-safe and assures you still get your commercials played, albeit a little late.

# Sample Satellite Network Hour with TOH Newscast

# Hour 8

# Interrupt@:00:00
Rotate Comment StationID
Play /boot/Station/News/LocalNewsCast1.mp3
Play /boot/Station/Weather/Forecast1.mp3

# Switcher HotTrackList2 00:20:00 Input 4 to Output 1 Listen 8 ClassicsNet Segment One

## :19 Stopset (insert commercials here)

# Switcher HotTrackList2 00:13:00 Input 4 to Output 1 Listen 8 ClassicsNet Segment Two

## :30 Stopset (insert commercials here)

etc.

THINGS TO KNOW

What would happen, you might ask, if you didn't have any commercials scheduled between Segments One and Two in the log example above? The answer is that Command Center's BreakSpan™ feature will cause a seamless transition between two network segments if no commercials are found between them. That lets you feel free to include all the available network breaks in your format clocks, and just fill the breaks you want to/need to fill. There's no burdening yourself or your listeners with PSA filler in unneeded breaks, and no need to create extra format clocks to handle hours where you have reduced commercial inventory and use fewer breaks.

Don't use the "shorthand" switcher routing approach in a Switcher event line containing a HotTrack list. It won't work properly. Use the "longhand" approach, saying, for example, "Input 3 to Output 1" instead.

Any relays being monitored by the Switcher event will be ignored after Command Center breaks out of the Switcher event and starts playing the next thing on the log. That is true whether the Switcher event times out or is interrupted by an advance caused by relay closure.

An automated Switcher event can be manually "killed," just the same as a live event, a commercial, or a song. Just click on its blue button to take it off the air.

As with most other programming elements, Switcher events are subject to the same universal overlap settings as the rest of your Command Center programming. That means it's wise to add one second (or whatever duration you have universal overlap set to in System Preferences) to the length of your Switcher event.

Currently, there are no provisions for fade-ins or fade-outs in Switcher events, so even if an Interrupt specifies a fade time, it will not be observed.

If you want to use a Switcher event for a timed event that doesn't require a relay at the end, such as a newscast, you can trick the Switcher command by entering a "Listen" relay number that is not in actual use. Alternatively, you can use the Route-For command, which has no Listen option.



Table of Contents