“Autofade” option in scheduler

Many broadcasters need to fade the playlist music just before the start of a news bulletin, or a new program. At the moment this requires careful but tedious timing of an additional fade command so the playlist is at zero volume when the top of the hour is reached. This can be cumbersome and adds additional work to every situation where this is required (prior to the start of most programs). Why not have an option in the scheduler such as this:
“Autofade [playlist prior to this event]”. (With the possibility to set the default fade point/length such as -5 secs). Note that a crossfade is not a solution in this case.
This would set RB above its competitors....
 
Chris are not Settings >>Scheduler Playlist fade in any good for you ? Ad you could record then schedule them ?
 
Many broadcasters need to fade the playlist music just before the start of a news bulletin, or a new program.
Can you please provide more details how it should work? Currently it will fade out according to the Fade Out setting as set in Crossfades.
 
We wish to be able to do the following without having to insert a separate command:

Every hour at TOTH there is either a news bulletin or a 55 minute program. At approximately 5 seconds before the hour, we want to fade out the music playlist over a period of about 5 seconds so that there is NO OVERLAP. We currently do this with a separate fadeout command, but if there is no event planned for TOTH, then the playlist can stop completely after the fadeout. To get around this we can use multiple commands I suppose, but given the frequency that fadeouts are required it would be far easier to build them into the scheduler as an option to tick (with selectable backtime of x seconds).

So the command for the news would include the autofade option (5 secs), followed by the start of the news. I suppose the time this all gets triggered in the scheduler could be 5 secs before the hour, although it would be more logical to enter the normal program time at its ToTH start time:

12.00 News [autofade or prefade occurs at 11.59.55; 0 fade in set in crossfades ]

We have not been able to reliably use crossfades to achieve the above - if you can show me how I will use it!
 
there is NO OVERLAP
You can get rid of overlap by using the "Override previous track mix point" option in the Crossfades, it's designed for such cases, when you want to play announcements or commercials in full without overlapping. You need to configure it for the News (at least, the first track that plays in the news block) so that Mix point for the preceding track is set to zero.

So the command for the news would include the autofade option (5 secs), followed by the start of the news.
Wouldn't it cause a small amount of silence right before the news?

Do we treat the news as overlay events?
You can. The fading for those events is controlled in Settings->Scheduler, you set both fades for the overlay event itself, and for the main playlist when the overlay event is started/stopped. I suggest you to try it.
 
Overlay will not work. At the end of the overlay the playlist fades in part way through a track rather than playing the next track. In any case, as a workaround, its a bit clumsy as some of the overlays would be an hour long. Also I forgot to mention that all of the TOTH events are preceded by a sweeper - so if the sweeper doesn't accurately finish before the hour, it's necessary to fade it out completely and then start the news. I cannot make it work unless there is a definite fadeout command inserted, which comes back to my original request. If a fadeout is warranted, then we should be able to start an event that incorporates the option to fade the preceding track or sweeper. So there will be two types of scheduled events: 1) start instantly at the time set or 2) start after having faded (over-ridden) the current track, sweeper or event. Surely this is not a difficult request.... a tick in the event scheduler enables the autofade option, saving us from having to carefully program a fade as a separate event.

One of the reasons for the need for this autofade is because the sweeper function can fall short of the hour, causing the next playlist track to drop in for a second or two, as I have raised with you before. Either the playlist must be faded, or playing 2 second bits of a track should be ignored.
 
a tick in the event scheduler enables the autofade option, saving us from having to carefully program a fade as a separate event.
Event settings is a very import window and every option there must make sense for the majority of the users. Adding it must be justified and I'm not really sure if it's really needed that much, to be honest.
You can try the following: add "next 5000" command to make it fade out for 5 seconds, then add pause for the duration of 5 seconds to make it "wait" for the fade to finish, and after that goes the news block.
 
add "next 5000" command to make it fade out for 5 seconds,
Thanks for that suggestion. I created a multiple event at 59:55 with this command followed by the pause and the news file and it works (as long as you remember that 5 seconds in next=5000 and in pause=5 (this is confusing)!

If you want to avoid messing with the scheduler then the above can surely be achieved much simpler by having a new fadeout command that does not STOP the playlist (as I have suggested in the past) or allowing the selection of autofade for events to be made in the advanced settings (precede all events by a fadeout of x seconds). The Fadeout command works OK as long as there is actually an event to follow, but sometimes if the event is removed for one reason or another (it might be an ad hoc relay feed) then the playlist stops abruptly and this is quite dangerous. Can the fadeout command (or a new command) have an option to not stop the playlist in the advanced settings?

Alternatively I suppose I could put the fadeout command inside the multiples box along with the next event to ensure the two remain linked...but then I would have to reschedule all my programs by -5 seconds and then the schedule looks illogical. I don’t believe my request to simplify this is not of interest to others because it is a standard broadcast procedure (fade program out to zero; pause a second if necessary; then start a new event such as news on the hour.
 
Thanks for that suggestion. I created a multiple event at 59:55 with this command followed by the pause and the news file and it works (as long as you remember that 5 seconds in next=5000 and in pause=5 (this is confusing)!
Fade duration is in milliseconds, while such precision for pause is not needed, so it's in seconds.

If you want to avoid messing with the scheduler then the above can surely be achieved much simpler by having a new fadeout command that does not STOP the playlist
But what will it do after the track fades out, move to the next track? I think that would be possible.

Alternatively I suppose I could put the fadeout command inside the multiples box along with the next event to ensure the two remain linked
Currently fadeout command will stop playback and no other commands after it will be executed.
 
But what will it do after the track fades out,....
Dmitry, the idea is to link the prefade of the playlist to the following event as a selectable default so one doesn’t have to worry about programming up to 100 fadeout commands - I.e. its automated! This is no less elegant than some of the other options you have programmed into the scheduler so I would have thought my suggestions offered you some ideas to think about, in the interests of improving and simplifying the way we use the excellent RB.

How does everyone else handle this requirement? This is how one operates when live, so the same should be possible while automated. 🙂 I’d be happy if you would consider taking this suggestion on board for a future update
 
How does everyone else handle this requirement? This is how one operates when live, so the same should be possible while automated. 🙂 I’d be happy if you would consider taking this suggestion on board for a future update
We'll start with improving the "fadeout" command and then we'll see if there are any further feature requests about it. Event properties window is already overcrowded and adding more options there will only make things worse :)
 
Back
Top