- Hearing Is Believing: Give Your Log A Listen Before You Send It
- What is your station’s actual format?
- Using A Secondary Artist Keyword Field
- Genius Days: It’s More Than A Free Lunch
- Don’t Duplicate Your Cart Numbers
Make It Your Own! posted on July 17th, 2017
By Drew Bennett
When I was young and just learning to program a day’s music log, my main issue was not being aware of what I needed to know about the music I was scheduling. Sound codes, Mood, Tempo, Type and Texture were mostly foreign to me. I can sit here and remember working on the DOS-based version of MusicMaster at KNNC in Austin, TX and thinking back then, “I guess I’ll just schedule this music the way the other guy showed me and then fill in these unscheduled positions and…done.” I bought my first PC in 1997. I got serious with learning about computers and the software I used at work every day. A majority of my time was spent reading the MusicMaster-DOS manual and that began my journey toward a passion for the science and art of music scheduling. Sound codes, Mood, Tempo, Type and Texture became my main daily focus. As a result, I listened to music differently than ever before.
My point is that I began to pay attention. I developed a personal sense of music and what made songs slow or fast, pop or rock, etc. I have my own opinions about what constitutes a sad song or a happy one. You do too. That personal sense of attributes that apply to a song needs to be in your music library if you program a radio station. If you landed a new job as the PD or MD of a heritage station in your favorite city, what would you do with the music when you got there? It might also be a good idea to ask what the last guy did with the music when he got there, too. How many programmers have touched this database in the last few years? Who uses this database day-to-day? Does a consultant have access to it? Do they make changes? These are big questions you should ask when you walk into a new situation at a radio station. You’d be surprised to learn that these questions are rarely asked by programmers and many times, databases are filled with data that’s been inputted by the last four or five programmers that worked at the radio station.
When you are tasked with a new job of scheduling music at a radio station, your first line of business after filling out a direct deposit form is to get into the database and make it your own. Take the bold move of wiping out every attribute in each song card and start over. If “Faithfully,” from Journey is a slow song, you need to have been the one who decided that and coded the song. If you do not, you are relying on the opinions of others to program your radio station. It’s as if someone is living with you in your own house! Perhaps not, but it is bad data. It is not yours and it could affect your music logs in a negative way.
To remain consistent with your music, it is a good idea to keep a one-sheet about your database. In that document, list coding examples in song cards and helpful notes about clocks or other areas you might use like Gold Recycling.
Slow Tempo = “Vision of Love” – Mariah Carey.
Rock = “New Sensation” – INXS.
“We use Migrating Positions during the afternoon to keep variety in the quarter hour between our ’60s category and our ’90s category.”
“Category P uses Gold Recycle. We pick up at 9am for 8 hours and we drop off at Midnight for 5 hours.”
You will save time exploring the software if your notes are thorough and you will help programming assistants and/or consultants get around the data if they need to review your work.
Making the database your own by coding every record yourself and keeping notes about your database for quick reference is the best way to keep good data and a tight ship in the programming department. Here are some extra tips to consider as you get started:
Clone your existing database and make your changes there. That way, you can keep a music log going in the original data and you can trade the old data for the new data when you are done. The idea that you can make mistakes in copied data is also a plus. Once you are done re-coding the data, think about a review of your rules and how they may need to be changed to adapt to new coding.
Do you have more tips on curating your own music scheduling database? I would love to hear about it. E-mail me at firstname.lastname@example.org. Happy scheduling!