VUMeter Plugin

[hiccup]

Am I correct that what we called '22' is now (the default) '1'?

I haven't made any changes in that regard. I thought it would be better to wait and see if anyone else had any input on it just in case it's a hardware specific thing. 22 works for me but I'm not a great measuring stick for this kind of thing.

Hm, the brain cells that connect my eyes and ears may be tired. I'll give them a rest for a while.

But for now it seems that I was slightly wrong when I said that '1' works best for event mode.
It then also leads a little bit, so perhaps something like '5' will be better.
I'll test it more precisely after the brain cells have enjoyed their vacation.
And hopefully some other users will provide their specific experiences and opinions on this.

edit
A good track for testing this would be 'Holding Back The Years' by Simply Red.
Nice and clean peaks in the LED bar of the DejaVU Compact Calibrated test version:

[BoringName]

Hm, the brain cells that connect my eyes and ears may be tired. I'll give them a rest for a while.

But for now it seems that I was slightly wrong when I said that '1' works best for event mode.
It then also leads a little bit, so perhaps something like '5' will be better.

That's pretty much the story of my life lately....

And hopefully some other users will provide their specific experiences and opinions on this.

Not holding my breath. But I wouldn't be surprised in the slightest if most people are happy to sit back and go with what you think is best. If you were not involved, VUMeter probably wouldn't have progressed much past version 1.0 and it's all the better for it.

[hiccup]

Not holding my breath. But I wouldn't be surprised in the slightest if most people are happy to sit back and go with what you think is best. If you were not involved, VUMeter probably wouldn't have progressed much past version 1.0 and it's all the better for it.

Thanks for that, and sorry for probably having been a bit pushy about things.
But, you have been able that handle that perfectly. (geniuses being capable of handling chaos)

Besides my gratitude and respect for your work (and persistence and attitude), I would also like to thank kamen and Steven.
Without their efforts and contributions on the audio matter of things this would probably also not have been possible.

[hiccup]

Not holding my breath. But I wouldn't be surprised in the slightest if most people are happy to sit back and go with what you think is best.

Ok, the brain cells that are tasked with audio have come to an agreement with the ones that do visual.

For event mode '5' is perfect.
For non-event mode it's '25'.

[sveakul]

Thanks hiccup for that info.  I've decided to stick with version 8.0 of the plugin, partly because you put so much effort in using RMS as the basis for your calibrated meters that I just don't want to compromise by using "mobility settings averaging" instead.  No shade to you BoringName, but that just seemed like a step back to me after the time you had taken pouring over precision, etc with the meter's development.

I know the BIN meter version is taking a time out right now--a well deserved one!  Is that envisioned as a separate plugin, or as an add-on to the AIMP analog + LVU combo?

[BoringName]

For event mode '5' is perfect.
For non-event mode it's '25'.

Could have sworn this had different values when I looked earlier

Thanks hiccup for that info.  I've decided to stick with version 8.0 of the plugin, partly because you put so much effort in using RMS as the basis for your calibrated meters that I just don't want to compromise by using "mobility settings averaging" instead.  No shade to you BoringName, but that just seemed like a step back to me after the time you had taken pouring over precision, etc with the meter's development.

I know the BIN meter version is taking a time out right now--a well deserved one!  Is that envisioned as a separate plugin, or as an add-on to the AIMP analog + LVU combo?

That's an interesting stance to take. What if I didn't say anything? I'd understand if you said you preferred the movement of one method over the other but it seems you are making a decision because you think there is a difference and not a difference you have witnessed. As long as you like the movement of the meter, does it matter how it gets there? It's still calibrated. Its just a different method of removing the peaks.

For what it's worth, I wasn't using RMS averaging until 1.5 and Hiccup stated very early on they were using a sample no. of one which removed any averaging anyway.

I will be incorporating the foobar skins into the current plugin. I'm just going through the different compression types at the moment.

[sveakul]

That's an interesting stance to take. What if I didn't say anything? I'd understand if you said you preferred the movement of one method over the other but it seems you are making a decision because you think there is a difference and not a difference you have witnessed. As long as you like the movement of the meter, does it matter how it gets there? It's still calibrated. Its just a different method of removing the peaks.

For what it's worth, I wasn't using RMS averaging until 1.5 and Hiccup stated very early on they were using a sample no. of one which removed any averaging anyway.

Don't take this the wrong way please.  It's because you ARE involved enough "to say anything" that I take your original development method as being important.  I'm the kind of person to whom it does matter how/why the needles are moving, as opposed to if I like what I see--I'd rather BELIEVE what I see, in terms of an established audio measurement.  Remember I'm the guy who sweats updates of BASS files nobody else cares about.  The fact that your "LED use Peak" option for LED versions is valuable to me is because that also works with a defined measurement.  If it's just about averaged movement and the subjectivity of what "looks" best, it becomes something different than how I had pictured the original intent.

But, hey, that's just one man's opinion.  I realize it's because of your own decision to spend time on this that we have these meters at all for this player.

[hiccup]

Could have sworn this had different values when I looked earlier

Yes, you may swear. Do you ever get tired of yourself? I do ;-)

I got to the earlier values based on eagle-eying the peak indicators.
But then I focussed on the needles a bit more (which I find more important), and they could use a tiny tweak to make them slightly faster.
(without harming the peak indicators)

I've decided to stick with version 8.0 of the plugin, partly because you put so much effort in using RMS as the basis for your calibrated meters that I just don't want to compromise by using "mobility settings averaging" instead.  No shade to you BoringName, but that just seemed like a step back to me after the time you had taken pouring over precision, etc with the meter's development.

My 3 cents on that:

The only reason for me creating these 'calibrated' versions was for testing purposes, and trying to get my head around all this VU meter and levels stuff.
But the end goal for me was always to have meters that are indicating something that my brain agrees with.
If you like these 'calibrated' versions, make sure to back them up, because there's a good chance I won't maintain them, or even remove them at some point.

I care about:

- the needle being responsive starting at very low volumes (note that many 'professional' meters don't care about that part of the scale at all)
- the needle being allowed to move a bit past the '0 dB' indicator (which is also customary in recording studios)
- the needle making the best possible use of the available space on the scale

Also, 'accurate' is a term that should probably never be used for any VU meter.
It's always some method of averaging and some compromises and design choices.
And there are also many variations on how recording engineers prefer to tune (or calibrate) them.
So that can differ from studio to studio. Or depending on recording pop, classical, spoken word, etc. etc.

The only thing that can come close to being accurate are peak indicators.
So that's why studios use both VU meters and peak meters. They complement each other.

So having (or asking for) a VU meter that indicates peaks doesn't really make much sense.

And what is great about BoringName's implementation is that we can now have both of them in one meter.
The needle doing VU, the peak indicators doing accurate peaks.
As I said before, I don't think either foobar2000 or AIMP can do that?

And when it comes to proof and pudding: comparing the needle action of all three, I personally like BoringName's the best.
So to me we have a winner.

Let's also remember that what we are talking about here is a meter for a consumer audio player.
Not one for a studio recording tool.
Different purposes, different requirements.

[BoringName]

Don't take this the wrong way please.

All good. I think you might be giving me too much credit with the "original development" comment though. I'm 95% winging half this stuff. I didn't even know what RMS averaging was until about 15 minutes before I implemented the formula and it pretty much got replaced immediately. The original averaging method from version 1.0 was just a simple average of the last 10 values and without any mobility settings it was pretty rough.

At this stage I don't intend to change the needle movement barring some very minor tweaks to mobility factoring to address this comment -

But then I focussed on the needles a bit more (which I find more important), and they could use a tiny tweak to make them slightly faster.

I don't plan on adding options for different level averaging like the foobar plugin has. With how the mobility settings work, I doubt it would make any perceivable difference anyway. The dboffset is available to shift where the meter is going.  So moving forward, how it is now is pretty much how it's going to stay when the foobar skins are added.

Also, 'accurate' is a term that should probably never be used for any VU meter.

This is something I keep coming back to. Having the needle point to specific levels while playing a test file is one thing but when the meter is in full swing, it's probably pointing to different places on different machines just because of the difference in hardware before you factor in everything else.

I was tossing up how to do the directory structure method. Load them all on startup or scan the folder and dynamically create the menu as each folder is clicked in the menu. But while typing this I think the later is probably better even if it might be a little slower as it means I can remove the "rescan skins" option.

eg) right click and select Skins. VUMeter scans that folder and creates menu options for any skins or subfolders in that folder. When you click a subfolder option it scans that subfolder and creates menu options etc... etc....

Loading them all on startup might be a problem if someone (not naming names) decides to download every skin on earth. They can be managed better loading each folder dynamically.

[BoringName]

Just a heads up. The next version will support a directory structure for the skins folder. Due to this, the plugin will no longer support unzipped AIMP/LVU skins. So you might want to make sure all your existing skins are zipped and ready to go for the next version. It won't be for a while.

There are a few limitations with the menu and dynamically adding lots of elements as they are not really designed for that purpose. But I don't want to add a file picker dialog because I think a majority of users will only have a few skins and being able quickly select it from the menu is more convenient.

Due to those limitations I would suggest anyone planning on downloading a bunch of skins and placing them in a directory structure in preparation, limit the number of skins per folder to around 40. eg) if you have 60 skin files in a Foobar subfolder, split that to Foobar\1-40, Foobar\41-60 etc...

You can have more than 40 but the menu adds overflow scroll arrows when the menu exceeds a certain size and to put it bluntly, it's really shit to navigate once that happens. Limiting the number of files will also prevent the menu from bogging down when loading items.

I've looked into workarounds to make it more user friendly but nothing really works and/or is really convoluted and I don't think it's worth the effort considering the number of users it will effect.

Of course I could be explaining all this for no reason because no one will download that many skins.....

[hiccup]

Just a heads up. The next version will support a directory structure for the skins folder. Due to this, the plugin will no longer support unzipped AIMP/LVU skins.

I'm almost starting to feel guilty about asking for this feature, seeing that nobody else has ever asked for this.
But then again, besides us three, no-one brings any ideas to the table anyway...

But (I imagine) it's not just a request for myself.
I recall when I very first discovered the existence of VU meters for foobar2000, and then trying to get all the VU meters that existed so I could see them work, compare, and then make some selection of the best ones that I would actually use.
(foobar2000's plugin feature to switch to previous/next skins by clicking both left and right mouse buttons at the same time is really great for this)

I wouldn't be surprised if there are users that now or in the future discover the VU meter feature for MusicBee and begin with hoarding every meter that they can find ;-)
And for VU meter skin developers like me it's also very useful for organising skins by type, test versions, favorites etc.

I am guessing it's going to be something like how MusicBee handles its skin selection menu?

---

I have to admit that I learned to appreciate that in the current version of the plugin, skins don't have to be zipped.
Because when creating/modifying a skin, you can do that pretty much on-the-fly, without the need for zipping each and every iteration.
So I will carefully keep a copy of the current 1.8.2 version for development purposes, and would suggest any (potential) VU meter creator doing the same.

Thanks again for all your work and persistence on this.
 

[BoringName]

I'm almost starting to feel guilty about asking for this feature, seeing that nobody else has ever asked for this.

It will be good for me too with testing, I can group the different types instead of having to rename them like I currently do.

I am guessing it's going to be something like how MusicBee handles its skin selection menu?

Pretty much.

I have to admit that I learned to appreciate that in the current version of the plugin, skins don't have to be zipped.

I had considered trying to keep support for it but I think it will just be a headache dealing with edge cases. How do I determine if a folder should be a subfolder or a skin. Is there an ini file in that folder because it's supposed to be a skin or because the user unzipped a skin there for editing and left it there.

You could probably set up a simple batch file for unzipping/zipping skins to make it easier when editing.

[sveakul]

FWIW I decided to make the jump to 1.8.2 after all, especially as the integration with BIN meters is on the way.  I had to say good-bye to hiccup's package of sine wav tones but somehow I'll make it    .  BTW, I can't recall if "Ignore Replay Gain" is checked by default, but that "tagged" me again until it registered on me, haha..  Anyway, I didn't die, and the AL-65 (calibrated of course!) is looking darn good...  I appreciate that Linear was kept as a movement option, which depending on the meter I sometimes prefer using.  It was just added in the last Foobar plugin update to its selection of Levels options.

BoringName, your continued development of this project is appreciated.  Thanks to you, and to kamen for his sophisticated spectrum analyzer, we finally have some enjoyable and useable visualization for MusicBee.

[voodoopunk]

Thanks to you, and to kamen for his sophisticated spectrum analyzer, we finally have some enjoyable and useable visualization for MusicBee.

Do you guys sit and stare at musicbee while music is playing?

[sveakul]

Thanks to you, and to kamen for his sophisticated spectrum analyzer, we finally have some enjoyable and useable visualization for MusicBee.

Do you guys sit and stare at musicbee while music is playing?

Stare at it, listen to it, read it, tweak settings, all kind of stuff!