VUMeter Plugin

[BoringName]

I thought the peak value was being calculated after replay gain was applied.

Yeah it is. But it seems we are talking about different things. I was looking at the settings tab where the volume adjustment was listed as a percentage. That seems to be separate to the volume leveling setting you have linked.

Volume adjustment adds an RVAD tag to the track where the value is -26 for a 10% volume adjustment or -51 for 20%...... great....

Analysing the volume adds REPLAY_TRACK_GAIN and REPLAY_TRACK_PEAK listed as a db value and peak value respectively. I assume querying the tracks ReplayGain property will return the REPLAY_TRACK_GAIN value and the volume adjustment is not involved? Who knows, I will have to run some tests.

[hiccup]

An option for the plugin to read the replaygain tag for the playing file and automatically adjust the meter gain to compensate.

So for you the meter output does not depend on ReplayGain values in a track?
That's weird, for me it does, and I wished it could be disabled.
This was also discussed earlier and with others, and the request that came from it was to have a pre- vs. post option.
(getting the raw sample data for pre, and post EQ/Volume/plugins audio for the other)

Perhaps this depends on audio settings somehow?
Strange.

edit
I may have interpreted what you wrote differently from what you mean.
Reading it again, it seems that you also would like to avoid ReplayGain values influencing the meter output?
The earlier and existing pre/post request would already allow for that (and I would prefer that solution), but if that can't be done, a separate option setting could also do the trick I guess.

[BoringName]

he earlier and existing pre/post request would already allow for that (and I would prefer that solution), but if that can't be done, a separate option setting could also do the trick I guess.

I can adjust for the replay gain tag values but there doesn't appear to be anything in the Musicbee interface that gives me access to the player equaliser and DSP settings. I can check if they are enabled but I can't read any values.

[Bee-liever]

This was also discussed earlier and with others, and the request that came from it was to have a pre- vs. post option.
(getting the raw sample data for pre, and post EQ/Volume/plugins audio for the other)

Would the new API call GetPCMRawData(float*, int) here, allow for this?

[BoringName]

Would the new API call GetPCMRawData(float*, int) here, allow for this?

I did already post about that but it appears that post got removed when the website was having issues a while back.

Two issues.
1. My plugin is written in C# and from the chat in that thread, and the fact it's using a pointer(float*) in that call,  the api call is for C++. That might be worked around but the main issue is point 2.
2. Pretty sure all that PCM stuff is beyond me. Or maybe more accurately, I'm not interested in the many rabbit holes I'll have to go down to figure it out.

[hiccup]

I noticed a minor sort of light halo around LEDs.
I had the leds on a completely transparent background, so I thought to place a thin bar behind them in the same colour as the VU meter background, so the LEDs themselves are not transparent anymore.

But the halo remains, but now shows the contours of the thin bar containing the LEDs.

Here's what it looks like:


Here is a skin that demonstrates this.

- - -

edit
Noticing something else:

Is MaxLevel being read properly?
Using this same skin, it currently has MaxLevel at 6.
And the needle is properly traveling to the MaxAngle position on a 6dB signal.

Now when I change MaxLevel to 5, and leave the MaxAngle as-is, I would expect the needle to travel to the MaxAngle position on a 5 dB signal.
But it doesn't. It stops before that, and it's still a 6 dB signal that will end up at MaxAngle.

I have an itch that I can't scratch that I'm doing something stupid and overlooking something simple. But I thought to share this potato while it's hot anyway.

[BoringName]

I noticed a minor sort of light halo around LEDs.

Welcome to the bane of my existence when making 3DBee - Alpha blending.

Without writing a war and peace novel. OpenGL averages out the alpha between the existing image (L_0.png) and the image been drawn on top of it (L_3.png). There is some stupid quirk where edges get treated like they are half transparent. It's something to do with the scaling because it can't always use full pixels so it approximates it with surrounding pixels. There are different methods for blending that will fix your issue but they cause issues in other transparent areas like the shadows on your needles. Some colour combinations are worse than others.

This is how I fixed your issue.
- Open the LED image in Paint.Net
- Used the colour picker to get the dark grey colour
- Set the alpha to around half. If you set it to zero at this point the next step won't actually do anything
- Use the paint bucket to fill the transparent area.
- Without clicking anything, adjust the alpha slider on the colour panel to zero. You should see the transparent area you just filled with the paint bucket go clear again.

Save the file. If you open it again and use the colour picker on the transparent area, you will see the RGB values are set to 31 and the alpha will be 8. For whatever reason it won't save as zero.

For me this gets rid of the outline on the LEDs and I can't see any effect from the alpha being 8 for the rest of the image. Your eyes are probably better than mine though.... I believe this fixes it because transparent areas are treated as rgba(0,0,0,0) when it's doing the blending which is white. But we just changed the transparent area to (31,31,31,8) which is the same colour as the edge which stops it making the edge a lighter colour when approximating the pixels - That's just my theory.

Is MaxLevel being read properly?

No. That seems to have dropped off my to do list. I've stuck it back on there. I thought I'd already implemented it when I stopped the needle going past the max angle on the meter but I obviously didn't.

[BoringName]

2. Pretty sure all that PCM stuff is beyond me. Or maybe more accurately, I'm not interested in the many rabbit holes I'll have to go down to figure it out.

I lied again. Steven helped out with the C#/C++ issue and the PCM stuff wasn't as complicated as I thought it would be. Just a bit of wizardry to separate the channels.

Just waiting on some clarification on where in the chain the raw data comes from. It seems to be post track tags and pre Equaliser & DSP. I can adjust for the Replay_Gain_track tags but I cant adjust for RVAD tags.

Actually realised that makes sense so the question is. Just to start a debate, whats the consensus (or lack of)  on the different options.

Normal mode - displayed levels include all tag adjustments and gains from EQ\plugins etc...
Raw mode - displayed levels exclude all tag adjustments and gains from EQ\plugins.

Is there anyone that wants a mode where tags are included but not the EQ\Plugins? Note- at this stage I can't make adjustments for RVAD tags. So really I'm just asking about the replay_gain tag.

[hiccup]

Without writing a war and peace novel. OpenGL averages out the alpha between the existing image (L_0.png) and the image been drawn on top of it (L_3.png).

(using Photoshop myself) I added a 1 px. border around the LED bar with its transparency set to 1%.
That solves the issue completely.

Is MaxLevel being read properly?

No. That seems to have dropped off my to do list. I've stuck it back on there. I thought I'd already implemented it when I stopped the needle going past the max angle on the meter but I obviously didn't.

Thanks in advance.
That'll be a great opportunity for me to re-align all my VU meter skins ;-)

[hiccup]

I can adjust for the Replay_Gain_track tags but I cant adjust for RVAD tags.

I'm wondering how important that is.
I can be wrong, but my guess would be that the vast majority of people that care about loudness are using ReplayGain, and not many are using that RVAD slider on a per track basis.

edit
And I believe other formats than mp3 such as FLAC, OPUS, APE, m4a etc. don't do anything with such a tag?
Not 100% sure though.

[hiccup]

Actually realised that makes sense so the question is. Just to start a debate, whats the consensus (or lack of)  on the different options.

Normal mode - displayed levels include all tag adjustments and gains from EQ\plugins etc...
Raw mode - displayed levels exclude all tag adjustments and gains from EQ\plugins.

Is there anyone that wants a mode where tags are included but not the EQ\Plugins?

If you accomplish getting either the pre (raw) audio, or the post audio stream (the stream that ends up at the speakers/headphones), will there be any reason to additionally consider using tag information?

[BoringName]

If you accomplish getting either the pre (raw) audio, or the post audio stream (the stream that ends up at the speakers/headphones), will there be any reason to additionally consider using tag information?

Well I thought post values would have been enough but clearly some users want pre values. I'm not invested in it all enough to make the decisions as I don't have enough info on what's important and what isn't. My partner is the music buff and she doesn't care about that stuff either. I like music but she does all the curating, I just listen to whatever she is playing. Her computer is connected to our home theater system and it all sounds great without needing any volume modification.

[hiccup]

Her computer is connected to our home theater system and it all sounds great without needing any volume modification.

Then I am guessing you are not having some more eclectic genre playlists that can randomly shuffle between Satie and Meshuggah?

Without ReplayGain, I would either have been deaf by now, or evicted due to complaints from neighbours.

[voodoopunk]

Just to stick my oar in, I manage to go from Sakura Gakuin to Agathocles without any need for volume modification. Just one giant auto playlist that shuffles everything from Sakamoto to Dead Kennedys.

Sorry for the interruption, back to the VUMeter Plugin.

[hiccup]

A couple of requests and suggestions that have been in the back of my mind.
Obviously, feel free to place them low on your to-do-list.
(as long as they are above that silly garage stuff ;-)

1.  'use skin colour'

When using 'Use skin colour', I notice some colouring that doesn't really work well.
It's not blending in perfectly with the surrounding area where I have the VU meter.
For me it's in the right sidebar, where I am guessing many users will place it. (or the left sidebar, for some confused English, Japanese or Australian drivers users)

It looks like the plugin currently takes the colour from "Panel.ChildBody.Default".
I think it would be better if it took it from "TrackInfoPanel.Default".
(these are skinning terminologies, MusicBee's API may have different wordings or options for this)
 


This would look a lot better:



2. bar-type VU meters

A VU meter skin like this can currently not be accomplished:



The reason being it requires the needles to have a width that exceeds the size of the '0' background images, which currently is not allowed for.

I'm not sure what the best solution would be, but here are two ideas:

1. allow the needle to have a length wider (or higher in case of vertical meters) than the L_0/R_0 images. (this already seems to work for L_3/R_3 LEDs)
2. add a new option to have the left and right meters showing on top of eachother instead of only side-by-side. (which is how foobar2000 solves this)

Personally I would prefer a solution like #1, since it would avoid adding yet another option to the VUMeter option list. (yep, still a believer in 'less is more' ;-)


3. prevent needles from displaying outside the designated VU meter area.
This came up before, but I thought to revive it. Also because it relates to the previous request/suggestion.


4. allow subfolders for VU meter skins
This is an existing request you already said you would give some thought.
Just repeating it here to keep things together a bit. (and because I would appreciate it a lot)


5. minimum duration of LEDs lighting up.
Not sure if this is worth much consideration, but I thought to mention it while at it.
LEDs are working great and are very responsive. Responsive to the extend that you can sometimes hardly see them lighting up.
If possible, a minimum 'lights on' duration could solve that.
Not sure about how long, maybe something around 0.3 seconds?


6.


Hm, I can't think of a 6th suggestion/request.
Which is probably an indication of how great this plugin is functioning by now.
This has become better and more fun than I could ever expect or hope for.

And it really helps to add some character to The Bee.