VUMeter Plugin

[hiccup]

Looks like perhaps some other tool or program is keeping something hostage until you restart Windows completely.

Possible, but I think unlikely as my PC reboots automatically once every 24 hours. So any hostage taking is (or should be) removed at two in the morning.

Ok, but you are updating the plugin while the computer is on, not when it's off?
So when it's on, the alleged culprit software will be running?
Perhaps it's some AV software?

[phred]

Ok, but you are updating the plugin while the computer is on, not when it's off?

I tried to update the plugin when the computer was off, but nothing happened.  :-)

So when it's on, the alleged culprit software will be running?
Perhaps it's some AV software?

Perhaps. There's nothing in the processes that looks unusual. I've got ESET running a full memory and disc scan now. It'll take a while. I'll report back.

[hiccup]

I tried to update the plugin when the computer was off, but nothing happened.  :-)

Try using smaller magnets. (assuming you're not using an SSD)

Perhaps. There's nothing in the processes that looks unusual. I've got ESET running a full memory and disc scan now. It'll take a while. I'll report back.

It doesn't necessarily have to be related to some virus suspicion.
Other software could also 'have an interest' in these files.
Similar to how iTunes or WMP can have an affect or grasp on audio files when not even purposely told to do so.
It could even be something like back-up software running but not doing much at that time.

[phred]

Try using smaller magnets. (assuming you're not using an SSD)

I did but the stuck to my head.

It doesn't necessarily have to be related to some virus suspicion.

Which tuned up clean. I add two new VU skins and there seems to be no problem, so I have no choice but to sit and wait to see if anything odd happens again. My PC runs 24/7 with an auto-reboot during the overnight. But it's been turned off during my absence so maybe it was just getting used to being power up again.  ¯\_(ツ)_/¯

[BoringName]

Have you been testing this on a specific skin that behaved dull without any boost?

Not going to lie, I hardly tested anything. There are so many different aspects now that testing everything just takes forever and I always seem to miss things anyway so I dialed it back. It's the lazy approach but in terms of my time it's easier to wait for someone to say somethings wrong and I just release a fix than spending hours running through the same old boring tests.

What I did for the curve adjustment is just look at a few meters while playing a song and noted down the min value the needle regularly dropped to. Then I played the same song again after altering the curve adjustment and checked the min value after the change. From the limited testing I did, setting a higher curve adjustment lowered the minimum value. ie) the needle had a wider range of motion. The curve still ends up at zero for a peak value of 1.0 so the needle behaviour shouldn't change too much at the top end but in lower parts of the track it will swing over a bit more. I expect you might need to add a point or two to the rise/fall settings the higher you set the curve adjustment so the needle can swing a bit more easily if that makes sense....

Here's the settings file in case it's helpful

I need to clean up some of those settings, they are not all in use.

I know you have solved your problem so this isn't really relevant to you but just for others benefit, when VUmeter starts up, it looks for the VUSkins folder in AppData\Roaming\Musicbee\Plugins\VUMeter and then the app startup folder\Plugins\VUMeter. Whichever it finds first it will go with. I haven't set it up to save this path so it does this check everytime it starts up. So if you're running the installed version and a portable version and you have skins in both locations, it will go with the appdata folder.

Also something I should probably change is when you uninstall the plugin it will delete the VUSkins folder and all the skins inside it. At least the appdata one anyway, I'm not sure if it deletes it out of the plugin folder when running the portable version. I got caught out by that and had to download a whole bunch of skins again >.<

[hiccup]

I am wondering about the 'centre x axis' and 'centre y axis' options.
Wouldn't it be enough if the meter is always centered in the middle of the panel?
(using either the largest horizontal or vertical space available, as it now does)
Why or when would one want to use these two options?

---

Could you please briefly remind me what 'Suppress INI checks' does?
I think you have explained that earlier, but I can't find it at the moment.

---

There is pretty much only one aspect left that I am still unsatisfied with, and that is the background colour of the panel not (always) matching the location where the meter is placed.
I posted a Wishlist suggestion that I think could solve that here, but neither Steven nor any plugin developer has responded to it, so perhaps that's not a good or valid suggestion.

Two other ideas that I believe could solve it are:
- have an actual colour picker in the plugin, so that you can simply click on a part of MusicBee's panel to set the background colour for the meter
- have the plugin check for the border colour of a skin and use that for background. (I believe the (original) foobar2000 plugin does that)

But here is another idea that I think could solve it that would also have another large benefit:

How about allowing for having the skin file accompanied by an .ini file that contains the preferred settings for that skin?
It would look something like this:

[What I did for the curve adjustment is…

Ok, thanks for explaining.
Since I (still) don't have some 'problem' skins to test this on, I will assume that it is doing what is supposed to do and will now shut-up about it ;-)

[sveakul]

Could you please briefly remind me what 'Suppress INI checks' does?
I think you have explained that earlier, but I can't find it at the moment

The change list from version 1.4 includes, "New option to suppress duplicate value messages with LVU skins"--if that's it, the menu wording needs to be made more clear as to what that actually means.

[BoringName]

I am wondering about the 'centre x axis' and 'centre y axis' options.
Wouldn't it be enough if the meter is always centered in the middle of the panel?

Initially it was always centered on the X axis but sat at the bottom of the panel for the Y axis, when I added the option to center it on the Y axis I added the X axis option to keep them consistent. Personally I can't imagine too many people will uncheck the X axis but I can imagine some users may want the meter to sit at the bottom of the panel for certain layouts. I might be wrong but I don't want to remove that setting yet.

Could you please briefly remind me what 'Suppress INI checks' does?

As already mentioned, it's just a check for duplicate values in the ini file. I expect most meters will work just fine even with duplicate values but notifying users of possible issues seemed like a good idea at the time. I've only come across 2 so far with duplicate values but I haven't tested a great deal of LVU meters as there isn't much that can go wrong with them. I could probably get rid of that setting.

I posted a Wishlist suggestion that I think could solve that here, but neither Steven nor any plugin developer has responded to it, so perhaps that's not a good or valid suggestion.

Not much I can do there really

Two other ideas that I believe could solve it are:
- have an actual colour picker in the plugin, so that you can simply click on a part of MusicBee's panel to set the background colour for the meter
- have the plugin check for the border colour of a skin and use that for background. (I believe the (original) foobar2000 plugin does that)

1. It is possible to get the pixel colour under the mouse but I don't know if I can do that when the mouse is not over the panel VUMeter is in. I'll test it out.
2. I think that might cause some inconsistent results.

How about allowing for having the skin file accompanied by an .ini file that contains the preferred settings for that skin?
It would look something like this:

Well AIMP and LVU already have ini files. Checking for an associated ini file with foobar .bin files wouldn't be a problem. But I'm a bit hesitant to automatically adjust settings unless they pertain to the layout of the meter. Eg) single meter mode for LVU skins or meters that require vertical display. I don't want to be automatically changing the LED peak settings or anything in the Needle Action sub menu.

[hiccup]

Here are my "Yeah but, no but's…"

Initially it was always centered on the X axis but sat at the bottom of the panel for the Y axis, when I added the option to center it on the Y axis I added the X axis option to keep them consistent. Personally I can't imagine too many people will uncheck the X axis but I can imagine some users may want the meter to sit at the bottom of the panel for certain layouts. I might be wrong but I don't want to remove that setting yet.

When the panel is wider than the proportions of the skin, it will be centered vertically anyway.
If the panel is higher than the skin, the default is already that the skin is anchored to the bottom.
So for as far I can imagine it would be perfectly fine to remove these option settings.

Not much I can do there really

Now you can ;-)

Well AIMP and LVU already have ini files. Checking for an associated ini file with foobar .bin files wouldn't be a problem. But I'm a bit hesitant to automatically adjust settings unless they pertain to the layout of the meter. Eg) single meter mode for LVU skins or meters that require vertical display. I don't want to be automatically changing the LED peak settings or anything in the Needle Action sub menu.

Fair enough, but:

AIMP .ini's don't contain parameters for 'horizontal vs. vertical', single meter vs. dual meter, background colour, curve adjustment, LED 'curved' vs. peak, etc.
So I don't think there would be any conflict there?
If it is about the .ini extension that might pose a problem because AIMP skins already contain such an .ini file in the .zip, then .txt or .xml could be used instead of .ini?

I really hope you will consider adding this.
It would be a significant improvement in the sense that then skins (that have such an additional ini file) will always display exactly as intended by the creator of the skin.
Without the user needing to delve into the settings menu to find and make adjustments for it to have the skin displaying and functioning as intended.
And a user could also very easily create or modify such a settings file himself, so he won't have to repeat changing any option setting every time he changes skins.

About your worry it possibly changing default settings for other skins:
When a skin doesn't have an accompanying .ini file, the plugin could resort to the setting that was last used before a skin with such an .ini file was selected?

I hope this takes away any possible concerns or reservations?
 

[BoringName]

If the panel is higher than the skin, the default is already that the skin is anchored to the bottom.
So for as far I can imagine it would be perfectly fine to remove these option settings.

But if I removed the options it wouldn't be anchored to the bottom anymore, it would be centered. You don't think some users might have a layout where they would prefer it anchored to the bottom?

Now you can ;-)

I'll add those to the background colour sub menu.

AIMP .ini's don't contain parameters for 'horizontal vs. vertical', single meter vs. dual meter, background colour, curve adjustment, LED 'curved' vs. peak, etc.
So I don't think there would be any conflict there?
If it is about the .ini extension that might pose a problem because AIMP skins already contain such an .ini file in the .zip, then .txt or .xml could be used instead of .ini?

I meant to imply they already have an INI file that you could add the options to. I don't want to messing around with multiple ini files. So for AIMP/LVU skins I could look for a "Layout" category and grab any options listed under that category. For foobar skins it could just be an ini file with the same name.  eg) neutron.bin, neutron.ini

When a skin doesn't have an accompanying .ini file, the plugin could resort to the setting that was last used before a skin with such an .ini file was selected?

I expect I will remove the "Suppress INI messages" and "override AIMP settings" and create a new setting "Override INI Settings". When unchecked the VUmeter will use any settings found in the INI files. If the settings are missing or "Override INI settings" is checked it will use whatever options have been configured by the user.

[sveakul]

@Boring.Name:  two questions!  A while back you posted an image extractor for BIN files, "BinExtractor.exe."

1.  Could you possibly post a similar tool that would re-import images into the BIN file, overwriting the original image?  The case I'm thinking of is after extracting the images with BinExtractor and making some color changes to them, there is no way to re-import them directly into the BIN.  VUEditor only works with *.vu project files.

2.  Recently a fellow in the Foobar forum bemoaned the inability to extract images from a BIN, solved of course by your BinExtractor.  Would you have any objection if I posted that app there, with the proper credits of course?

Thanks!  The new plugin version 2.1 working fine here by the way, appreciate your efforts.

[BoringName]

@Boring.Name:  two questions!  A while back you posted an image extractor for BIN files, "BinExtractor.exe."

1. I don't think I'll be doing that. But I believe oops is going to release the details on how it all works so other people might get it done. Otherwise you just have to create a new skin in VUEditor or convert it to the AIMP format, unfortunately whichever way you go the needle image will probably need cleaning up.

2. No problem. Just make sure to warn them about how many files clicking export all can create.

[sveakul]

Thanks BoringName for allowing me to share BinExtractor, but after playing with it just now it occurred to me that I don't really know what I'm doing.  I guess I thought it would operate like VUEditor does with *.vu files, allowing component vs. frame extraction.  Hiccup had kindly posted a set of those for me that I used to color parts of his first BIN file, and it was easy to extract the primary component images minus "movement", make changes, then export it as a re-compressed new BIN.  I don't know how he made the *.vu files.  I think I'll just leave all of this to the experts for now!!

[BoringName]

The extractor just extracts the images to PNG files. The vu files are the project files for VU editor, Hiccup can share them with you because he created them. There isn't any VU files for existing BINs unless the original author skin shares them.
It might be possible to reverse engineer the VU files from a BIN but I'm not really interested in doing that. The VUEditor is not that complicated once you play around with a few of the sample VU files provided with it.

New Version - VUMeter2.2.zip

Fix for LVU skins - VUMeter2.2.1.zip

Changes
- Colours for SkinElementPanel and SkinTrackDetailsPanel added to the background colour sub menu.
- Option "Supress INI Messages" removed and no warnings will be given for duplicate settings in the INI file as it doesn't seem to prevent the skin from working.
- Option "Override AIMP settings" removed.
- New option "Use Skin Defaults". When checked this will apply any settings in the ini file listed under the [DEFAULT] section. An example of the available settings -
[DEFAULT]
isVertical=true
bgColour=-16711936 //int equivalent of ARGB. Use a website like This one.
rise=0.03 //same as mobility settings.
fall=0.03
curveAdj=5
singleMeter=false
peakLED=false

This DEFAULT section can be added to the INI files for LVU and AIMP skins. For foobar skins create an INI file with the same name as the skin. eg) Neutron.bin, Neutron.ini. For skins with multiple meters like Grundig 1.bin/Grundig 2.bin, VUMeter will look for an INI file minus the number on the end so make sure to include a space if it exists. eg) Grundig .ini. Or just use the "Save Defaults" button mentioned below.

When Use Skin Defaults is checked, changing any of the settings included in the DEFAULTS section from the right click menu will have no effect on what is displayed but they will change the base settings. Whatever default settings are in the INI file will not be reflected in the right click menu. It will always show the base settings. When Use Skin Defaults is unchecked VUMeter will revert to the base settings.

If the DEFAULT section is missing any settings, they will default to the base settings. If a file contains both MobilityPositve/MobilityNegative and rise/fall values the rise/fall values will be used. For AIMP skins, "Use Skin Defaults" unchecked will use the base rise/fall settings ie) it will have the same effect as having the old "Override AIMP Settings" checked even if there is no [DEFAULT] section in the INI file.

Adding the DEFAULT section to AIMP/LVU INI files shouldn't break those skins for the AIMP player as it should just ignore that section.

New Option "Save Defaults". When clicked this will save the current base settings into the skins INI file or overwrite existing values. For foobar skins it will create an INI file first if one does not exist.

In other news, I'm never going on holidays to the US.

edit: With the background colours. The custom colour section saved from the colour picker is a different format to what is used for the bgColour. It's some legacy crap with microsoft. So don't add a custom colour to the colour picker and then assume the code saved in the XML file will give the same result if copied to the bgColour value. Just use a website like I said. It uses AARRBBGG whereas the colour picker uses 00BBGGRR or something like that. Actually if you add the custom colour from within VUMeter, set it as the background and then click "Save Defaults" it will convert it to the correct format for you, no need for a third party website.

edit: Check "Ignore Replay Gain" as I renamed the setting for this in the code so it will probably uncheck itself after installing the update.

[BoringName]

And in typical fashion, I made a change just before releasing the last version that broke saving the ini file for LVU skins.

Here is a fixed version - VUMeter2.2.1.zip