Individual & Block TS to last events segue/transition point (irrespective of block target marker having a stop/segue transition)

[AaronJowitt]

As discussed;

• we need individual TS to scale to "Enforce Length' duration based on Transition point (rather than current end of cut behaviour)
• we need the last event of a block to transition at its segue start point, not end of cart (i.e the segue start point of the last cart occurs at the exact time as the target time marker 'Start At' time). In doing so need to retain the flexibility of the target timing marker having a stop transition (i.e if won't fire the post time marker event until its "Start At' time) . This is possible in other automation systems such as RCS, because transitions into the next event are set on the currently playing cart. In RD, they are instead set on the next cart.

I think you were suggesting (below) a 'global behaviour' based on a RDADmin preference for segue/play default transition behaviour. I'm ok with that, and suggest it needs to encompass a few things;

• RDAirplay > Pie Counts to... [END/TRANSITION]
• RDAirplay >Play Stack, cut remaining value and event progress bar [END/TRANSITION]
• ENFORCE LENGTH/INDIVIDUAL TS MODE - calculates play to transition point of [END/TRANSITION]
• Block TS - last event calculates play to transition point of [END/TRANSITION]
• Global (AirPLay, Library, LogEDit etc) - all LENGTH GUI values throughout RD [END/TRANSITION]. See email of 15Sep 10:26am for screen shots.

AJ

On 16/09/15 17:59, John Anderson wrote:

Agree with the transition..(forward moving concept),

question..if the segue marker isn't there...such as the new talk format, or segments of a day that may be primarily talk /imported form RDCatch, and stuff with no segue markers...is this automatic that this would then become the transition point?

That would makes sense. No segue start marker, so it plays to end of cart - with timers, progress pie's/bars reflecting that.

By the way, RDCatch and RDAdmin DROPBOXES ideally*should both support auto placing a segue marker. I know we will have to undertake much of our our 'dropbox' style importing with multiple RDImport instances running instead, solely to allow auto segue marker placing.

so I favor the option to select!

are there any formats or stations that DO rely heavily on total end of cart (abet transitions) ...(Classical?, reading services, etc, that may well WANT to work on the absolute end, and then some)... them pauses might be important...

so I favor the option to select!

Would those carts not have segue start markers set, so would play till end of cart anyway. And even if they did have segue markers, setting the log event transition types to PLAY would ignore any segue markers, and play till end of cart anyway. Would that meet their needs? I think that's Fred's thinking. Trying to think of when it may not, or is a messy workaround etc.

On Tue, Sep 15, 2015 at 7:34 PM, Scott Spillers scotts@paravelsystems.com wrote:

Even when 'No Fade on Segue' is selected, the next transition is no longer keyed to the original cart, but rather to the next one (usually a voice-over) that started at the Segue transition.  I would recommend always following the transition code.  I can't think of a situation where you wouldn't want the timer to count down to the proper transition time.

Scott Spillers
scotts@paravelsystems.com

On Mon, Sep 14, 2015 at 8:11 AM, John Anderson <johna@paravelsystems.com> wrote:

    The more I think about this, the more it’s making sense to just make all of this automatic on the basis of whether the transition in question is SEGUE or PLAY.  This would make a whole slew of configuration settings (present and contemplated) go away.  Can anyone think of situation where one would want an “opposite” behavior —e.g. an event with a PLAY transition that counts down to the SEGUE point?

    Overall, I can't think of anything either..as long as the no fade on seque switch works as normal.. (I have instances where folks puts a dry forecast over a Weather bed/with closing jingle)... 

    Other than that, the transition switch is RDAirplay should work just fine...

    On Mon, Sep 14, 2015 at 10:45 AM, Frederick Gleason <fredg@paravelsystems.com> wrote:

        > On Sep 12, 2015, at 22:39 02, Aaron Jowitt <Aaron.Jowitt@rebelfm.com.au> wrote:
        >
        > So if easier to code for, you could consider encompassing all above under one host based RDAdmin switch, and you could always split later to separate 4 toggles if the need arose.  This works for us, and I suspect would work for most people.   If just as easy for you either way, then yes, providing a separate switche for above 4 options gives most flexibility.

        The more I think about this, the more it’s making sense to just make all of this automatic on the basis of whether the transition in question is SEGUE or PLAY.  This would make a whole slew of configuration settings (present and contemplated) go away.  Can anyone think of situation where one would want an “opposite” behavior —e.g. an event with a PLAY transition that counts down to the SEGUE point?

        Cheers!

        |----------------------------------------------------------------------|
        | Frederick F. Gleason, Jr. |              Chief Developer             |
        |                           |              Paravel Systems             |
        |----------------------------------------------------------------------|
        |          A room without books is like a body without a soul.         |
        |                                         -- Cicero                    |
        |----------------------------------------------------------------------|

[ElvishArtisan]

| we need individual TS to scale to "Enforce Length' duration based on Transition point (rather than | current end of cut behaviour)

Done in git master.

[ElvishArtisan]

| RDAirplay >Play Stack, cut remaining value and event progress bar [END/TRANSITION]

Done in git master.

[AaronJowitt]

thanks Fred. Does new behaviour encompass the other areas (listed above);

-Block TS - last event calculates play to transition point of [END/TRANSITION] -Global (AirPLay, Library, LogEdit etc) - all LENGTH GUI values throughout RD [END/TRANSITION]. See email of 15Sep 10:26am for screen shots.

Cheers

[ElvishArtisan]

| -Block TS - last event calculates play to transition point of [END/TRANSITION]

I misspoke above -- it is the block TS that has been changed, NOT the individual. In fact, by its very nature, it really makes no sense to have individually timescaled events calculated to the segue point. The whole point of such timescaling is to make the event conform to a specified length (in contexts with fixed availability windows, such as satellite spot breaks). One would never use SEGUE in such situations anyway. Additionally, allowing such for individual timescaling would create mare's nests such as: how do we determine what the "legal" length range for cuts in RDLibrary? It would vary depending on the scheduling context!

[ElvishArtisan]

| -Global (AirPLay, Library, LogEdit etc) - all LENGTH GUI values throughout RD [END/TRANSITION]. | See email of 15Sep 10:26am for screen shots.

Here's the way it works now: the "Pie Counts To" control in RDAdmin->ManageHosts->RDAirPlay has been changed to "Calculate Transitions". It has three settings: "End" (calculate everything relative to the End marker of a cut), Segue/End (calculate everything to the SegueStart marker of a cut if it exists, otherwise End) and "Automatic" (calculate to SegueStart or End as determined by the transition type specified in the following log event). The context of all of this is RDAirPlay (as implied by its location in RDAdmin). I'm thinking that, for other modules, as separate, system-wide setting would be appropriate (if for no other reason than the 'Automatic' setting makes no sense in contexts outside of a log).

[AaronJowitt]

| I misspoke above -- it is the block TS that has been changed, NOT the individual.

We have a different take on this. In this region it is common for segue transitions to be used in commercial breaks. Sure, sometimes its hard to tell (with clean ending commercials), but other times with a tailing off music bed (particularly if next commercial is cold voice etc) it makes the transition just slightly flow better. When we produce commercials aiming for 30s (+/- 0.5s) its the fade point of the commercial (at ~ -15) that we're aiming for. And our current automation system does not 'auto place' cut-end markers, so its likely a number of our commercials have a second or so of silence at the end (depending on where they were produced).

| ...in contexts with fixed availability windows, such as satellite spot breaks). One would never use SEGUE in such situations anyway.

Why not? If the last event in the break has a musical fade ending (with say the segue start marker at -15 to -20, if that's the exact point the satellite feed returns (with both sources on air at once), this sounds great. It's the way most stations do it here. Very few stations ensure there is nothing playing locally when satellite returns. It makes satellite networking as 'smooth flowing' as if it was instead all local programming with all log events (Pre & post break) set to segue transition.

| allowing such for individual timescaling would create mare's nests such as: how do we determine what the "legal" length range for cuts in RDLibrary? It would vary depending on the scheduling context!

Yes, I can see that difficulty if 'Calculate Transitions' is set to 'automatic'. One idea: a new "Validate Length" control for GROUPS that offers just two settings; 'segue' or end'. RdLibrary then checks the Group setting for that control, applies the Groups TS limits, with respect to the segue or end point of the track, and then gives the appropriate warning if outside the range. This would imply the scheduling context used for all carts in a given group would always have to reflects the group setting to fully ensure all carts will 'fit'. Not ideal, but this should certainly work flawlessly for us. i.e. The COM groups can be set to validate lengths based on its segue point, and when logs are merged we import all traffic events with a segue transition.

[AaronJowitt]

| The context of all of this is RDAirPlay (as implied by its location in RDAdmin). I'm thinking that, for other modules, as separate, system-wide setting would be appropriate (if for no other reason than the 'Automatic' setting makes no sense in contexts outside of a log).

That's really neat Fred, great implementation. Though presumably 'Automatic" ideally should also influence RDLogEdit's content/ run time counters, wouldn't it?

Broadly agree a separate system wide setting for non-log modules such as RDLibrary etc (with just segue or end option) is best.

A possible alternative is to just have the one "Calculate Transitions" control, but move it to a 'system wide' area and give it 4 settings, something like;

END END (Auto AirPlay) SEGUE/END SEGUE END (Auto AirPlay)

Though think your idea is best and clearest for new users.