Hi,

The example seems to be going about the problem kind of backwards. Heres how I have my logs (in a very rough way)

Music/Advert/Whatever on Play Transitions

LIVE MARKER to act as a memory aid for presenters on Segue Transitions (Segue isn't important just as long as its not a stop its fine).

Music/Advert/Whatever on Play Transitions

When we go for on the hour news or whatever the presenter hits automatic mode and answers phone calls or gets some tea etc.

If they are late, or the building sets on fire the auto mode skips through the memory aids by virtue of automatic and no stop. If the presenter turns up, they put it in manual and everyone is happy.

On occasion the next songs starts as a presenter forgets to go to manual but we either just play it or they use it as a bed or something (or just fade the thing down) so its not a big loss.

There was a nice feature in Dalet where by it would auto pull in some random music without skipping over the presenter slots (unless there were timed events) but in all honesty its not a feature we've really missed over the last 9 months.

As for the stops, I have lots of these in the logs but remember timed events will start the log again so as long as you map out the logs properly its not usually a problem you should have.


On 2013-09-22 07:17, Jay Eames wrote:
I believe the OP might, like me, have had experience with a playout
system like Myriad. 

The "auto" mode would ignore any soft "presenter link" type stops
between tracks, but would still respect any and all hard timed
stop/start events. This allowed for the system to put into automation
if a presenter was not available for their shift (think community
radio), but would still allow feeds from the switchers to work on the
hard timed events.

This also meant that in the event of a fire alarm the output could
keep running while staff were evacuated without having to do anything
more than select the auto mode.

While I agree there is no substitute for getting logs set up
correctly, there is also no better way of screwing up a stations
output than human intervention, or lack of it, especially in a
volunteer based organisation. :)

On 22 September 2013 04:49, Fred Gleason <[email protected]
[3]> wrote:

On Sep 21, 2013, at 13:44 17, Lorne Tyndale wrote:

> 2.  A playback mode where Stop elements are ignored.  This
would mainly
> be to cover those times when no one is at the station and for
some
> reason a stop element has been left in the log.  I realize this
would be
> more to cover for human error rather then anything else, and for
that
> very reason it might be a feature to not implement.  I see this
as a "no
> one is going to be here, so the system must keep playing audio as
long
> as there is audio in the log to play" mode.

Im far from sure that this would really be at all useful.  It most
every real world scenario that I work with, telling the log to
ignore stop transitions (*especially* when unattended) would
generate as much if not more of a train wreck than a stop
inadvertently placed in a log.  For example: think of a log with
many automated satellite breaks -- ignoring stops would be a great
way to blow through a days log in an hour or so! 

Unfortunately, there is really no easy substitute for the initial
hard work of getting log templates built and debugged.  Once thats
done however, RDLogManager makes it easy to generate logs from those
templates that will work consistently and reliably.

Cheers!



|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |               Chief Developer
              |
|                           |              
Paravel Systems               |


|-------------------------------------------------------------------------|
|          A room without books is like a body without a soul.
           |
|                                         --
Cicero                       |


|-------------------------------------------------------------------------|

_______________________________________________
Rivendell-dev mailing list
[email protected] [1]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[2]

_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Reply via email to