RadioBOSS 7.2 [beta]

[Guillaume]

I checked the box, but the clock is still in 12-hour format. It would be helpful to be able to change the date format.

I can confirm the problem (the afternoon has just begun as I write this).
Furthermore, when the time is adjusted in the display settings (view), the change is not applied. However, it is correctly applied in the window next to "On Air".

 

[IvanVK]

Hello,
I checked the box, but the clock is still in 12-hour format. It would be helpful to be able to change the date format.

Regards

True, same thing here.

 

[xzsaimon16]

They can add the option “mark as next” on double-click. (Only mark as next, without adding it to the queue.)

 

[box26609]

Thanks for the explanation, but after reading this several times, I still don’t see how this would work in my case.

My station does not use a single generic hourly structure.
I have different clocks for different hours — different music categories, different jingle sets, different rules, sometimes different program logic. In total, there are around 77 different clock variations.

With that in mind, I don’t understand how a single repeating “create” event (or a template-based approach) is supposed to handle this.
If every hour has a different clock and different rules, how can one repeating event — or even a repeat every 60 minutes setup — reliably generate the correct playlist for each specific hour without manually mapping and maintaining all those dependencies?

From my perspective, this still looks like replacing a clear and explicit workflow (each event clearly represents what happens in that hour) with a more abstract one, where the actual behavior depends on naming conventions, variables, and implicit assumptions. That makes it much harder to verify and control in real daily radio operation.

Could you please explain concretely, step by step, how a station with many different hourly clocks (not a uniform hourly structure) is supposed to implement this using the proposed approach?
At the moment, I understand the theory, but I don’t see a practical, safe way to apply it to a real-world radio setup like mine.

I like how thorough and clear you are in explaining the issues. You are able to clearly put into words the questions I have in my head. As a fellow radio programmer, thanks!

 

[djsoft]

Thank you for your reply. The idea would be to be able, via the API, to enable or disable an input, and it would be even better if a fade parameter could be added. That’s why the mixer would be perfect for this.

Maybe in the future, but for now we'll need allow the mixer to evolve and then probably add API support there.

It’s impossible for me to save an icon in this file type. I select an icon in the file type settings and click OK, but when I go back, the icon is gone. It seems like the change is not being saved.

Yes, this is a bug, change some other option for a file type to make it save the icon.

I've had the suspicion that alot of the repeat protections seem based on the creation of 24 hour playlists in which repetitions can more easily be prevented. Since Radio boss has no overall day part music clock scheduling system (like most other radio scheduling systems), it means for some of us we have to create events to generate playlists every hour. The result is that, in my case at least, it is not uncommon for the same song to be inserted by the playlist generator an hour later when it generates the next hour's playlist. Or am I doing it wrong?

It doesn't matter if you create a single 24-hour playlist or 24 one-hour playlists, or something else, repeat protection also checks the "Last played" tag to avoid repeats. Unless you disable it of course (Settings tab in the playlist generator; it's enabled by default). It also has an option to check tracks that present in the playlist and not played yet. This option is also located in the same Settings tab.

So there are tools to avoid repeats no matter how many playlists you create and when.

I too am curious about this process and would like to know how to implement it.

Please see my reply to @tomimatko here: https://www.djsoft.net/community/threads/radioboss-7-2-beta.13899/post-57318

 

[djsoft]

One more question: if I set “do not repeat track for 6 hours”, will this rule apply to all next clock rotations?

Any repeat protection rules defined in the preset, are applied when a playlist is created using this preset.

-the “On Air” and “Next” panels could be combined so the crossfaders are visible in real time — something like a live segue editor.

Interesting idea - noted for the future, we'll consider it, thank you.

AutoIntro is very useful — the new interface is great, but it would be interesting to be able to see the file name in the interface.

You can see it in the log where it says "Inserting auto intro ...".

Also, does the new function “Do not play at the same time as yesterday” make use of “Ignore global no-repeat rules” for the station imaging?

Currently not, it's checked separately. I think this can be considered as a bug and it must take into account the "Ignore ..." option.

The icon configuration is lost for file types.

This is a bug, change some other option for a file type to make it save the icon.

Lastly, with the new mixer, it’s very difficult to select 0 dB after moving it.

Right-click the slider to reset it to zero.

 

[djsoft]

I checked the box, but the clock is still in 12-hour format. It would be helpful to be able to change the date format.

Probably a bug, we'll check it.

Is it possible to add an advanced option to increase the FPS between 20, 30, 45, and 60? I believe that, in my case, it does not affect performance that much due to my PC’s specifications.

I think yes.

Another feature regarding Now Playing: is it possible to add another seek/status bar? This bar would indicate the estimated time it will jump to when hovering the mouse cursor over it.

This bar will have to be placed somewhere, and UI is not going to be changed again. A tooltip can be added showing the expected seeking position.

 

[djsoft]

It seems that we are approaching this from two different angles. You are looking at it from an engine/developer point of view, where it is essential to know the exact start date and time down to the second, so that dayparting rules can be applied deterministically.

Dayparting will work with generate command as well (if start time/day is supplied there). The problem is unpredictable start time, and we did receive a lot complaints about it and it's understandable as (almost) everyone wants things to start on time and any randomness here is not welcome.

I cannot realistically monitor whether each generated playlist is correctly linked to the corresponding event, what happens if I create a new playlist generator preset, rename one, or delete an old one, or whether a file-based playlist was actually generated successfully before it is supposed to start playing.

As I said before, you can change how things are configured. There are many different ways, one I described above with using templates. Here's another, and it's just an example, for hourly programming

1. You create a playlist every hour using various presets but always save those playlists to the same file. Let's say it's C:\playlist.mp3 - this should happen every hour.
2. You create an event that runs every hour and starts this C:\playlist.mp3.

This way, you run various "create playlist" events and they overwrite the playlist file.

In practice, this means moving from a simple, safe, and easy-to-control workflow (one event, one click, generate and continue playback) to a significantly more complex one, with multiple steps, external executables

Using the generate command also involves calling the same executable "PlaylistGeneratorPro.exe" but it saves the playlist to a temp file and then starts it. In terms of reliability, there's no difference.

Since a simpler, single-step “generate & start” option is currently only a possible future idea, with no confirmation, I will remain on version 7.1 for my daily radio work for the time being.

It's not a big deal to extend the generate command to specify start time/day. But the point is to encourage approach where everything runs predictable, playlists start when they are programmed to start and not "when it's ready" which is random.

If every hour has a different clock and different rules, how can one repeating event — or even a repeat every 60 minutes setup — reliably generate the correct playlist for each specific hour without manually mapping and maintaining all those dependencies?

There's actually a feature request for cases like this, to create a tool similar to the Ads Scheduler, but instead it will create scheduled events to create and run the playlist. Effectively automating your approach to programming. The point of such a tool to reduce manual event management and see everything in a grid.

 

[djsoft]

The way I see... Playlist generator pro will just have to have a new tab just for assigning different clocks/presets to the different hours of day. Generate all playlists for the 24 hours once and they're loaded into the scheduler section to load at their play hours... Just like the Ad scheduler. Just saying.

Yes, this is an existing feature request and this will be possible in the future.

 

[djsoft]

I can confirm the problem (the afternoon has just begun as I write this).
Furthermore, when the time is adjusted in the display settings (view), the change is not applied. However, it is correctly applied in the window next to "On Air".

Thank you, this will be fixed.

They can add the option “mark as next” on double-click. (Only mark as next, without adding it to the queue.)

The playback queue if, effectively, a "mark as next" feature.

 

[xzsaimon16]

“There should be an option to delete comments in the forum.”

 

[xzsaimon16]

The playback queue if, effectively, a "mark as next" feature.

The “Add to queue” function is not the same as “Mark as next”.
The queue creates an additional list with one or more tracks and requires management, which becomes tedious when you want to quickly change the next track.
“Mark as next” would be a one-time action: the selected track plays immediately after the current one, then playback continues normally without creating or modifying any queue.

 

[xzsaimon16]

I think yes.


This bar will have to be placed somewhere, and UI is not going to be changed again. A tooltip can be added showing the expected seeking position.

Thanks!

 

[nelson c]

There's actually a feature request for cases like this, to create a tool similar to the Ads Scheduler, but instead it will create scheduled events to create and run the playlist. Effectively automating your approach to programming. The point of such a tool to reduce manual event management and see everything in a grid.

I support that idea!

 

[nelson c]

Nice interface refresh!

Thank you for your work

 

[djsoft]

“There should be an option to delete comments in the forum.”

I don't recall exactly why, but it was disabled for some reason.

“Mark as next” would be a one-time action: the selected track plays immediately after the current one, then playback continues normally without creating or modifying any queue.

This would be yet another queue, but limited to a size of one. I don't think it's necessary. Queue allows doing all that.

Nice interface refresh!

Thank you!

 

[tomimatko]

OK, I think I understand it now — please correct me if I’m wrong.

The idea is to have one scheduler event with multiple “Generate playlist” actions, for example:

run PlaylistGeneratorPro.exe "-preset=Funky" "-out=C:\Users\tomim\Downloads\Funky.m3u8"

…and then repeat this for all presets.

In my case, this would mean around 77 generate commands/lines inside a single event. I don’t consider this an edge case — in practice, most reasonably serious radio stations operate with a large number of presets, not just 5–10, unless the format is very simple or narrowly specialized (for example, a pure hit radio).

If I later remove a preset, I must manually find the corresponding line among those 77 actions and delete it.
If I add a new preset, I must remember to manually add a new generate line for it.
If I forget to do this, that preset won’t generate a playlist, which could result in dead air.

So effectively, instead of having 77 separate “Generate playlist” events, I would have one event containing 77 generate actions, which is functionally similar but still quite hard to maintain and not very transparent with a larger setup.

My question is:
Is there any command, option, or mechanism that would allow generating playlists from all presets that exist in Playlist Generator (or from the folder where .genprs are stored), without explicitly listing every preset name and having to constantly maintain those lines manually?

Or is explicitly defining each preset (either as a separate event or as a separate generate action) still the only supported way?

Thanks for clarifying.