Improvements to overlays for Remote VoiceTracking
Improvements to overlays for Remote VoiceTracking
We are using overlays for our ad-breaks in ProppFrexx, but we are currently having some minor issues when using those with Remote VoiceTracking.
* We use the "Suppress Filter" on overlays to make sure no Jingles/Sweeps are played before the start of an ad-break. When a playlist is retrieved using Remote VoiceTracking the Overlays are resolved to the playlist as Embedded Containers, which are played by the playlist players and not the overlay player. This causes the suppress filters not to apply.
* We want to allow our live DJ's to prepare their playlists at home, but this is not possible right now. Since overlays are resolved to the playlist as Embedded Containers these playlists will work differently in a live session. Our radio DJ's are trained to use the Overlay Players for adverts as we need strict timing on those.
Would it be possible to add an option to resolve Overlays to a new type of playlist entry. Something like a placeholder so the VoiceTracker knows where the ad block is, but the overlay is still played out using the overlay player. This placeholder would suppress the normal overlay, as they can be dragged around in the playlist which can cause timing to be different from the scheduled time, but playback will happen by the overlay player.
Or perhaps a different approach would be an option to allow all "OVERLAY:" embedded containers to be removed from the playlist when it is loaded and all overlays to be rescheduled to the appropriate timing>
I don't know what is possible here and if it would be too complex to implement. If you have a similar workflow that exists with the current version of ProppFrexx that solves these issues, please let me know![🙂](//cdn.jsdelivr.net/gh/twitter/twemoji@latest/assets/svg/1f642.svg)
Thank you in advance!
* We use the "Suppress Filter" on overlays to make sure no Jingles/Sweeps are played before the start of an ad-break. When a playlist is retrieved using Remote VoiceTracking the Overlays are resolved to the playlist as Embedded Containers, which are played by the playlist players and not the overlay player. This causes the suppress filters not to apply.
* We want to allow our live DJ's to prepare their playlists at home, but this is not possible right now. Since overlays are resolved to the playlist as Embedded Containers these playlists will work differently in a live session. Our radio DJ's are trained to use the Overlay Players for adverts as we need strict timing on those.
Would it be possible to add an option to resolve Overlays to a new type of playlist entry. Something like a placeholder so the VoiceTracker knows where the ad block is, but the overlay is still played out using the overlay player. This placeholder would suppress the normal overlay, as they can be dragged around in the playlist which can cause timing to be different from the scheduled time, but playback will happen by the overlay player.
Or perhaps a different approach would be an option to allow all "OVERLAY:" embedded containers to be removed from the playlist when it is loaded and all overlays to be rescheduled to the appropriate timing>
I don't know what is possible here and if it would be too complex to implement. If you have a similar workflow that exists with the current version of ProppFrexx that solves these issues, please let me know
Thank you in advance!
Re: Improvements to overlays for Remote VoiceTracking
Well, first you do not have to resolve Overlays to the playlist during remote voice tracking, i.e. this is an option. If disable, the Overlays are played out via the Overlay Scheduler.
However, once they are resolved, they are of course played as embedded containers as regular playlist items. And yes, in that case, they are of course not exactly played as if the Overlay Player plays them (this also includes the exact time).
And if you for example resolve all overlays to the remote playlist and the even remove all those embedded overlay containers, those overlays would again be played by the Overlay Scheduler/Player.
As such, you are in full control, if you want to resolve them or not.
Is that the option you are looking for (i.e. not resolving overlays to the playlist)?
However, once they are resolved, they are of course played as embedded containers as regular playlist items. And yes, in that case, they are of course not exactly played as if the Overlay Player plays them (this also includes the exact time).
And if you for example resolve all overlays to the remote playlist and the even remove all those embedded overlay containers, those overlays would again be played by the Overlay Scheduler/Player.
As such, you are in full control, if you want to resolve them or not.
Is that the option you are looking for (i.e. not resolving overlays to the playlist)?
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Improvements to overlays for Remote VoiceTracking
Hi Bernd,
We have been doing some brainstorming here on how we could improve this without requiring changes to the software.
We came to an agreement to switch from overlays in the overlay player to overlays as embedded containers in the playlist. This way there are no differences between Live and VoiceTrack and the above issues are mostly solved.
I started a test instance to test this out, and I changed all of our overlays to "AsPlaylistInsert". This way they always appear in the playlist at the specified time. There is however one issues I found while testing: there are 2 different types of overlays:
![Image](https://i.imgur.com/byGgt9s_d.webp?maxwidth=1520&fidelity=grand)
For Remote Voicetracking is also a bug when checking "Resolve Overlays" in the "More RVT Options"-menu. When the overlays are resolved the Suppress Filters are not applied to the generated playlist.
We have been doing some brainstorming here on how we could improve this without requiring changes to the software.
We came to an agreement to switch from overlays in the overlay player to overlays as embedded containers in the playlist. This way there are no differences between Live and VoiceTrack and the above issues are mostly solved.
I started a test instance to test this out, and I changed all of our overlays to "AsPlaylistInsert". This way they always appear in the playlist at the specified time. There is however one issues I found while testing: there are 2 different types of overlays:
![Image](https://i.imgur.com/byGgt9s_d.webp?maxwidth=1520&fidelity=grand)
- The first one is called an "Embedded Overlay Container. It is resolved by the scheduler when "AsPlaylistInsert" is enabled. For some reason the "Apply Suppress Filter" is ignored here.
- The second one is called an "Embedded Container". It is resolved by clicking on "Resolve Overlay To Playlist" in the "Upcoming Overlays" menu. The "Apply Suppress Filter" works as requested.
For Remote Voicetracking is also a bug when checking "Resolve Overlays" in the "More RVT Options"-menu. When the overlays are resolved the Suppress Filters are not applied to the generated playlist.
Re: Improvements to overlays for Remote VoiceTracking
I’ll take a look… !
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Improvements to overlays for Remote VoiceTracking
Thank you!
I have been doing some more experimenting in the mean time.
There are more issues that occur with the "AsPlaylistInsert" option that are not present when clicking on "Resolve Overlay To Playlist" in the "Upcoming Overlays" menu.
When using a program with "Soft TimeUpdateSync" an overlay scheduled at xx:00 (with "AsPlaylistInsert" checked) is inserted before the actual TimeUpdateSync. This causes the embedded overlay to be skipped at the hour switch.
When instead manually clicking the "Resolve Overlay To Playlist" the embedded container is placed right after the TimeUpdateSync, as it should, and is not skipped after the TimeUpdateSync occurs.
I have been doing some more experimenting in the mean time.
There are more issues that occur with the "AsPlaylistInsert" option that are not present when clicking on "Resolve Overlay To Playlist" in the "Upcoming Overlays" menu.
When using a program with "Soft TimeUpdateSync" an overlay scheduled at xx:00 (with "AsPlaylistInsert" checked) is inserted before the actual TimeUpdateSync. This causes the embedded overlay to be skipped at the hour switch.
When instead manually clicking the "Resolve Overlay To Playlist" the embedded container is placed right after the TimeUpdateSync, as it should, and is not skipped after the TimeUpdateSync occurs.
Re: Improvements to overlays for Remote VoiceTracking
The functions are not identical…! So they are not fully intended to be 100% the same ![Wink ;-)](./images/smilies/icon_e_wink.gif)
However, I just looked to the code, but the ApplySuppressFilter option should actually work in both cases - at least here in the code it is applied.
So I need more test cases, as I currently can not reproduce it. I.e. in both cases, the SuppressFilter tracks should be 'Marked As Played'.
Can you describe your test scenario/use case? What tracks should be suppressed, but are not? Is it a scheduled playlist you are testing with or a manually created one? Are the tracks to be suppressed already present in the playlist when the overlay is shown and the AsPlaylistInsert option is evaluated or are the tracks to be suppressed maybe added later, i.e. what s your Show In Advance time for the overlay and how many tracks to you schedule in advance?
![Wink ;-)](./images/smilies/icon_e_wink.gif)
However, I just looked to the code, but the ApplySuppressFilter option should actually work in both cases - at least here in the code it is applied.
So I need more test cases, as I currently can not reproduce it. I.e. in both cases, the SuppressFilter tracks should be 'Marked As Played'.
Can you describe your test scenario/use case? What tracks should be suppressed, but are not? Is it a scheduled playlist you are testing with or a manually created one? Are the tracks to be suppressed already present in the playlist when the overlay is shown and the AsPlaylistInsert option is evaluated or are the tracks to be suppressed maybe added later, i.e. what s your Show In Advance time for the overlay and how many tracks to you schedule in advance?
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Improvements to overlays for Remote VoiceTracking
Good news is, that I was able to reproduce your issues.
Bad news is, that I didn’t find the reason yet or can explain it… ie. I need to fix the issue(s).
Might take some time, as they seems to be quite strange and odd… so pls standby!
Bad news is, that I didn’t find the reason yet or can explain it… ie. I need to fix the issue(s).
Might take some time, as they seems to be quite strange and odd… so pls standby!
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Improvements to overlays for Remote VoiceTracking
Hi Bernd that is great! Thank you!
To answer some of your questions, if it would be helpful.
* clicking on "Resolve Overlay to Playlist" in the "Upcoming Overlays" menu
Resolved incorrectly with no suppression when:
* fetching a playlist over RVT (with the "Resolve Overlays" checkmark enabled in the settings)
* marking "AsPlaylistInsert" and waiting for the overlay to be inserted in the playlist at runtime
We are using playlists that are generated using a scheduling software and the script for the each hour resolves those playlists.
To answer some of your questions, if it would be helpful.
Resolved correctly with suppression when:What tracks should be suppressed, but are not?
* clicking on "Resolve Overlay to Playlist" in the "Upcoming Overlays" menu
Resolved incorrectly with no suppression when:
* fetching a playlist over RVT (with the "Resolve Overlays" checkmark enabled in the settings)
* marking "AsPlaylistInsert" and waiting for the overlay to be inserted in the playlist at runtime
The playlists are scheduled using the program scheduler.Is it a scheduled playlist you are testing with or a manually created one?
We are using playlists that are generated using a scheduling software and the script for the each hour resolves those playlists.
Since we are loading a playlist using a script with only one script line, the entire playlist is resolved at the start of the program. So yes all tracks are already present in the playlist.Are the tracks to be suppressed already present in the playlist when the overlay is shown and the AsPlaylistInsert option is evaluated
Re: Improvements to overlays for Remote VoiceTracking
A new v4.3.6.0 is available, which should (hopefully) fix all your issues you mentioned!
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Improvements to overlays for Remote VoiceTracking
Hi Bernd
Thank you for taking the time to apply these fixes!
I have been testing the new version and the suppression issues seem to be fixed when using "AsPlaylistInsert".
There are however some bugs remaining, unfortunatly:
Suppression with Remote VoiceTracking and "Resolve Overlays"
"ApplySuppressFilters" is still ignored in some scenarios when resolving overlays to the playlist during Remove VoiceTracking.
Sweeps/jingles are not suppressed before the overlay. I was not able to find any sweeps/jingles after the overlay, so perhaps it is only a problem with suppression of items before the overlay.
Steps to reproduce:
1. Create a script that has a single script-line that loads some playlist
2. Schedule this script every hour using the progran scheduler.
3. Go to Settings > Script/Scheduler > Suppress Filters and check all items except for "Music"
5. Create an overlay with the options "ApplySuppressFilter"
6. Fetch a program using Remote VoiceTracking.
AsPlaylistInsert timing bug
The differences between "AsPlaylistInsert" and "Resolve Overlay To Playlist" is still present, which is a bug. Let me explain this in more detail on how to reproduce this:
1. Create a script that has a single script-line that loads some playlist
2. Schedule this script every hour using the program scheduler. Select the "Soft TimeUpdateSync" as the Start Type.
3. Create an overlay at the start of the hour using the overlay scheduler. Check the "AsPlaylistInsert" option and specify "Show 60 seconds" in advance.
At 12:59 the overlay will be inserted into the playlist, but it will be placed underneath the current active track, and not on top of the playlist of the next program. At 13:00 the TimeUpdateSync will be triggered, which will eject the overlay together with the remaining tracks of the old hour, causing the overlay to be unplayed.
When using the "Upcoming Overlays > Resolve Overlay To Playlist" action, the overlay is placed after the TimeUpdateSync, which is the correct location.
Inconsistent Embedded Container naming bug
There is still a difference on how overlays are named:
---
Maybe the behaviour and container naming code of "Upcoming Overlays > Resolve Overlay To Playlist" can be applied to the "AsPlaylistInsert" option?This would fix the last 2 bugs.
Thank you for looking into this, we greatly appreciate your time and effort!
Thank you for taking the time to apply these fixes!
I have been testing the new version and the suppression issues seem to be fixed when using "AsPlaylistInsert".
There are however some bugs remaining, unfortunatly:
Suppression with Remote VoiceTracking and "Resolve Overlays"
"ApplySuppressFilters" is still ignored in some scenarios when resolving overlays to the playlist during Remove VoiceTracking.
Sweeps/jingles are not suppressed before the overlay. I was not able to find any sweeps/jingles after the overlay, so perhaps it is only a problem with suppression of items before the overlay.
Steps to reproduce:
1. Create a script that has a single script-line that loads some playlist
2. Schedule this script every hour using the progran scheduler.
3. Go to Settings > Script/Scheduler > Suppress Filters and check all items except for "Music"
5. Create an overlay with the options "ApplySuppressFilter"
6. Fetch a program using Remote VoiceTracking.
AsPlaylistInsert timing bug
The differences between "AsPlaylistInsert" and "Resolve Overlay To Playlist" is still present, which is a bug. Let me explain this in more detail on how to reproduce this:
1. Create a script that has a single script-line that loads some playlist
2. Schedule this script every hour using the program scheduler. Select the "Soft TimeUpdateSync" as the Start Type.
3. Create an overlay at the start of the hour using the overlay scheduler. Check the "AsPlaylistInsert" option and specify "Show 60 seconds" in advance.
At 12:59 the overlay will be inserted into the playlist, but it will be placed underneath the current active track, and not on top of the playlist of the next program. At 13:00 the TimeUpdateSync will be triggered, which will eject the overlay together with the remaining tracks of the old hour, causing the overlay to be unplayed.
When using the "Upcoming Overlays > Resolve Overlay To Playlist" action, the overlay is placed after the TimeUpdateSync, which is the correct location.
Inconsistent Embedded Container naming bug
There is still a difference on how overlays are named:
- When fetching the playlist using RemoteVoiceTracking or when using "Upcoming Overlays > Resolve Overlay To Playlist", the following naming will be used:
This is great, as it shows that an overlay will be played and the name is on top (which is also the case with other special items in the playlist)
- When using "AsPlaylistInsert", the following naming will be used:
The naming is confusing here. Overlay: <name> should be used as "Artist", not the amount of entries. The amount of entries is also not that relevant, but could be displayed as title, underneath the actual overlay title.
---
Maybe the behaviour and container naming code of "Upcoming Overlays > Resolve Overlay To Playlist" can be applied to the "AsPlaylistInsert" option?This would fix the last 2 bugs.
Thank you for looking into this, we greatly appreciate your time and effort!