How my understanding of radio programming has shaped my concept automation

This is a commentary I have been meaning to write for quite a while, but I’ve been pretty busy the last month, so haven’t done it yet. Over the years, I’ve been playing with the concept of developing my own radio automation system. This concept has evolved over the years. How it has done so closely aligns with how my understanding of radio programming has also evolved. Let’s take a look at these concepts.

The Digital Carts

This first concept is what I’m now going to call the digital carts, because even modern digital systems call what I’m about to describe carts. This was a completely live-assist system in which each key on the keyboard was programmed with an element. All the user had to do was press that key and the corresponding element would play. Of my early concepts, this would actually have been the most practical, as it’s my understanding now that prior to computer automation, the program director would have to write out by hand, or possibly type, a schedule for the day. Instead of the jocks having to fiddle with records however, my system would simply require the press of a button to fire the next element. The downside would be that your station would have to be staffed 24/7 in order for this to work, and even by the time I came up with this concept at 14, stations were not hosted overnight.

The Audio Editor

Next was the audio editor concept. This system would have been highly impractical, as every element had to be dropped into place by hand, then listened to to make sure things sounded correct. You would also need multiple sound cards, one to hear what you were doing and one to actually play stuff out. At a professional station, this probably wouldn’t be a big deal as these things exist already, but I mainly saw this system on blind stations which mainly use Station Playlist. I suppose that wouldn’t have been too impractical for a station like that, as hosts on those stations usually do a few hours a week with cloud-based automation filling the rest of the schedule. Still, I could see this being a bit cumbersome, and for a professional station, the person programming the automation would need to keep a close eye on the time to make sure all elements played when they were supposed to. The blind station I was most familiar with didn’t have any such requirements though. I would imagine too that the project file would get quite large after a while, I didn’t even think about how that would work.

Multiple Playlists

Next was a concept I developed in 2013 after realizing that the powers on my local CHR were actually played in a specific order at a specific time. Thus, the concept of multiple visible playlists. The way this worked was that you created as many playlists as needed, then added your songs to them until things were ready. You could also time elements to play at certain times, but otherwise the first song in the first playlist would play, then the first song in the second, and so on. I could see how this could be challenging for a presenter to see what is coming up next or even how they could know when to talk.

Current Concepts

I am lumping the last two concepts into one heading because they are the most similar to each other, and also the most like what my actual system would look like. The first concept had a library that consisted of categories, to which each element had to be assigned. For music rotations, subcategories did exist. The system would then continuously generate the playlist as it went. While the schedule wasn’t visible on the main screen, the system did keep track of the time in the event scheduler, and via a checkbox, would advance to the next hour as close to the top as it could.

Many of these concepts carried over to the concept system as it currently exists. The library and individual categories are gone, but they have been replaced with a list-based system, similar to Zara Radio. There are two big differences between my system and Zara:

1. You can actually build hours. In Zara, you can start things at the top of the hour, but you would have to create an event that repeats hourly, and make sure its timing was right for your station. With my system, you will be asked which hour you want to use when making the schedule, then it will use that hour until you tell it otherwise.
2. Next, a schedule actually exists. With the free version of Zara as it currently exists, there is no way to see what song is coming up next. It is my understanding that in the version of the program after the one I have, the filename of the next file is shown, but you can’t look ahead 15 minutes, let alone several hours. It is also my understanding that you can assign voice tracks in the playlist itself in later versions, but in the free version you can only assign them to a song. In my system, this is all done through the scheduler.

All of these show an evolution in how my knowledge of programming has evolved. At first, there is no plan, just a random selection of music. It was only much later that I knew that a schedule was written up ahead of time, before I figured everything was just picked at random with rules about what elements played where. Now, having studied programming a bit more, and actually worked with a few systems, I know that this is not the case. While my understanding of programming will continue to increase, I don’t see too many more changes in my system’s interface. Even as this is being published, my concept interface is still being refined, but they are now small changes, not the drastic ones that have come with updates in the past.