Guillaume
Active member
There was a topic in this thread.
Response :
https://www.djsoft.net/community/threads/radioboss-7-2-beta.13899/post-57560
RadioBOSS 7.2 [beta]
- Thread starter djsoft
- Start date
Response :
https://www.djsoft.net/community/threads/radioboss-7-2-beta.13899/post-57560
Willian Cassiano
New member
There's a delay in the VU meter; the music starts and it takes almost a minute for the meter to go up.
This will likely be be added in the future, an option e.g. "Override global setting" but not in this beta because there are lots of other things that need to be done for this version.
Yes, presently it will only show when it has finished with error, but not success.
It depends on when the playlist is generated and what the Start Time is. For example, if today is Thursday and you create a playlist for Sunday then repeat protection rules, even if set for like 12-hours as in your case, will not apply, because it's 36+ hours between those days.
Playlist Generator considers playlist's start time or repeat protection.
If you only set the start time and do not set start day, it's also taken into account, assuming the playlist will start later today (but calculating the time difference).
We'll consider this, thank you.
There's an option in Settings > Control: Mouse double click function. Another option may be added: "Add track to playback queue" what do you think? For now, you can add a track to the queue by selecting it and pressing Q.
We won't be adding another single-queue option just for setting the next track as it's a duplication of existing feature and having multiple conflicting next track options is not good.
It means that the Playlist Generator was not started from within RadioBOSS. What happens if you generate the same preset, but from the scheduler?
Further thinking of this, it still may be added as an override of a global option.
A quick test does not confirm this, the meters work instantly after a track is started. Maybe a track itself has a quiet start?
xzsaimon16
Active member
As I understand it, do I need to create many more generate command events for each day of the week? Because I don’t see any other option that would work the way I want.
Honestly, I don’t fully understand how to implement dayparting in my case unless it’s by adding many events for each day of the week, which would require more work.
The events in my current workflow are only three (at the 59th minute of every hour) to generate the playlist and one to load it (at minute 00 of every hour).
In my case, would the missing piece be an option to use the current time? Or could an option be added to configure the estimated start time to something like: “in xx minutes,” “in xx hours,” etc.?
I think adding tracks to the queue with a double-click this way is fine.
However, if we accidentally add a track we don’t want, how can we remove it and select the correct one more quickly? Right now, we have to open the queue manager, delete the track, and then search and add the correct one, which feels like too many steps when speed is essential.
For example, if there are only a few seconds left and I select the wrong next track, the current method (adding to the queue) makes me lose too much time.
Thank you, will be fixed.
There's "generate multiple playlists" option that you may use to reduce the number of the events. In this case, "Start time" for each subsequent playlist is increased, e.g.
First playlist: start time is as set in the parameters.
Second playlist: start time = set start time + first playlist duration.
And so on.
Quickest ways are: press Alt+Q or right-click a track and select "Remove from playback queue". It's actually a very rare case when you need to use the queue manager.
Adding to the queue by double click will be possible soon.
This is a very special/rare case, and still it's pretty easy to handle: you first add the correct track to the queue and then remove unwanted track with Alt+Q, 1-2 seconds is enough to do it.
xzsaimon16
Active member
Bueno, intenté que funcionara sin tener que crear tantos eventos adicionales, y para mí es complejo, ya que inevitablemente tengo que crear muchos más. Actualmente, tengo cuatro: tres para generar y uno para cargar.
El uso de múltiples listas de reproducción, aunque evita agregar tantos eventos, sigue siendo complejo porque tengo que crear muchos eventos de "carga".
Entonces, ¿no sería mejor añadir una opción para definir el tiempo estimado como un número aproximado de minutos u horas tras la generación? Obviamente, en función del momento en que se activa el comando de generación.
Por ejemplo:
Evento: la creación de una lista de reproducción comienza a las 12:59 y el tiempo de reproducción estimado es 1 minuto después (13:00).
También podrían ser más minutos, una hora, dos horas, etc.
Algo como esto sería la línea de comandos:
ejecutar PlaylistGeneratorPro.exe "-preset=PATRON 2" "-out=D:\PARA RADIO\Data Base Radio boss\PLAYLIST\PLAYLIST.m3u8" "-starttime=00:01:00 después" "-startday=hoy "
o
ejecutar PlaylistGeneratorPro.exe "-preset=PATRON 2" "-out=D:\PARA RADIO\Data Base Radio boss\PLAYLIST\PLAYLIST.m3u8" "-starttime=00:01:00 después"
Honestamente, no estoy seguro de cuáles serían los pros y los contras o cuán lógico es este enfoque. In my case, it would work for me, since I generate and play using two separate commands. I wouldn’t need to create more events than I already have. I’m not sure what others might think or how it would work for other users.
Last edited:
radiotelevision
New member
Hi Dmitry:
The interface is still clean, and with the modifications, it looks even better.
Perhaps my suggestion is purely aesthetic, but would it be possible to add a "max peak" function to the VU meter, so that the maximum LED stays lit for a moment?
Best regards.
The interface is still clean, and with the modifications, it looks even better.
Perhaps my suggestion is purely aesthetic, but would it be possible to add a "max peak" function to the VU meter, so that the maximum LED stays lit for a moment?
Best regards.
Probably not, I'm sorry.
Please write in English.
Thank you! Regarding max level fall off indication, this will be added in the next update.
xzsaimon16
Active member
Sorry, when translating and editing, the changes are saved in Spanish.
Well, I tried to make it work without having to create so many additional events, and for me it’s complex, since I inevitably have to create many more. At the moment, I have four: three to generate and one to load.
Using multiple playlists, although it avoids adding so many events, is still complex because I have to create many “load” events.
So, wouldn’t it be better to add an option to define the estimated time as an approximate number of minutes or hours after generation? Obviously, based on the moment when the generation command is triggered.
For example:
Event: playlist creation starts at 12:59 and the estimated playback time is 1 minute later (13:00).
It could also be more minutes, one hour, two hours, etc.
Something like this could be the command line:
run PlaylistGeneratorPro.exe "-preset=PATTERN 2" "-out=D:\PARA RADIO\Data Base Radio boss\PLAYLIST\PLAYLIST.m3u8" "-starttime=00:01:00 after" "-startday=today"
or
run PlaylistGeneratorPro.exe "-preset=PATTERN 2" "-out=D:\PARA RADIO\Data Base Radio boss\PLAYLIST\PLAYLIST.m3u8" "-starttime=00:01:00 after"
Honestly, I’m not sure what the pros and cons would be or how logical this approach is. In my case, it would work for me, since I generate and play using two separate commands. I wouldn’t need to create more events than I already have. I’m not sure what others might think or how it would work for other users.
Guillaume
Active member
From the Scheduler, I get the same type of result and the problem is identical: some tracks already present in the playlist (the player) are in the playlist file (.m3u8).
I think the playlist tracks aren't being taken into account when generating multiple playlists.
oh yeah i realised that it wasnt like that in 7.1
for some reason since yesterday when i have the mic on, music is no longer heard locally at the lowered level set its just simply disabling music. no setting have been changed from how it was a week ago when i was last on air and Mute Monitor sound card is NOT selected only output to encoders nly is so i dont hear myself... theres also a delay from when i turn the mic off to when i start hearing it again
I know there was a similar issue back in build 5
I know there was a similar issue back in build 5
patrick.de-bruyn
Active member
If you have assigned a custom color to a playlist tab, this color does not change to the color set for the active playlist when you activate it.
The Tabs in previous version where much better in my opinion
The Tabs in previous version where much better in my opinion
Last edited:
patrick.de-bruyn
Active member
In the mixer, the setting for Main has no effect on the signal to the stream server.
That might be interesting.
That might be interesting.
