|
| TUNETRACKER SYSTEM IN ACTION - TuneStacker |
TuneStacker User Interface
TuneStacker is a very quick learn. All controls and Preferences are right on the front screen for easy access. Let's go through them one-by-one.
- The "Master Log" requester lets you type in or browse for the master log you want to use. You may also select a master log by simply dragging and dropping it onto any part of the surface of TuneStacker. You can also test out a single format format clock hour by specifying that as your master log.
- The "Program Log" requester seeks the name and path you want to use for the program log you are generating.
- The "Traffic Log" requester seeks the name and path of the traffic log you want to import and integrate into your program log (TuneTracker Command Center Only).
- "Scan Volume" lets you choose which hard drive or drives will be scanned during random searches for music and other audio files. The dropdown box lets you place checkmarks next to the drive volumes you want included in the search. If more than one hard drive volume has been selected, "Multiple Volumes" will appear as the title of the dropdown box.
Next comes the ProximityGuard section. ProximityGuard gives you control over how closely the same randomly-selected files will be allowed to appear on your program log. In TuneTracker Basic, TuneStacker gives you a single level of protection. In Command Center, you can have up to five (in "Basic," all five are there, but using more than one will cause it to protect poorly).
As an illustration, let's assume you have a music library of 850 songs, taken from 610 albums. Represented in the collection are 641 artists. The mix includes 6 distinct genres. All the songs have been rated by tempo as "fast," "medium," or "slow."
Now, let's say you have decided that you don't want the same song title to appear on the program log any more frequently than once every 300 lines. So in ProximityGuard, you set the first entry to:
- Protect Based on Title for 300 Events
That may not be enough protection for you, though. After all, since you have more titles than you have artists, it's possible you could wind up with two songs back-to-back by the same artist. So you add a second layer of protection*. Click the "Add" button and select the following for layer two:
- Protect Based on Artist for 100 Events
Now, consider this. Since you have three different tempo classifications, you may decide you don't want to risk having, for example, three slow songs playing back-to-back, which is a distinct possibility. So you set yet-another layer of protection:
- Protect Based on Tempo for 3 Events
Still not satisfied? Want to keep the same genre from popping up too often?
- Protect Based on Genre for 4 Events
Granted, our imaginary station's music collection has 6 different genres. But consider that you may have 300 in one genre and only 50 in another. So sometimes you have to be careful to weigh the implications of your protection scheme.
Another issue which might not be immediately evident is that you can't set a layer of protection to a number greater than the number of songs or other audio cuts matching the criteria specified in that layer. For example, TuneStacker will be unable to comply with your wishes if you tell it to protect by Album for 800 events when you only have 610 unique album names.
You can set up to five* layers of ProximityGuard protection to be active, all at once. The only thing to keep in mind is that the more layers of protection you include, the longer it will take for your program logs to generate.
Another factor affecting the length of time it takes to generate a program log is how close your protection number comes to the amount of available cuts. For example, if you have 400 song titles in your collection and you specify 399 as the level of proximity protection, you will have a longer wait than if you set the protection for 200 adjacent events.
FINAL NOTES ABOUT PROXIMITY GUARD
When it comes to levels of proximity protection, more isn't always better. Sometimes it's difficult to anticipate all the implications when you get beyond two or so layers of protection. Some planning and some testing are advisable if you want to stack many levels of protection. You'll be able to tell (in Command Center) if you've gone overboard if you notice items that fail to be properly protected. If TuneStacker's settings are unrealistic, TuneStacker will "give up" and just add a song without regard to how recently it was used. You can get a line-by-line accounting of how often TuneStacker has had to disregard protection if you generate your program log using TuneStacker from the command line.
Because you are protecting by "x" number of adjacent "events," not adjacent "songs," it's important to take that into consideration. Each "event" is one line in your master log, and that includes non-audio events such as memo lines, Time-Corrects, etc. You might have 80 events in an hour's worth of programming, but only 11 or 12 songs. So it's best to err on the side of abundance when setting your proximity protection. It will take longer for your logs to generate, but it's worthwhile if it gives you the degree of protection you need.
* Users of TuneTracker Basic should not attempt to use multiple layerss of protection, because it will not function properly. Limit your ProximityGuard to protecting by a single item such as Artist or Title. TuneTracker Command Center users can safely stack up to five.
Table of Contents
|