RadioBOSS 5.8 [beta]

[Pretmaker]

Quick question, what does this fix/feature entail?

* Music DSP does not affect microphone

Does that mean that any DSP/VST plugins that are set on the main FX tab will not be used with the microphone output? If so, how can we set the same DSP plugin on the microphone with the same settings without causing too much latency?

Reason this is important is that in the DSP FX properties I use StereoTool enhancement with AGC and other optimizations that create a specific sound for internet broadcasts (to the same degree normal FM stations use to create better and distinct sounds).
If for example the microphone would not route trough this, that would mean that my voice won't be able to sound louder than the music.

If I read this feature correctly, it would be a no-go for this release as this is limiting output encoding options for internet radio stations.

 

[DJSTU]

Dear djsoft.
Normally I try my best to be complementary of your efforts to make improvements to RB (which are usually pretty good). But sometimes when people are putting forward suggestions/improvements, your response is instead making me irritated. And today is one of those days.
SO today I am going to put my critical hat on.

Sometimes developers get into the mode of "I know whats best", but in fact as a consumer if you don't provide what I want, I will move on to where I can find what I want because somebody is providing that need. Sometimes you need to be pushed into making changes, much as you might be reluctant to do so.
You cannot sit on your laurels and not make changes because they are too hard. That argument doesn't wash. Don't put things into the too hard basket. Nothing is too hard, it just needs working on.
Consumers are the ones that drive changes and should be listened to.
The old saying goes "Change or be Changed".
Reading your replies today (and not only today either), I am getting the distinct impression you don't want to make change because you don't want to listen to what people are saying and just flinging out the "too hard" argument to deter them.
Today you have been told by several people that improvements are needed, and I have to agree with them. Many (in my view) are long overdue. Most of us can adapt to change, particularly if its an improvement that makes the software operate better for us. However change cannot be dramatic and ohh so different...suddenly. Its has to be slow and incremental and more than anything an improvement on the previous version, but at a pace that people have no trouble in adapting to (a classic example of a bad software change was when Winamp tried to bring in their Ver 3, it was a disaster, as it was to dramatic a change, and people disliked it intensely).

Basti is right when he says there needs to be a better order, a more logical place to find things.
For me your Options layout is a nightmare to work through. Things are all over the show. Its like bits have been added in, and ohhh where will we put it, ohh lets just plonk it in here, because there is a gap.
Options need improving....consolidating and re-ordered. Majorly !

You should instead of just saying to Basti that his graphics "look nice", instead you should be asking for others opinions on his layout, what do you lot think of his suggestions ?, and then considering those replies and making changes as a result.

Your HELP should be online and in one place only. Having help in the software these days is old hat and yesteryear. If you had it online, you would only need to make one change, in one place, and quickly, without it being such a laborious task under your present system.

There must be a much better system for translations. Surely ? Consumer driven. A place where nominated members can log on and can go and actually do the translations for you immediately, you then pick it up and make the change straight away in RB and in Help. You seem to have a laborious process for these language changes which could be improved, saving you a task which you don't seem to like doing ?

 

[DJSTU]

Please note that RadioBOSS never reads the "nowplaying" file. It only writes to it. It sends the titles to the server according to the rules (broadcasting title format etc). If it's playing a network stream, it reads the title information from the stream - then it will write this title to the nowplaying file (if enabled) and will send the same title to streaming servers it broadcadts to (according to broadcast title format and other settings).

I do fully understand that. And always have.
What I having been saying is that title information being sent to the nowplaying file is not the same as that being streamed direct.
The "Include Next Track Info" box is ticked

(1) nowplaying file contains two titles (Stream #2)
(2) the inbuilt streamer is providing just one title to the Server (Stream #4).

So its saying one thing to the nowplaying file and another to the direct stream.
And THAT is what I am asking to be fixed.
Look at my Server and see streams #2 and #4 (as previously advised).
There is the result of what I am talking about.
http://138.68.236.50:8000
Stream #2 has two titles and Stream #4 has just one title.
Both are coming from the very same RB with the "Include next Track Info" box ticked.

This is a classic example of what I was talking about before, with choices in Options being all over the show and not in a logical and obvious location.
The "Include Next Track Info" choice should be in Broadcast/Metadata, the obvious place to be making this choice. And NOT under reports.

 

[nelson c]

Bug in file type: changes are applied when editing. (If the edition is canceled the same change applies)

 

[djsoft]

Another track with problems using the MySql database: I guess by the file name.

The next version should have this problem fixed.

YES. When it reaches the end of the Playlist and then repeats, nothing is changing excepting the Start Time. You no longer have the new playlist look (un-played) but instead have the stale played look recycling. The list should look like new every time it repeats.
And I am looking for some way to achieve this.

OK, I think there will be a way to do it - a scheduler command and/or menu command to reset the played state.

For me, the Playlist is short (circa 15 to 20 items) and changes every day. I just don't need any additional information such as play counts etc.

This is counted automatically and you're free to ignore this information Turning this off is not a good solution as many other parts of the program require additional information to function properly.

Every time play count etc rewrites the file, old files get placed at the top in the folder. Now I have to go hunting for whats new.

In this case, the best solution would be to switch additional information storage to SQLite database. It does not require any configuration, so the only thing you need to do is change the type in the settings and click OK. This will keep the files unchanged while the information will be stored, in case you need it (note that it's not only playcount, it's also all labels in Track Tool, "disabled" flag, etc - basically, anything beyond the standard tag fields).

Does that mean that any DSP/VST plugins that are set on the main FX tab will not be used with the microphone output? If so, how can we set the same DSP plugin on the microphone with the same settings without causing too much latency?

Yes, this means that now music DSP (the one that is configured in the main window) does not affect microphone. However, generally you wouldn't be able to use the same plugin for mic and music as due to how most of the plugins work, there will be conflicts, weird error messages etc.

If I read this feature correctly, it would be a no-go for this release as this is limiting output encoding options for internet radio stations.

We can make it configurable, to switch it to work as it was. But we received lots of complaints about it - many people didn't like that music DSP is applied to microphone.

 

[djsoft]

Normally I try my best to be complementary of your efforts to make improvements to RB (which are usually pretty good). But sometimes when people are putting forward suggestions/improvements, your response is instead making me irritated. And today is one of those days.

I think the problem here is that a short forum reply does not really show some important internal processes. Most suggestions, even if not immediately accepted (or implemented) still go to the internal bug tracker for later consideration; later they are being compared to other similar suggestions and our own view on how the product should develop. So nothing is dropped if I say "we won't implement this now".

Consumers are the ones that drive changes and should be listened to.

This is how it always was and will always be here. There are many new features added each version and most of them were asked before by csustomers. Like something is asked during RB 5.6 beta and the feature is added in 5.7 or 5.8. There are bad examples as well, when requested feature was added after 7 years. But this is an exception and most of the time it is much faster.

a classic example of a bad software change was when Winamp tried to bring in their Ver 3

Yes, this is a good example of how changing the UI goes wrong, and that's why rearranging settings window in RadioBOSS could become such a bad example as well.
Yes, there are some settings that are accessed more frequently than others, but that also depends on the user's situation... RadioBOSS settings window is not really complicated, and it doesn't (yet) require complete overhaul (while some minor improvements could be made and anyone is welcome to suggest those). I suggest you to take a look at the options window from Visual Studio to compare (attached).

For me your Options layout is a nightmare to work through. Things are all over the show. Its like bits have been added in, and ohhh where will we put it, ohh lets just plonk it in here, because there is a gap.

This is not far from the truth, actually. The "Fading" section is the extreme case of this.

If you think that some changes should be made, now is a good time to state those - some of them might be implemented right in this beta, or be moved to the future releases.

You should instead of just saying to Basti that his graphics "look nice", instead you should be asking for others opinions on his layout, what do you lot think of his suggestions ?, and then considering those replies and making changes as a result.

This is implied, and anyone is free to comment on proposed changes, or offer something else.

Your HELP should be online and in one place only. Having help in the software these days is old hat and yesteryear. If you had it online, you would only need to make one change, in one place, and quickly, without it being such a laborious task under your present system.

I think I was misunderstood, the manual was mentioned to show that renaming some option is not as simple as might seem - and its should be done where it's justified.
The online help available as well: https://www.djsoft.net/enu/support.htm
And, of course, internally it has one base source from where all help formats are built.

There must be a much better system for translations. Surely ? Consumer driven. A place where nominated members can log on and can go and actually do the translations for you immediately, you then pick it up and make the change straight away in RB and in Help. You seem to have a laborious process for these language changes which could be improved, saving you a task which you don't seem to like doing ?

It's automated for the most part. Regardless of how the translation is made, if some option is renamed, it will require for the translation maintainer to update the translation - and this is one more reason to avoid renaming unless it really brings value.

 

[djsoft]

What I having been saying is that title information being sent to the nowplaying file is not the same as that being streamed direct.
The "Include Next Track Info" box is ticked

(1) nowplaying file contains two titles (Stream #2)
(2) the inbuilt streamer is providing just one title to the Server (Stream #4).

Yes. The different information is sent. The "Include Next Track Info" only controls if the nowplaying file will include the next track information. It does not affect what is being sent to the streaming server. Also, IIRC, servers do not have means of accepting the next track information, they only show the currently playing track information.
Typically, if you need to show the next track on your web site, this is achieved by other means like exporting the nowplaying file to your web site and use it to show the current and next track names, an example is here: https://www.djsoft.net/smf/index.php/topic,3176.0.html (it's for the current track only but the principle is the same).

The "Include Next Track Info" choice should be in Broadcast/Metadata, the obvious place to be making this choice. And NOT under reports.

This option is there as it only controls how the "nowplaying" file is formed and does not affect anything else.

In your example, I understand (from your other posts) that a different process is involved. Where you have the two titles, it comes from RadioCaster which reads RadioBOSS's nowplaying file that has current and next track titles. So the title source in this case is nowplaying file, which is not the case in RadioBOSS.

There can be a pretty simple solution, as RadioBOSS already "knows" what will be playing next, we can add new title variable that will hold the next track title, so it will be possible to set the streaming title format to something like this:
Now playing: %artist - %title (next: %nexttitle)

What do you think?

 

[Pretmaker]

If I read this feature correctly, it would be a no-go for this release as this is limiting output encoding options for internet radio stations.

We can make it configurable, to switch it to work as it was. But we received lots of complaints about it - many people didn't like that music DSP is applied to microphone.

Please do make it configurable, as allot of people are using this feature like this I think. If you want, I can give you some examples audio files of what happens exactly between the 2 versions so you'll see the need for this .

 

[djsoft]

Please do make it configurable, as allot of people are using this feature like this I think. If you want, I can give you some examples audio files of what happens exactly between the 2 versions so you'll see the need for this .

This is not necessary - a configuration option to control this will be added in one of the next updates.

 

[celso]

I would like to do the translation into Portuguese Brazil, there are many differences for Portuguese Portugal, they will be better understood. I wonder if you have any program for this.

 

[djsoft]

I would like to do the translation into Portuguese Brazil, there are many differences for Portuguese Portugal, they will be better understood. I wonder if you have any program for this.

I think this will be better discussed in private - please write to support@djsoft.net and we'll continue there.

 

[djsoft]

Bug in file type: changes are applied when editing. (If the edition is canceled the same change applies)

Yes, this is a known issue and the problem also exists with broadcasting encoders and some other settings too. I don't think this will be fixed, instead, the Cancel button may be removed from the settings, as it seems to be how most of the "settings" windows work nowadays (e.g. settings in Windows 10).

 

[DJSTU]

Thank you djsoft for your replies.
I will try and work my way through some of these issues and post them.

There are often small anomalies and this is one of them that shouldnt be. You could argue its obvious. But to someone, it may not be. :

Options/Styles
Here you have :
Previous Track
Current Track
Next Track

AND YET the actual names being used are totally different
Last Track
ON Air
Coming Up Next

So the question is, why does Styles not match the actual names being used ?

 

[DJSTU]

Yes, there are some settings that are accessed more frequently than others, but that also depends on the user's situation... RadioBOSS settings window is not really complicated, and it doesn't (yet) require complete overhaul (while some minor improvements could be made and anyone is welcome to suggest those). I suggest you to take a look at the options window from Visual Studio to compare (attached)

I am not familiar with Visual Studio, but you are absolutely right, its a shocker of a menu system. And certainly a good example of "how NOT to do it" !
But its not a matter of just saying how good yours is compared to them. You need to be saying to yourself "how can we bring an even better presentation to that which we presently provide".

Now here is a small example of what I spent 35 frustrating minutes today trying to find. That was driving me Nutz. I couldn't remember how I had changed the colour under the mouse. I went thru everything in Style's, hunted high and low elsewhere, went away in frustration, came back afresh , and finally found it.

BUT my thinking was "should this not have been under Styles in the first place, where all the colour changes are located ??". And I daresay I would have found it in no time, were it to be located there ?

 

[DJSTU]

If you think that some changes should be made, now is a good time to state those - some of them might be implemented right in this beta, or be moved to the future releases.

I think people will put stuff forward, if they think you will carefully and considerately listen to their idea (I am never sure whether its just you, or other people are involved). They want to hear what you/they think, and whether the time and effort they have put into it has made their often at considerable time and effort worthwhile.
I am not certain that Basti would have gone away with a great impression of how you handled it. That you gave a lot of weight to it.  He went to a lot of trouble with his graphics, a lot of work involved, but you needed to leave him with the impression you have looked at it with very serious regard as to its practicality, and whether or not you would adopt it, not necessarily now, but eventually in the future. Even if you just used it as a building block for another idea.
Not just putting it into the too hard basket. Was it a good idea. Did you like it ? Was it practical ? Will you use it ? How did you leave Basti with some praise, some idea of where his proposal would be heading for further use or development ?

Not every proposal put forward will be a winner. Yes, I agree on that.
BUT from your consumers will come some great ideas.
They do the work, you make the gain.

I liked Basti's proposal and that is why I made a post supporting it. It solved what I saw as an issue, too many choices not in some sort of logical place and order. What he proposed was so much better than what already exists. I liked the fact that he used graphics, to try and give you a very clear idea of what his proposal was.

 

[DJSTU]

OK, I think there will be a way to do it - a scheduler command and/or menu command to reset the played state.

Yes, just do it.
Whatever way you think is the best.

In this case, the best solution would be to switch additional information storage to SQLite database.

I have switched to SQLite and will see if I feel happier about the way things are running.

APEv2
I struck an issue with APEv2 whereby a small, just over a one minute track, kept cutting into about one third into the track (from the start) in spite of the fact that there was a Start and End put in via Tracktool.
I couldn't find any logical reason for it happening. So in the finish I put a Mix in via Tracktool lined up right next to End, and that finally caused the track to work as it should.
Maybe it was something I couldn't physically see that was causing the issue, but it did leave me wondering if Tracktool should have a button to click that says "Clear all settings back to Original" ?

 

[DJSTU]

There can be a pretty simple solution, as RadioBOSS already "knows" what will be playing next, we can add new title variable that will hold the next track title, so it will be possible to set the streaming title format to something like this:
Now playing: %artist - %title (next: %nexttitle)

What do you think?

Yes, agree.
That would be a good solution.
Will the word "Next:" appear ?

You have talked about a nowplaying.txt template that is coming up in the future, which I am presuming RadioCaster and RadioBoss will both be using ?

Is there some technical reason as to why the inbuilt broadcast doesn't have the ability to choose the nowplaying.txt file just like Radiocaster does (being an optional choice within Radiocaster) ?

 

[hro_sebastian]

and it doesn't (yet) require complete overhaul (while some minor improvements could be made and anyone is welcome to suggest those).

The first small step could be the style settings only I suggested here in (2): https://www.djsoft.net/smf/index.php/topic,5601.msg27393.html#msg27393

Maybe also work on Track Tool suggested here: https://www.djsoft.net/smf/index.php/topic,5601.msg27395.html#msg27395

These 2 small things would be a beginning to a good future, or so?

 

[DJSTU]

I have found what I am pretty sure is a major BUG.
The smaller the file, the bigger this problem seems to be in the sense that its get exaggerated.
In fact it is chopping most of my files I am finding out, but some are several hours long, so you don't really notice. And the red line is virtually at the end, so close to the right hand side its not chopping much.

This all started when 3 small files together were not playing in full, in fact were jumping from one to the other, but not at a 6 secs mix.
The file in the Track Tool pic below is 84.3 secs long.
The mix point in Crossfades is 6 secs long.
Its mixing at where the red line is, but not turning the usual blue colour to show a mix fade out point (or is that just caused by Track Tool ? I am pretty sure its at all mixing points).
I was initially blaming this problem on APEv2, but now I don't think it is since its continuing on on SQLite

When you look at the pic showing the picture playing there is a red line at circa 60 secs from the end. This isn't 6 seconds from the end, but almost at the opposite end, the start (but not 6 secs from the start).
Whether "Remove Gaps" is on or off doesn't seem to make any difference.
Take the Crossfades Mix out and you will see in the second picture, the track will play in full with NO red line anywhere in the track.

To make sure I have this right.
When you add in a mix point by itself, it mixes at that point. In this example it mixes at 6 seconds.

NOW if you add in "Trigger Mix at" it reads ahead from 6 seconds until the end (or end of actual sound), determines where the -11.3 db target is and mixes at that point.
"Trigger Mix at" does not work by itself when I read the Help file. Only in conjunction with the Mix Point.

If I have that right, and that is the way it is supposed to work, then something is wrong.

 

[DJSTU]

There is another Bug.
In making additions or deletions in the Playlist, there has been quite a few times now when I have clicked on the SAVE button only to have it come up SAVE AS. YES, I am clicking on the right one.
I just ignore it and escape.
Five minutes later I can do the same thing and the SAVE button will work exactly as expected.

Its not constantly doing this error, just erratically.

PS:
Maybe something to do with suffix.
I am using .m3u
I think sometimes its looking for and defaulting to .m3u8
hence its coming up with a save as.