Feature Request: Intro/Outro Marks (the 'pisadores' bussines-logic)

[alexolivan]

Hi... Today my partners of automation dptm. have show me what they call (and they say its a common generally used therm, at least in Spain/Latin America) the 'pisadores' (Haven't found a propper translation...I would say it's just Intro/Outro mark). This feature is present on two systems they use (Hardata HDX/Dinesat and ZaraRadio/ZaraStudio)... but they claim it is very very common in many systems.

Asked about this in Rivendell, I didn't knew about nothing similar (I didn't know about that whole idea either).... I've checked documentation, and I think this feature is not present in Rivendell (I may be wrong!)

In a nutshell, the idea is to have two additional marks on a cut: Intro and Outro. The idea is that, whenever enabled to, the system will select a random cart/cut from a pre-defined selection criteria, and play it (that's why they call it 'pisador', for spanish 'pisar' - step) OVER the song at the selected mark-points.

It has several uses, but the original idea was a way to 'watermark' with a radio-ID, jingle or whatever, selected tracks, normally top hits, that would otherwise be aired unaltered, and recorded by listeners as originals... (This way the radio ID got recorded for posterity on the listener casette :-P ... I love all this very 80's 90's stuff on this world :-)

The implementations seem to differ from system to system, with more or less granularity and control... The one that I've seen (Hardata HDX) is not much fine-grained: It would be equivalent as if in Rivendell Model there would be, for a given Service, a second set of carts (just like he Autofill cart list) candidating to be selected as 'pisadores' (intros/outros). So, if the Service has the feature enabled, any cart with an Intro, Outro Mark (or both) will trigger the playout of one of the carts at the indicated mark time.

I think this feature could be achieved if such a given Intro/Outro Mark could simply trigger a playout event on a cart-slot configured in a kind of Breakaway mode, but getting carts from the 'Pisadores' selection.

Best regards.

[ElvishArtisan]

Asked about this in Rivendell, I didn't knew about nothing similar (I didn't know about that whole idea either).... I've checked documentation, and I think this feature is not present in Rivendell (I may be wrong!)

It's not present. In fact, this is the first time I've heard of the concept too.

In a nutshell, the idea is to have two additional marks on a cut: Intro and Outro. The idea is that, whenever enabled to, the system will select a random cart/cut from a pre-defined selection criteria, and play it (that's why they call it 'pisador', for spanish 'pisar' - step) OVER the song at the selected mark-points.

FWIW, Google Translate offers 'tracker' as the English translation, which sounds more like a description of the purpose of the added audio. Perhaps 'watermark' would be a more idiomatic translation? So we'd have 'intro watermarks' and 'outro watermarks'? (Just musing aloud here.)

The implementations seem to differ from system to system, with more or less granularity and control... The one that I've seen (Hardata HDX) is not much fine-grained: It would be equivalent as if in Rivendell Model there would be, for a given Service, a second set of carts (just like he Autofill cart list) candidating to be selected as 'pisadores' (intros/outros).

Would a single set of candidate carts be sufficient, or would we need separate sets for 'intro' and 'outro' watermarks?

I think this feature could be achieved if such a given Intro/Outro Mark could simply trigger a playout event on a cart-slot configured in a kind of Breakaway mode, but getting carts from the 'Pisadores' selection.

Would this actually be useful in rdcartslots(1)? I'd think that rdairplay(1) would be its natural home.

[alexolivan]

Perhaps 'watermark' would be a more idiomatic translation? So we'd have 'intro watermarks' and 'outro watermarks'? (Just musing aloud here.)

Probably... I'm not experienced in this. The 'pisar' (stepping over) concept has some 'annoying' connotation, since it somehow adds/mixes additional/unrelated audio that somehow 'ruins' what would, otherwise, be a perfect clean content airing. This is also said ('pisar' / step over) when the radio DJ talks over a song. I used the watermark word as it came to my mind from the video concept... maybe some experienced Latin America user knows the english word for this in Radio jargon

Would a single set of candidate carts be sufficient, or would we need separate sets for 'intro' and 'outro' watermarks?

I can only answer from what I've seen (again, I'm more an enthusiast, not a professional): I didn't notice for such differentiation. However, your question makes a lot of sense though!!!. My feel is that, being the original idea to simply 'whatermark' aired contents, they probably didn't care much, as they just wanted to put some short jingle/ID in place.

Would this actually be useful in rdcartslots(1)? I'd think that rdairplay(1) would be its natural home.

Actually. It is... The systems I have mentioned do perform the playout on the airing tool (RDAirplay in RIvendell) ... for some reason, I though that it would be very much prefered to keep DAirplay untouched.

[druidlabs]

Instead of intro and outro, perhaps just call them "overlays" and allow any number of them within a cut? This would allow station-stamp overlays to occur at several points during a long song or program.

Should an overlay cart have some way to set its level when the overlay is applied? Should there be a fade up and down? Should the level of the "underneath cut" be changed while the overlay cart plays?

[alexolivan]

Today I have briefly tried to dig a little bit further on this with my colleagues and I also did a little bit of research... At this moment, I can conclude that the complexity/feature-richness of the feature, greatly varies from system to system, but, in one way or another, it seems that most (if not all, I have still to dig on this feature on the french systems used here, Dalet and WinMedia... also used by some companies in Spain) widely used systems in Spain/L.A have this feature (Hardata products, Zara Studio/Radio, AEQ products, Aspa XFrame)

• Not all the systems provide 2 markers (in/Out), some use just one
• The triggering system, or the way to enable the feature varies from system to system... in some the operator must manually enable/disable the feature on the airing tool, in others the feature is just enabled service-wise and cannot be controlled, while in others it does depend on the level of automation the airing tool is set to.
• Some systems do provide, host or service wise, a way to set the level that the 'pisadores' are played at.
• Not all systems feature a pool of candidates to select to... some do force, at lower level (cart/cut), to setup which specific cart/cut is assigned as 'pisador' for a particular cart/cut, while some feature both options: pool or specific.
• This feature provides somehow the same functionality (with its limitations and differences) as the 'talk over / Voice tracking' feature in Rivendell. Not all systems feature a nice tool such as Rivendell's Voice Tracking tool to fine-grain transitions on the log, instead, they rely on this feature to enable the scheduling of a voice record track (instead of an ID, jingle, etc) to be aired over the actual track. 'top tier' systems provide both (like Rivendell may actually do :-).
• While googling in forums about the matter, the word 'SideChaining' is somehow often spelled... maybe to you, experienced radio broadcasters, the word sounds familiar

I sincerely think Rivendell should do its way... looking for a best compromise between functionality and complexity in implementation. I keep in mind that no one has ever required/used this feature before... so it is probably not required by the profile of radios using it (independently that, for many radios in Spain and L-A, it is, or was, a go/no-go feature) I'm but very shocked about finding such big coincidences and, at the same time, big differences in Radio Broadcasting 'cultures'...it is very interesting!

[kernelpanic3]

I've wondered about the feasibility of a similar function in Rivendell as well. A common thing I've heard on the radio both in the States and here in Canada is to have an "overlay" in the form of a dry tail on the end of a sweeper, which can play over the beginning of a song if it has enough time for it. Something like "On your radio, on your phone, and on your smart speaker -" (song starts) "- the Heartland's variety is on Valley 96.5." If I'm understanding correctly, this sounds broadly equivalent to the "pisadores" Alex is talking about, and it'd be great to see such a feature added if it isn't already possible.

[CWJR]

I favor Mike's suggestion of calling it "Overlay" or something other than "Intro/Outro". That last term already has a definite meaning in both audio and video in America, and it is not the same as this 'drop-in' kind of option.

By the way, my understanding of "pisadores" is "trampler"--as in the people who stomp grapes for making wine.

One amazing feature of Rivendell is the ability to treat the entire day's log as a voice-track and anywhere in the day, manually manipulate transitions, and even position events like drop-ins to overlay on top of the intro or extro of songs. We did that for a 3-day weekend special that was entirely voice-tracked last year during the height of the Covid lockdown. Most listeners thought we were live and were calling in requests, but it was 3 days of carefully-manipulated voice-tracking.

[ElvishArtisan]

I like this idea. As I'm seeing it right now, the feature would be called 'Overlays' Any cuts could have zero or more 'overlay markers' placed. When played in a log, each overlay marker would trigger playout of a cart, randomly selected from a pool of carts on the basis of Service. Dayparting logic in such carts would be fully supported, allowing the content of the overlays to be tailored to the current daypart. Overlays would work only in a Log context --i.e. in RDAirPlay logs.

How about audio channel assignments? Should overlays play on the same output as the parent cut? Would there be merit to the ability to use a dedicated output from them (so to enable things like generating 'clean' and 'branded feeds simultaneously by means of appropriate downstream mixing)?

What else am I missing?

[alexolivan]

Hi all!

Something like "On your radio, on your phone, and on your smart speaker -" (song starts) "- the Heartland's variety is on Valley 96.5." If I'm understanding correctly, this sounds broadly equivalent to the "pisadores"

My initial though was that, to do that, the 'voice tracker' tool would be the ideal tool, since, for that particular case, you're not just overlying one track, but two (the song starts amidst the overlying track. However, since I've never used the voice tracker, not being sure, I checked it out, and, at first glance, it looks as it is unable to even do what you want either (it appears to be designed to just allow you to insert an 'in-situ' recorded voicetrack cart) Maybe I'm wrong... but your question makes me think that maybe Rivendell has absolutely no way to do nothing similar to this at this moment.

In a nutshell: Systems with full-blown transitions editor (Win-Media for instance) could do what you want. Systems I know that use just the 'pisadores' (Zara, Hardata...) you could just achieve half of your purpose, since the Intro/Outro marks are defined WITHIN the cut boundaries, so it can not start before the track itself. However, with hardata, you could automate something very very close, since it features both Intro and outro marks

By the way, my understanding of "pisadores" is "trampler"--as in the people who stomp grapes for making wine.

Yes! :-D ... that's the literal translation!!! (but I got step in my mind :-) the word 'pisador' has indeed, in this context, that kind of 'negative' meaning, because it ruined FM recordings :-P (It was, and is, currently applied in spanish radio jargon as the radio dj talks over a song: they say he is 'trampling' the song 'pisando la cacnción') ... however, I agree (and that's just an opinion from a non-english speaker) that a word such as Overlay, or something like that, more ellegant/professional, is what it should be for Rivendell

manually manipulate transitions

That's the key here I think, Manually vs Automatically. The ability to let the system to automatically choose an overlay, from a random pool, or a certain cart, at the right place, of certain songs can be very handy and time saving... By using pisadores, having a reasonably good 'fake' live is something trivial in Hardata products (what my partners mostly install here) for ages. Also, all systems that I know or I have asked about this matter, allows you to, someway or another, schedule the playout of an 'overly' cart (not necessarily a voice track recorded cart, but anything in the library) over a song... something that I start to feel Rivendell was not required to do when it was conceived (sure, you can do that, more or less manually, using auxiliary logs, rdcatch playout, etc...but nothing truly automatic and integrated in the automation bussiness-logic)

[alexolivan]

How about audio channel assignments? Should overlays play on the same output as the parent cut? Would there be merit to the ability to use a dedicated output from them (so to enable things like generating 'clean' and 'branded feeds simultaneously by means of appropriate downstream mixing)?

What else am I missing?

At that point, I fear I can not help very much myself... since not all systems do everything and some seem to have some feature or lack another. Probably, most thoughs have sense, but the problem is the thing goes more and more complicated to implement.

EDIT: Maybe it would be helpful to be able to select, in event settings, whether or not to choose or discard 'Overlayed' cuts (since, unlike the systems I know about, Rivendell has the superior feature of multiple cuts per cart, where eventually, not all cuts could have overlay marks)... I have not in my mind a clear picture about the implications of multi-cut model together with overlay marks feature model, I'm wondering whether unwanted overlays or missed overlays could happen (sure, duplicating carts, with and without overlay marks could be the solution...but, is it elegant?)

[ElvishArtisan]

Yes! :-D ... that's the literal translation!!! (but I got step in my mind :-) the word 'pisador' has indeed, in this context, that kind of 'negative' meaning, because it ruined FM recordings :-P (It was, and is, currently applied in spanish radio jargon as the radio dj talks over a song: they say he is 'trampling' the song 'pisando la cacnción') ... however, I agree (and that's just an opinion from a non-english speaker) that a word such as Overlay, or something like that, more ellegant/professional, is what it should be for Rivendell

Agreed. Rivendell always tries to take a mechanism, not policy approach to features. Policy is the domain of Program Directors.

[druidlabs]

Putting the overlay on a separate channel likely means it's exposed on a control surface. The DJ can modify the audio level, which allows the possibility of accidentally/purposefully disabling the overlay by fading down the channel. This is probably not an issue in real life.

Should macro carts be allowed? Doing so would essentially get you an RDCatch event tied to the elapsed time in a cart rather than the elapsed time in a day. This is getting pretty far away from the original idea, and I can't really think of a use case (other than "It Would Be Cool").

[ElvishArtisan]

Putting the overlay on a separate channel likely means it's exposed on a control surface. The DJ can modify the audio level, which allows the possibility of accidentally/purposefully disabling the overlay by fading down the channel. This is probably not an issue in real life.

If it's a concern, then Don't Do It --i.e. set the channel assignment to the same port as the log.

Where this becomes slightly less straightforward is when you've got a setup where the output is toggling between two different ports, with the operator doing manual crossfades; in which case 'overlays follow log audio' would be the appropriate option. (Or, I'm just overthinking this whole issue way too much -- perhaps we should just hardwire the 'follow' option and call it done).

Should macro carts be allowed? Doing so would essentially get you an RDCatch event tied to the elapsed time in a cart rather than the elapsed time in a day. This is getting pretty far away from the original idea, and I can't really think of a use case (other than "It Would Be Cool").

I don't see any obvious reason why we couldn't/shouldn't allow macros. That would let you do things like play overlays from the SoundPanel. The extra layer of indirection could be useful.

[alexolivan]

Putting the overlay on a separate channel likely means it's exposed on a control surface. The DJ can modify the audio level, which allows the possibility of accidentally/purposefully disabling the overlay by fading down the channel. This is probably not an issue in real life.

If it's a concern, then Don't Do It --i.e. set the channel assignment to the same port as the log.

Brilliant! ... so, if I'm thinking it correct, translates to a new form field in RDadmin/hosts/RDAirplay where a new output (overlay) will have to be setup to a given output (so you can just send to same as logmachine, or a dedicated output to have it on the mixing table). I'm concerned but that the possibility of external-mixer overlay level control will drop the idea of having a form field there where we could select the duck/level of the overlay (which is the usual way to control the level when overlay exists on same output than logmachine)

Another thing that I have not clear in my mind is how to control when and if overlays should be played for the two models/use-cases I have in my mind:

1 Regarding the log generation bussiness-model/use-case (RDLogmanager) The underlying problem I see is that, unless you start duplicating material (with and without overlay mark(s)), you have to be able, to some degree of granularity, when to honor the mark and trigger the overlay playout. Otherwise, you may end with lots and lots of overlays every single time a cut has overlay marks. Also, what happens if a cart has two cuts, one with and another without marks? how could I convince RDLogmanager that I allow overlays on events, lets say, ToH and HoH? (sure, I can control, by using a scheduler code 'hasoverlay' whether or not I want an event with overlay marks on the cut)

2 Regarding the log execution bussiness-model/use-case (RDAirplay) The question is how to let the operator to toggle on/off overlays, or how to condition them to the operation mode (much like segueing). For instance, for automatic overlays on, for Manual overlays OFF, for live-assist you have to toggle them ON/OFF

Finally, I would consider, to match kernelpanic3's request (very much possible in systems with a powerfull transitions/segue editor, such as Rivendell's Voice Tracking tool):

Something like "On your radio, on your phone, and on your smart speaker -" (song starts) "- the Heartland's variety is on Valley 96.5."

To allow (maybe it is possible, I think it is not!) a cart to optionally be loaded, instead of a voice recording from the mic, and used there as an overlay over the transition or segue between two songs.

[ElvishArtisan]

Brilliant! ... so, if I'm thinking it correct, translates to a new form field in RDadmin/hosts/RDAirplay where a new output (overlay) will have to be setup to a given output (so you can just send to same as logmachine, or a dedicated output to have it on the mixing table). I'm concerned but that the possibility of external-mixer overlay level control will drop the idea of having a form field there where we could select the duck/level of the overlay (which is the usual way to control the level when overlay exists on same output than logmachine)

A 'duck level' setting would be pretty simple. Probably per Service.

Another thing that I have not clear in my mind is how to control when and if overlays should be played for the two models/use-cases I have in my mind:

1 Regarding the log generation bussiness-model/use-case (RDLogmanager) The underlying problem I see is that, unless you start duplicating material (with and without overlay mark(s)), you have to be able, to some degree of granularity, when to honor the mark and trigger the overlay playout. Otherwise, you may end with lots and lots of overlays every single time a cut has overlay marks. Also, what happens if a cart has two cuts, one with and another without marks? how could I convince RDLogmanager that I allow overlays on events, lets say, ToH and HoH? (sure, I can control, by using a scheduler code 'hasoverlay' whether or not I want an event with overlay marks on the cut)

2 Regarding the log execution bussiness-model/use-case (RDAirplay) The question is how to let the operator to toggle on/off overlays, or how to condition them to the operation mode (much like segueing). For instance, for automatic overlays on, for Manual overlays OFF, for live-assist you have to toggle them ON/OFF

Taking case 2) first: there are basically three different 'levels' at which control could be exerted:

1. Per log. A single 'big switch' that makes all overlays work in that log, or not.
2. Per log event. A event attribute (similar to transition type or hard start time).
3. Automatic. Overlays would be active on the basis of some higher policy (as you suggest in 2) above).

The combination of 1. and 2. could be effective. A 'big switch', which if active then causes the per-event attribute to be honored. Once we have this as a foundation, then your point 1) above becomes mostly a matter of having rdlogmanager(1) set the appropriate attributes during log generation. For 3., I'm thinking something like an RML hook that would fire every time the mode is changed in rdairplay(1). This would allow implementation of local site policy --e.g. "always disable overlays when in Live Assist mode"-- rather than guessing the optimal combinations to hardwire and then getting it wrong.

[alexolivan]

Hi! Today I've further inquired my partners of automation about the intro marks, and I have further understood how they work... It turns out I had oversimplified the thing, as I'm not experienced on those matters.

Here's the thing, and why there's either one or two marks, not more: The Intro Mark is set on the point of the cut where the Overlay MUST END (not start!!!) The reason for this is that you don't want the singer and the overlay (very often voice) to overlap.

The playing engine checks for candidate overlays that fit in the resulting gap, from the start of the cart to the intro mark, and starts to play the overlay at the precise moment so it ends right over the mark. If the gap is too short for existing overlays, no overlay is played.

Also, the ducking controls of the overlay, turns to be more complex than I initially though: what it does is to duck the log machine with a short fading, in a way that, overlay and song do play nicely together. When the playout reaches the intro mark (overlay ends) then, the logmachine level is faded up to normal level

I immediately realized that, in a nutshell, what all those systems are doing is a kind of automated version of the voice tracker (but using an arbitrary cart)...The use case being very very similar, to the point that the difference blur in my mind. As I asked about the difference, they've explained me that high-end systems do feature too a kind of voice track tool too, but having a simplified automatic version of it, to play general stuff (such as Ids, etc, etc) is very very handy and saves a ton of work.

What I'm wondering is whether the talk start/end marks could be then used to this same purpose! so part of the work being already done.

[ElvishArtisan]

Here's the thing, and why there's either one or two marks, not more: The Intro Mark is set on the point of the cut where the Overlay MUST END (not start!!!) The reason for this is that you don't want the singer and the overlay (very often voice) to overlap.

The playing engine checks for candidate overlays that fit in the resulting gap, from the start of the cart to the intro mark, and starts to play the overlay at the precise moment so it ends right over the mark. If the gap is too short for existing overlays, no overlay is played.

So, we add an attribute to the Overlay Marker: 'Start at Mark Position' or 'End at Mark Position'. Still no reason to limit the absolute number of Overlay Markers placeable on a Cut.

Also, the ducking controls of the overlay, turns to be more complex than I initially though: what it does is to duck the log machine with a short fading, in a way that, overlay and song do play nicely together, when the playout reaches the intro mark (overlay ends) then, the logmachine level is faded up to normal level

That has been my understanding of how ducking would work all along.

What I'm wondering is whether the talk start/end marks could be then used to this same purpose! so part of the work being already done.

That idea immediately came to my mind as well as I was reading this -- in many cases, you'd want a TalkEnd and an OverlayEnd marker at the same point. I don't think we'd want to hardwire that though -- instead, I'm thinking something like an option in rdmarkerset(8) to generate such OverlayEnd markers automatically in accordance with local site policy.

[alexolivan]

It's so fun to read and realize you (and probably others here) understood the whole implications and potential of the thing deeper than myself from the very beginning... experienced broadcasters here! :-)

From your comments, I feel the implementation on your mind will, from 0 to hero, out-feature many, if not all, aspects of all other win-based systems I know about... astounding...

Best regards.