RadioBOSS 7.2 [beta]

[madein80]

Thank you!


API may be added but may be later once the mixer settles in - otherwise we will spent more time doing then redoing the API in case mixer needs to be changed considerably for some reason. Maybe you can achieve the same using the existing API commands - depending on what exactly needs to be switched on/off.

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.

 

[madein80]

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.

 

[box26609]

Yes, there are users who run a single 24-hour playlist, and for them this approach is easy. But a serious radio station runs many playlists, depending on the day, time of day, weekends, and special programming.

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?

 

[box26609]

1. One event generating many playlists
You said that all playlists can be generated in one event.
How exactly would this work if I have 77 different playlists?
Do I need one long command with many presets and output files, or is there a simpler and more practical method for real radio use?

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

 

[tomimatko]

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

I didn’t know about this at first either. The key is the “Create Multiple Playlists” option — it’s a bit hidden, so check the Help section for instructions on how to use it.
It’s still more complex than the old workflow, but it allows you to generate all playlists with a single event instead of many separate ones.

 

[tomimatko]

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

 

[nelson c]

Hello Dmitry,


Congratulations on the new version.


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

 

[nelson c]

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.

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?

The icon configuration is lost for file types.

In the additional workspace area, it would be useful to duplicate the On Air and Next panels so the presenter can have that information visible on another monitor.

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

 

[djsoft]

I understand this, but it’s necessary to implement the icons (previous, current, and next). Where will they be added? Inside the “icon” column, or will there be another column called “status”?

I think inside the Icon column, just add a second icon to the right. Adding a third column seems too much I guess.

I fully support the idea of making it possible to choose the position of the countdown timer. So far, I have not encountered any errors in the operation of RB. I like the new clock display option in the menu.

This should be implemented soon.

 

[djsoft]

You said that all playlists can be generated in one event.
How exactly would this work if I have 77 different playlists?
Do I need one long command with many presets and output files, or is there a simpler and more practical method for real radio use?

One command, or multiple commands for each preset, or combine like generate 5 playlists with this preset, then 10 playlist with the other etc. It depends on what approach is better for you.
It can be a single command to e.g. create all playlists for the whole day in one go.

It can be a different approach if the presets are named after the hour they are supposed to start at, you can use templates to have a single event to create all playlists and second event to start them.

For example, the "create" event starts at hh:50:00 every hour (use the "Repeat every" - 60 minutes option, or start by Hours, or multiple start times)
run PlaylistGeneratorPro.exe -preset=playlist?hh ...

And then start those playlists at hh:59:59 every hour
C:\path\to\playlist?hh.m3u8

As you see here, playlists and presets are named including the hour and ?hh variable is the current hour (0-24).

With this approach, when I add a new hour or remove one, I must also remember to update the central “generate playlists” event.

Again, it depends, if you just edit the presets it will consider all the changes when it's the next time to create the playlists. Once you have the general template in place (see the example above where it creates a new playlist every hour based on this hour's template), you then just add music and edit presets.

We are moving from a simple, safe, and easy-to-control workflow to a more complex one with more dependencies and more things that can go wrong.
Please correct me if I am misunderstanding this.

As I told you before, the "old" workflow has a fatal issue that you don't know when the playlist will start playing.

Is this planned for RadioBOSS 7.2.x, or is it only an idea for some future version?

It may be added as an option I guess, but I can't promise anything, we need to test it first.

 

[djsoft]

I understand, but it would be possible to set one color for the intro time and another for the outro, to distinguish them.

It doesn't really separate them because this timer is a sum of both. You see if it's intro or outro in the nowplaying bar (if it's the end of a track, it's outro, if a new track had already started, it's intro).

Additionally, I would like to be able to edit the color of the “intro and outro” marker within Now Playing.

This can be added.

I would also like the position marker’s movement to be smoother. On short tracks, it’s noticeable that the sliding movement is abrupt.

The nowplaying bar is set to 20 frames per second. Making it update more often will consume more CPU/GPU with no real noticeable improvement (we tested it). This is how it's going to be for shorter tracks.

 

[djsoft]

In practice, this means more steps, more manual selection, and more things to remember. For daily radio work, this increases complexity and the risk of mistakes, without improving the actual on-air result.

Please see the example of how it may be done differently. Also, you create all those events once, not that you have to re-do them again and again every day.

From a radio editor’s point of view, the previous “generate and start in one step” workflow was simpler, safer, and better suited for real-world operation.

And what about unpredictable start time?

 

[djsoft]

I created the event correctly as well:
run PlaylistGeneratorPro.exe "-preset=Funky" "-out=C:\Users\tomim\Documents\Funky 2.m3u8"
However, every time I generate the playlist, all jingles appear in the clock, including the weekday ones.

This command does not specify the start time and day, so dayparting will not work in this case, as the Playlist Generator doesn't know when the playlist is going to launch. Please use the Wizard in the Scheduler to create a command that will include this information.

 

[Radio Souvenir]

Clock uses the system time format. 24-hour clock can be enabled from Settings > View.

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

 

[xzsaimon16]

The nowplaying bar is set to 20 frames per second. Making it update more often will consume more CPU/GPU with no real noticeable improvement (we tested it). This is how it's going to be for shorter tracks.

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.


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.

 

[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.

Hello,
Your screenshot shows the time as of this Monday morning, and you posted it this Monday morning. I don't think it's not working… We'd have to wait until 1 PM to be sure And I think that if the 12-hour clock system is set (depending on your PC's configuration), an "AM" or "PM" indication would appear next to the time.

 

[Levine66]

Hello,
Your screenshot shows the time as of this Monday morning, and you posted it this Monday morning. I don't think it's not working… We'd have to wait until 1 PM to be sure And I think that if the 12-hour clock system is set (depending on your PC's configuration), an "AM" or "PM" indication would appear next to the time.

My PC clock is in a 24hour format. Radioboss playlist shows in 24 hours format. It's only the clock that remains in 12hour clock format... Even after forcing the 24 hour setting.

 

[tomimatko]

Thanks for the detailed explanations. I think I now understand the core technical reasoning behind this, but I’d like to explain why this is still problematic from a real radio workflow perspective.

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. From that perspective, generating playlists in advance and then starting them later makes sense, even if it introduces more steps and dependencies.

However, I work as a radio editor and broadcaster, using RadioBOSS every single day in real-world operation. For me, RadioBOSS is a daily working tool, not a system that I can continuously audit, debug, and validate internally. 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.

What is especially important here is that this represents a fundamental change of workflow that has existed since the very early days of RadioBOSS. This was never clearly stated upfront, so at first I assumed I was dealing with a bug or a configuration issue, not a completely different operational model. I had to discover this only through trial and error and forum discussion.

Regarding the specific issue with dayparting: I now understand that when I run a command like
<span><span>PlaylistGeneratorPro.exe -preset=Funky -</span><span><span>out</span></span><span>=Funky.m3u8<br></span></span>
the Playlist Generator has no information about the intended start day and time, and therefore cannot apply dayparting rules correctly. That makes sense from an engine perspective. However, when I am told to “use the Wizard in the Scheduler”, I am still missing a concrete, step-by-step example of what the Wizard actually adds to the command line and how a non-developer user can verify that this information is correctly passed. Simply saying “use the Wizard” is not sufficient unless it is clear what exactly changes and how this should be safely implemented in daily radio operation.

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, file-based playlists, naming conventions, and timing dependencies. Each additional step increases the risk of silent errors. For my use case, the practical gain from features like strict dayparting or “do not play at the same time tomorrow” is relatively small compared to the added complexity and operational risk.

Version 7.1 provides me with stability, predictability, and a very small margin for mistakes. The existing “generate and continue” workflow has worked reliably for many years. Whether playback starts a minute earlier or later has never been an issue for me, and it still isn’t. From a radio point of view, reliability and simplicity are more important than theoretical precision.

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.

That said, I will of course continue to follow RadioBOSS development and provide feedback whenever possible. I just need to use the version that best fits real-world radio operation in my environment right now.

Thanks again for taking the time to explain your approach and for listening to user feedback.

 

[tomimatko]

One command, or multiple commands for each preset, or combine like generate 5 playlists with this preset, then 10 playlist with the other etc. It depends on what approach is better for you.
It can be a single command to e.g. create all playlists for the whole day in one go.

It can be a different approach if the presets are named after the hour they are supposed to start at, you can use templates to have a single event to create all playlists and second event to start them.

For example, the "create" event starts at hh:50:00 every hour (use the "Repeat every" - 60 minutes option, or start by Hours, or multiple start times)
run PlaylistGeneratorPro.exe -preset=playlist?hh ...

And then start those playlists at hh:59:59 every hour
C:\path\to\playlist?hh.m3u8

As you see here, playlists and presets are named including the hour and ?hh variable is the current hour (0-24).

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.

 

[Levine66]

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.