Please enable JavaScript to view this site.

XStudio 3

Navigation: Reference

Programming XStudio

Scroll Prev Top Next More

Developing your station's air sound is a creative process, requiring a strong sense of what your potential listeners will be attracted to, along with some sound judgment. Once you determine what the "sound" or "format" of the station will be, it's a matter of explaining it to those who will execute the steps needed to achieve that "sound."

Unless you are starting a new radio station, you probably already have a program format which outlines the general sequence and positioning of various audio elements, are creating daily broadcast logs (program schedules) which provide the specifics of execution for a given day, and either staff people or an automation system of some sort is interpreting this information to produce your on-air product.

For purposes of this discussion, we refer to "Programming" as explaining to XStudio how you want things done to produce the desired on-air product. In most cases, you already know what you want XStudio to do - it's a matter of telling XStudio what you want done and when.

In order for XStudio to execute your format properly, you need to complete a few steps:

Update Station Format Clocks. If you already have formats in your music and traffic scheduling systems, they need to be reviewed and perhaps updated with specific instructions for XStudio. Such changes may include placing Log Directives in the formats.

Assign Audio Switcher Inputs and Outputs. If XStudio will be controlling an audio switcher and you will be switching among audio sources, you will need to create an external resource record and assign it to XStudio.

Create XStudio Tasks and Actions. If XStudio will be performing automated tasks such as controlling an audio switcher, starting playback of a break or playing specific jingles, the appropriate Tasks need to be created and assigned to Actions. Subsequently, the Actions will be connected to a specific input relay on an audio switcher, become a scheduled event, connected to a hot button or placed on the log for execution.

Produce a daily log. The log needs to have the appropriate content and special XStudio commands known as Log Directives. Producing a daily log may be as simple as exporting the log from your traffic system or may involve using LogMerge to combine (merge) logs exported from your music scheduling and traffic systems to produce the finished on-air schedule. Most popular music scheduling and traffic systems have export routines to convert their logs to our generic log format.

dcsTools makes available a number of optional programs and utilities that can be used to accomplish these and other tasks. See the topic on Companion Programs & Utilities for a additional information.

How does it all tie together?

First and foremost, the broadcast log (program schedule) dictates what audio will be played during a given day. It is important that the log have all audio content, correctly identified by cart number, scheduled to play, as well as a general sense of when it is to play.

If you are operating your station as a live operation, with a live announcer running all air shifts, there's not much more to do than get the log organized properly and available for XStudio to load from disk as needed. The on-air personality then simply uses XStudio as an on-demand playback device. In fact, the log becomes more a guide, as the personality can choose to play or not play scheduled items, move the items around on the schedule, and play other audio not on the log in an ad hoc, on-demand way.

The reality of today's radio, though, is that it's likely one or more air shifts during the day or overnight will be some form of "walk-away" programming, where there's nobody in the control room and XStudio needs to assume the complete responsibility of controlling your air sound. This is when XStudio operating modes, log directives, audio switching control and Actions come into play.

These "walk-away" or "automated" times are generally organized in one of two ways:

1.All program content that is to be aired is present on the log and is played by XStudio. This is commonly referred to as "local automation". In this scenario, XStudio will play log content from a starting point on the log in a sequential manner. Periodic adjustments for over-scheduled content may be made, using so-called "hard sync" and "soft sync" methods, which are driven by the log.

2.Program content - music or talk show content - is delivered to the station via satellite and at certain times throughout an hour the station is signaled to insert local audio content; typically commercials, local weather and local news, for a specific amount of time. This means that the satellite program feed needs to be taken off the air, the correct local content played and then, the satellite program feed needs to be restored to the air. In addition, the local station may be called upon to play jingles or liners on-demand based on a signal from the program service. This is often referred to as "satellite automation." This approach requires XStudio to respond in a non-sequential, asynchronous way to outside stimuli, typically as a result of an input relay.

As you might guess, these two scenarios need to be handled quite differently by XStudio, which is one of the reasons multiple operating modes are available to customize the behavior of XStudio for a particular type of automated performance.

Perhaps the best way to understand how all the pieces tie together is to look at specific examples. The next sections provide examples for satellite automation and local automation.

Quick Links

Satellite Automation Example

Local Automation Example