VUMeter Plugin

[phred]

Could it be your computer being strange again? Maybe it needs a restart.

Was Musicbee playing anything at the time? just to rule out any possible conflicts with other Musicbee functions, what happens if you select the lovebird skin then close musicbee and open it again.

Not only have I done a restart, but over the past four days I reinstalled Windows.
MB was not playing anything at the time.
MB 3.6.9083 P

Based on sveakul's comments, while waiting for Lovebird LED to load, I exited MB and restarted it. After thirty seconds it still hadn't loaded so I exited and reinstalled 2.3 and all is well. Yes, it takes longer for the two Lovebirds to load, but they load. Other meter skins load almost instantly.

[sveakul]

phred : what are your machine specs as far as RAM, processor, and OS?

After starting the PC for the first time today, I went first to MB and started it, with the AIMP skin I happened to be using when it was shutdown, and selected the Lovebird LED skin.  It loaded in about 4 seconds, slightly less than yesterday.  Then I switched to an AIMP skin, and back to Lovebird LED.  Same, loaded in 4-5 seconds.  So I have to say no problem here now, only yesterday after I had just updated the plugin and lovebird stalled out as I described in my last post.

Edit: other plugins in use at startup are LyricsReloaded/Beenius/Museexmatch/LRCLIBee, Classic Spectrum Analyzer,  CoolEdit Nostalgia spectrum analyzer.

[hiccup]

- Foobar skins now use a separate shader which allowed me to optimise some of the foobar draw code. The alpha channel is set to zero for the bin file images and I was having to do stupid workarounds with the main shader I was using.

Is this something that may have an affect on skin creation? Meaning:
- could it influence how (e.g. needle) shadows turn out?
- does this mean that adding a thin transparent border around LEDs is no longer necessary?

[hiccup]

I had to gather some courage to bring up 'needle action' again, considering how good it is by now, and me being fully aware the complexities that had to be overcome to get to this.
So, please consider this to be mainly some observation. If you think you've done all that you can (or are willing to do), feel free to ignore this.

Below a comparison between MusicBee (top) and foobar2000 (bottom).
I most certainly prefer the liveliness of your implementation to the RMS approach of the foobar2000 plugin.
And yet, there is a nice calmness and 'authority' to foobar2000's needle action.

And while in comparison it may come across as 'slow', it is actually faster in responding to 'general' loudness increasements.
It's like an older boxer that seems a bit sluggish, but will still throw the first punch.

What I think is what is still making the MB needle a bit nervous, is that the needle is allowed to move many times back and forth in short amounts of time.
If it would be possible to 'dampen' or restrict the allowed frequency of movements within very short time spans, it might make things look less nervous and jumpy.
But I could imagine this can't be done without also affecting the more global rise and fall times of the needle. Which are good as they are and probably shouldn't be touched.

Anyways, I hope you see what I mean and my observations make some sense to you?

Here's the comparison:

[phred]

phred : what are your machine specs as far as RAM, processor, and OS?

@Sveakul... I'm running Win10 with 16gb RAM and a four core Intel i5-7500 CPU.


Launching MB and VUMeter 2.3, Lovebird LED takes 7 seconds to load. The CPU load is between 15% and 23% with no music playing. It goes up to about 38% with music playing.
With no music playing and VUMeter 2.4 and Lovebird LED being the skin in use when closing MB, CPU load starts at 38% and after a minute settles down to between 18% and 23%. And the skin still has not loaded - after one minute. Attempting to load another skin does not work. The panel window shows that it's loading a skin, but nothing happens. MB is otherwise responsive even to the point of showing the VUMeter context menu. I can select any skin and it won't load.

I've also noticed that with 2.4 -none- of the bin/ini skins load. The only skin that loads is a ZIP skin of SPL Mk2 Phred on the Outlook with Bee. Which is one that I took from hiccup and modified back in the early days of VUMeter.

As stated earlier today, with 2.3 all skins -except- the two Lovebirds load almost instanteously. The Lovebirds take seven seconds.

[sveakul]

Sorry you are still having problems with 2.4!  My OS is WIndows 11 with 32MB of RAM and a I7-13700 processor with 16 cores and 24 thread hyperthreading.  I have a feeling your processor might not be up to it.  BUT, you can load 'em all with 2.3.1, so I don't know, may have something to do with the new separate thread for the BIN skins but now I'm guessing.  Nothing wrong with sticking with 2.3.1 when that gives you fast access to all the skin formats.

Hiccup your comparison with Foobar vs. MusicBee on the Lovebird LED meter is a tough call, as you said.  The action with Foobar IS smoother, but I do favor a more "active" needle/LED movement and the MB one has that.  Neither one is really "less" than the other, just different approaches that by definition should have SOME visual difference when Foobar is ignoring your custom *.ini file.  If the MB one on top was "jerki-er" than it is now, I would choose Foobar, but it's not, it's at the "active approaching jerky but not REACHING jerky" level.  I would just stick with designing around the BoringName plugin as far as your own preferences and let Foobar do its own thing.

[phred]

Sorry you are still having problems with 2.4!  My OS is WIndows 11 with 32MB of RAM and a I7-13700 processor with 16 cores and 24 thread hyperthreading.  I have a feeling your processor might not be up to it.  BUT, you can load 'em all with 2.3.1, so I don't know, may have something to do with the new separate thread for the BIN skins but now I'm guessing.  Nothing wrong with sticking with 2.3.1 when that gives you fast access to all the skin formats.

Yup. 2.3.1 works as expected. I've been saying "2.3" in the past few replies, but it was actually 2.3.1. Which I'll keep until BoringName issues the next release and I'll try again.

[BoringName]

Is this something that may have an affect on skin creation? Meaning:
- could it influence how (e.g. needle) shadows turn out?
- does this mean that adding a thin transparent border around LEDs is no longer necessary?

Zero effect. Because the alpha channel is set to zero in the foobar skins, I had to do a workaround to set it to 1.0 (255) manually when a foobar skin was processed by the existing shader otherwise the window would be blank. I just created a new shader for foobar skins that assumes the alpha channel is always 1.0 (255). I need to keep the existing shader for the other skins because they use varying alpha values when drawing the different layers. Foobar skins start with the background image and then the locations of the needle and LED pixels are replaced. There is no "layering" or need for alpha values.

It just allowed me to neaten the code up a bit and reduce some of the process involved. From an end user standpoint you shouldn't notice any difference. There should be slightly less CPU usage but I highly doubt it would be noticeable at all.

I'll review the needle movement and see if there is any way to dampen it without effecting the overall movement. If I do make any changes there I'll just send you a test version and not release it publicly unless you agree it improves on the current version. For what it's worth, I don't like the foobar movement in that gif, it looks too smoothed out. But I'm not really an end user for this thing.

So at this point are we 3-1 on the foobar skins loading for people in 2.4? I was on an older version of Musicbee but updating to the latest still loads fine for me.

I'm on a Ryzen 5 7600. CPU usage fluctuates between 0.9%-2.2% for me. That's just what musicbee is using, not total usage.

The lovebird skin loads in quarter of the time in Foobar so there is probably some room for improvement in my loading code.

Not really sure why using a separate thread would be causing any problems but I'll see what I can find out. It's going to be pretty hard for me to test when I can't reproduce the problem....

Edit: I just extracted Lovebird and put .bin on the end so it's effectively a skin with no compression and it loaded almost instantly. So the loading issue is with the compression library I'm using. Not sure if I will be able to do much about that.

[hiccup]

Edit: I just extracted Lovebird and put .bin on the end so it's effectively a skin with no compression and it loaded almost instantly. So the loading issue is with the compression library I'm using. Not sure if I will be able to do much about that.

I've been using BZIP2 for compression.
Mainly because I think I read Oops saying it would be the preferred option.
I just tried using LZMA on a Lovebird skin, and on my system it then loads in under a second.
(where it is 4 seconds for the BZIP2 version)

So, what do you think? Use LZMA from now on?

[BoringName]

I've spent most of the afternoon trying out different Zip libraries and they all have the same problem of only extracting the first block from Bzip2 files. Because of this if a Bin file contains a left and right meter, the right meter doesn't get extracted. The library I'm currently using which is slow is the only one that works. The foobar plugin might have more options because he isn't using C#.

So at this stage we are stuck with it being slow but there is a different solution. When creating a skin with the VUEditor, select LZMA as the compression method instead of BZip2. It is substantially faster to decompress in the area of 6x.

edit: Yes, use LZMA. I believe it's the 7-zip format. I think oops prefers BZIP2 as it's easier to determine if the file is compressed or not. The library I'm using for LZMA has no issues distinguishing between LZMA and no compression. You could always just use LZMA and test it with the foobar plugin before releasing it. If it fails in Foobar then use Bzip2.

[hiccup]

You could always just use LZMA and test it with the foobar plugin before releasing it. If it fails in Foobar then use Bzip2.

The LZMA versions load a lot faster in the (original) foobar20000 plugin too.
The new version of the plugin by Oops still makes foobar2000 crash when loading these skins, so no difference there.

I've now updated the Lovebird skin downloads with LZMA versions.

[sveakul]

Stick with those MusicBee optimized LZMA fast loads, might be placebo but even the movement seems optimized now. Like you said oops can deal with Foobar before lunch.

[BoringName]

New version - VUMeter2.4.1.zip

Changes
- Made a change to how the separate thread is configured for Foobar skins.

This is just a change for Phred's benefit to see if it fixes the non loading issue.

If foobar skins are already loading for you, I wouldn't bother upgrading to this version.

[sveakul]

hiccup:  DID you do more tuning on the Lovebird skins besides just changing the compression?  It's not placebo, both DO operate more accurately and smoothly than either of those test gifs.  Quick, responsive but no "jerk."  This is the recipe to use for ALL your skins now.   Of course "use skin defaults" is checked, Event mode, LED use peak, ignore replay gain.   Plugin version 2.4, I'll pass on 2.4.1, the separate thread idea is GOOD.

[BoringName]

hiccup:  DID you do more tuning on the Lovebird skins besides just changing the compression?  It's not placebo, both DO operate more accurately and smoothly than either of those test gifs.  Quick, responsive but no "jerk."  This is the recipe to use for ALL your skins now.   Of course "use skin defaults" is checked, Event mode, LED use peak, ignore replay gain.   Plugin version 2.4, I'll pass on 2.4.1, the separate thread idea is GOOD.

Not sure comparing with GIFs is that reliable as they are running in the browser.

Just to clarify, the only thing running in a separate thread is the loading of the bin file. Once it's loaded, everything is running as it always has done previously so the separate thread change will have zero effect on the movement of the meter.