VUMeter Plugin

[hiccup]

Just making sure you installed the new MusicBeeBass.dll because that's different to the straight bass.dll file.

Yes.
It's the one that is included in the latest MB patch 3.6.9042 update, right?

Also,
What's interesting, the needle now responds moments before the audio playing.
While I thought that wouldn't be possible it's clearly the case.
So maybe it's now possible to fine-tune the audio/video sync so it's neither leading nor trailing the audio?
That would be a relevant and substantial improvement.

[hiccup]

I really don't want to be delving in to skin stuff for the sake of one colour. I was hoping I could just grab a modified foreground colour on one of the elements I can retrieve and then users could just set that colour in their skin.xml to whatever they wanted. But it seems the modified element state doesn't work.

Since nobody (but me) has specified in what location he is or wants to be using the VU meter, I have to do some guessing.

These are probably the most likely positions:


These would require getting the bg values of:

1
"Panel.ChildBody.Default"

2
"Content[Artwork].Body.Default"
(Album Covers view)
"Content[TrackDetail].Body.Default"
(Album and Tracks view)

3
"ElementPanel.Default"

Also, I think the Now Playing panel would be a good view to be able to have the VU meter in.
That's currently not possible, but anticipating on a request for that to happen:

4 Now Playing
"NowPlayingList[TrackDetail].Default"

---

If you are reluctant to have the option to choose between these colours, perhaps another approach might be to avoid these borders showing up to begin with by having the VU meter panel dynamically adjust its height to the height of the VU meter's background image?
(not sure if that's even possible)

I really hope you'll be able to figure something out, since it's just not looking good with a mismatching background colour, and the need to very precisely drag the panel to a specific size to hide it for every other VU meter is no fun.

edit
Or, if I am the only one that cares about this, have it using "ElementPanel.Default" as the default colour, and I'll never bother you again about it…

[BoringName]

Yes.
It's the one that is included in the latest MB patch 3.6.9042 update, right?

Correct.

Also,
What's interesting, the needle now responds moments before the audio playing.
While I thought that wouldn't be possible it's clearly the case.
So maybe it's now possible to fine-tune the audio/video sync so it's neither leading nor trailing the audio?
That would be a relevant and substantial improvement.

I noticed that today as well. A lot of the time when I'm testing I have the volume right down because the test tones get monotonous. I've got the player controls element setup to show a wave bar and the VUMeter was reacting before the peaks in the wavebar. I'll have a play around and see if I can get it to sync up with the audio.

edit: If this delay is the time it take for the audio device to receive the audio and process it that could make it hardware specific.... I might have to re-purpose the sample slider to a sync slider....

Or, if I am the only one that cares about this, have it using "ElementPanel.Default" as the default colour, and I'll never bother you again about it…

I'll leave the 3 main colours there and add a custom option that opens a colour picker so the user can enter whatever color they want. Probably easier than stuffing around with skin elements, for me anyway.

[hiccup]

I'll leave the 3 main colours there and add a custom option that opens a colour picker so the user can enter whatever color they want. Probably easier than stuffing around with skin elements, for me anyway.

Yeah that might work.
Still, it's a lot of work for you, and adds complexity for the user.

An ideal solution would probably be if the plugin panel would take the bg colour of the panel that is right above it.
But there probably isn't an API available for that?

[hiccup]

Would it be possible to have resizing the VU meter working like this?:
(never cropping the meter)



It would be more convenient, and then the current option for "Lock Aspect to Y Axis" could probably be removed?
 

[BoringName]

Still, it's a lot of work for you, and adds complexity for the user.

An ideal solution would probably be if the plugin panel would take the bg colour of the panel that is right above it.
But there probably isn't an API available for that?

Already added a custom colour option with the ability to save 16 custom colours.

Ideal until the next person says they would prefer it take the bg colour from the panel underneath it. Maybe I'm wrong but I would think a very large percentage of users would set it how they want it and leave it alone. Maybe changing it occasionally for something different. While messing around setting a custom colour might be an inconvenience, it's not a regularly thing.

Would it be possible to have resizing the VU meter working like this?:

If I was starting from scratch I would do it that way. I didn't think far enough ahead on the possibility users would want margins around it to fit a certain space and also due to my assumption above that a lot of users would be set and forget. I just did enough to get it working and have tacked on changes since which makes it hard to implement that kind of resizing now. With work required to add a vertical option it might be worth doing both at once and cleaning up the code a bit.

[hiccup]

I just did enough to get it working and have tacked on changes since which makes it hard to implement that kind of resizing now. With work required to add a vertical option it might be worth doing both at once and cleaning up the code a bit.

Thanks for explaining and considering.
Just to make sure we are on the same page, I don't suggest "adding  a vertical option".
My suggestion would be to make this default behaviour and get rid of the existing "Lock Aspect to Y Axis" option.

Also, I don't think many users would have a need for using the bg colour of the panel below the meter instead of the one above it.
(the black bars are showing at the top of the meter, not at the bottom)
But if the meter is placed on top of all other panels, then it should probably take the colour of the one below it.

I still think this would be a (close to) ideal solution and it would both improve the user experience and help in trying to keep the options list lean and mean.

But currently it's probably not even possible, since it would require two API's, one for getting the bg of the panel above and one for the one below.
And I am guessing those don't exist at the moment.

[BoringName]

Thanks for explaining and considering.
Just to make sure we are on the same page, I don't suggest "adding  a vertical option".
My suggestion would be to make this default behaviour and get rid of the existing "Lock Aspect to Y Axis" option.

I was referring to an option to place the meters on top of each other rather than side by side.

Also, I don't think many users would have a need for using the bg colour of the panel below the meter instead of the one above it.
(the black bars are showing at the top of the meter, not at the bottom)
But if the meter is placed on top of all other panels, then it should probably take the colour of the one below it.

I was just throwing an example out there of what could happen. Everyone has different ideas on what's best. Although you're probably right in this instance but as you have already suggested, I don't believe this is currently possible.

How many skins would it actually effect? The skin I'm using, Track Information just inherits from ChildBody.Default which isn't an issue.

[hiccup]

Already added a custom colour option with the ability to save 16 custom colours.

Ok, but if the skinning elements that I listed before would be used, I believe all situations would be covered, and there would only need to be 5 pre-configured colouring options. And most users could probably select one and never have the need for changing it to another one.
That seems much simpler to me.
(for the end-user, maybe not for you and/or Steven)

How many skins would it actually effect? The skin I'm using, Track Information just inherits from ChildBody.Default which isn't an issue.

It's just that my proposed solution would erase any need for guessing or making assumptions on unknown variables such as:

- what skins users are using
- how frequently users change skins
- at what location users place the VU meter
- how often users change that location

It would just work.

I'll let this rest now, I don't have much more to contribute to this.

[sveakul]

Hi BoringName, I don't mean to pester you, but I was wondering if you had changed or updated 1.7 since hiccup made this comment about it:  https://getmusicbee.com/forum/index.php?topic=41692.msg228441#msg228441

I've been using 1.6 with good results and didn't want to update if there are still visually obvious errors in the meter response.  Thanks a lot!

[BoringName]

Hi BoringName, I don't mean to pester you, but I was wondering if you had changed or updated 1.7 since hiccup made this comment about it:  https://getmusicbee.com/forum/index.php?topic=41692.msg228441#msg228441

I've been using 1.6 with good results and didn't want to update if there are still visually obvious errors in the meter response.  Thanks a lot!

I haven't updated 1.7 since my last post mentioning it. I just made it back to how it was at initial release of that version with a small fix. I wont do that kind of change again as it just causes too much confusion. I really should have made any changes something like 1.7.1.

1.7 still has the issue Hiccup mentioned. The meter is ahead of the music by a considerable amount. I've added an option in the next version to manually set a delay but I haven't done a lot of testing with it yet. If you're happy with 1.6, I'd stick with that for now. Despite my previous comments, I'll post another version before I dive into any major changes.

[BoringName]

I've created a separate little program that opens foobar bin files. It grabs the background image and renders the needle position for all 1024 frames which I can cycle through. I haven't got the LED done yet but I've found where the pixel data is stored for those, I just need to find the offsets to render them correctly.

I know which frame needs to be displayed when the level is at zero so I can extrapolate some of the movement out but I haven't found any other data yet detailing anything like min/max levels etc...

So at this stage, bin files without LED's can be made to work but won't be calibrated yet. I don't think the LED's should be too hard to nut out.

[sveakul]

Sounds great BoringName, I'm amazed at the speed you have in figuring out/turning out this stuff!!  Please keep us informed on the development.  Foobar just went "public" on oops's new 32/64-bit beta release of the old foo_vis_vumeter to much acclaim.

If you continue work on this I would encourage you to include a way to adjust any option values (sensitivity, decay, rise, etc) by using keyboard up/down arrow keys with a function key, or a simple slider GUI, as opposed to the mouse wheel.  This is because wheels get less precise with age and can skip or fail to change values.

[BoringName]

Sounds great BoringName, I'm amazed at the speed you have in figuring out/turning out this stuff!!  Please keep us informed on the development.  Foobar just went "public" on oops's new 32/64-bit beta release of the old foo_vis_vumeter to much acclaim.

If you continue work on this I would encourage you to include a way to adjust any option values (sensitivity, decay, rise, etc) by using keyboard up/down arrow keys with a function key, or a simple slider GUI, as opposed to the mouse wheel.  This is because wheels get less precise with age and can skip or fail to change values.

oops deserves 100% credit for that. I might have worked out how to get the background image eventually but there is no chance in hell I ever would have figured out the offsets for drawing the needle. That was next level crazy. Messing with data at a binary level wasn't something I thought I would be doing 2 weeks ago.

I can add keyboard shortcuts but I'm not sure a dodgy mouse wheel is justification for doing it, probably better you get a new mouse if that's happening. The only thing that's using the wheel is the DB Offset and it shows the value on the tooltip so you can see if the mousewheel worked or not.

[Viola]

Just don't works on my MusicBee. I use the portable version and I've tried to install your plugin with MusicBee install method and manually and does't work. I see the meeter but doesn't move when I play a song.