Spoiler (click to show/hide)

Quote from: sveakul on 2024-10-18 19:51:28

oops:  I have access via hiccup to the needle components you say you can't find from the BIN meter I posted, if you haven't gotten them yet let me know and I'll post them.  Aren't these "extractable" in some way from the BIN using VUEditor?

Oh, I meant I couldn't get the needles to draw in the right coordinates. Only saw an empty panel. I've found my mistake and fixed it in version 0.2.0. Sorry for not being clear.

Quote from: jistme on 2024-10-18 04:42:45

Wouldn't it be so that if for example the VU meter image is 600 pix wide, using 600 angles would suffice?
Is there a benefit in using more angles than the background image is wide?

There likely isn't that much. There is some interpolation going on, the calculations happen with fractional pixels so there could be some "difference" depending on the interpolation method. Looking at the decompiled version of VUEditor, the maximum image size appears to be 4096 pixels and the maximum frame count is 1024. So, the author is using a 4:1 ratio, much less than 1:1. And the needle isn't always vertical either. And that still appears to be over-spec'd. The VUEditor author has been very clever--when reverse engineering the BIN file format I noticed several of the needle delta array pointers using the same offset. That means that the tool uses the same needle "angle" for several frames if there is no change in the pixel data between adjacent frames. And you can see it even when the frame count is 200 since most panels are not over 1000px wide!

Quote from: 2tec on 2024-10-18 13:52:40

Quote from: ilovefb2k on 2024-10-17 22:10:00

i just asked @oops to have a feature (beat detection) for VU meter (as seen in above post).

Updated version with mostly complete AIMP analog VU meter skin support: 0.2.0

This version went through a large refactor to merge everything but the initial loading and device drawing functionality between the foobar2000 BIN files and the AIMP ZIP files. So, if you decide to try it and see a functionality regression let me know. This is not "current" so manual download and install is necessary.

Quick notes:

• Unfortunately, the needle behavior for the AIMP skins is bad and inaccurate; especially around 0dB. That is likely the next thing I'll work on improving.
• Some skins are transparent at the edges (mainly at the bottom) which makes the needle show through--I've increased the "glass" size by 4 pixels to cover it on some skins. Removing this "edge trim" might not look the best or some elements might overflow. Let me know if you run a skin where it looks bad.
• I added SHIFT and CTRL modifiers for more granular control of the preamplifier gain setting. Use them alongside the mouse wheel to step in hundredths or tenths of a dB, respectively. None-modified mouse wheel steps in unit increments.
• Lasty, if you use a "vertical" stack AIMP skin, there is only 1 layout option: LEFT+RIGHT H. No other options make sense so they are not selectable. Vertical stack means that the left or right channel needle origin in the Y-axis is negative and the opposite channel's is positive.

Quote from: jistme on 2024-10-18 04:42:45

Wouldn't it be so that if for example the VU meter image is 600 pix wide, using 600 angles would suffice?
Is there a benefit in using more angles than the background image is wide?

There likely isn't that much. There is some interpolation going on, the calculations happen with fractional pixels so there could be some "difference" depending on the interpolation method. Looking at the decompiled version of VUEditor, the maximum image size appears to be 4096 pixels and the maximum frame count is 1024. So, the author is using a 4:1 ratio, much less than 1:1. And the needle isn't always vertical either. And that still appears to be over-spec'd. The VUEditor author has been very clever--when reverse engineering the BIN file format I noticed several of the needle delta array pointers using the same offset. That means that the tool uses the same needle "angle" for several frames if there is no change in the pixel data between adjacent frames. And you can see it even when the frame count is 200 since most panels are not over 1000px wide!

"DejaVU Compact Calibrated Bright"
I like it better than "DejaVU Compact Calibrated".
The way the needle moves is really cool.

I've been looking for an AIMP Analog VU Meter skin that works with the current version (v2.0 beta) and I don't have enough time.

AL-65 Calibrated.zip:
Cute and calm

DejaVU Compact LED Calibrated Elemental-mod.zip
This needle movement is also cool.

How do you know so much? hahaha...

It's not me I just know where the people who DO, post them, haha..  the MusicBee forum just went through an extended period of discussion with the development of its VUmeter Plugin that allows use of both AIMP Analog and AIMP "LVU" meters.  Its developer BoringName and main contributor hiccup did some extensive modifications to the *.ini files to allow more precise and accurate meter movement of the dowloaded as-is meters within the plugin's interface and some skin work also.  Some examples are downloadable in the thread here: https://getmusicbee.com/forum/index.php?topic=41696.0 .  The MusicBee plugin is awaiting its own BIN-compatibility soon.

• The default sample window in the original VU meter component is 200ms. That is the backlog (i.e., sample_window) it uses. This number has by far the most influence on the needle movement. This is because after summing all of the samples and averaging over the window size, it tends to prevent very abrupt movements. In other words, the larger the window size the less needle movement from frame-to-frame. From playing with the original VU meter, this tends to hold true.
• I added rise and decay factor multipliers to further control these properties given that the sample window can be made very small, but they should only be used to fine tune. Other than what happens when the music stops (due to how foobar2000 provides audio data), the needle movement properties can be controlled solely by the sample window size.
• One feature I added, is that when paused, the needle stops in place but stopping allows it to decay to the resting position. This behavior is different from the original component.
• The rise and fall constant defaults come directly from the transfer function of the SPICE netlist simulation of a real live McIntosh VU meter that I own. For those that care, the circuit is just doing some basic integration/filter and then a buffer that drives the appropriate current level for the needle movement. And this is why I added the LKFS calculation as it is the closest to this functionality. Making the visualization closely match the real meter behavior has been my objective, not replicating the behavior of the original VU meter component.
• For the AIMP skins, I ignore the Mobility* parameters because I don't know what these exactly represent in the AIMP DLL and I think that they are wrong given that many skins just copy/paste them even though the panels have different graduations; similarly several skins also have the wrong *Level parameters.
• Once again, the BIN file is so much more elegant as everything is precalculated and all I have to do is select the frame to show without any compositing.

• Columns UI support.
• Multi-channel support.
• BPM visualization.
• Windows Script Host or ActiveX support.
• vkd3d support; the "D3D12CreateDevice" function call fails with -> E_NOINTERFACE No such interface supported.
• Low-level performance optimizations.

Detected memory leaks!
Dumping objects ->
..\pfc\alloc.h(8) : {863} normal block at 0x0000020C568DDCD0, 8 bytes long.
 Data: <VUj2    > 56 55 21 32 01 00 00 00 
{862} normal block at 0x0000020C540E9100, 48 bytes long.
 Data: <H  _    z    . C> 48 A3 02 5F FD 7F 00 00 7A 8B 8B 0A 90 2E BB 43 
Object dump complete.

Adwdg-1.zip
Adwdg-2.zip
Adwdg-3.zip
Skin is not displayed correctly.

Ц4202
The background color will be white.

I've made some additional changes to support multiple instance windows and the LVU skins. Release 0.3.0 is mainly made up of dirty workarounds due to the special/ugly/inconsistent window lifecycle of the Default UI. Release 0.3.1 is a small UI fix and release 0.3.2 includes the LVU extension. At this point more than the initial feature set is implemented. Release candidate version: 0.3.2

Seeing as how work obligations are ramping up, leaving substantially less time to work on foobar2000 components, requested features which have not been implemented, at least for a while and may never be (at least by me) are:

• Columns UI support.
• Multi-channel support.
• BPM visualization.
• Windows Script Host or ActiveX support.
• vkd3d support; the "D3D12CreateDevice" function call fails with -> E_NOINTERFACE No such interface supported.
• Low-level performance optimizations.

I apologize if you were holding out for any of these. However, I still expect to work on refinements, particularly on the needle accuracy, calculations and movement. Also, will be fixing any incompatibilities with the supported skins, if found. Finally, I'm focusing on adding some documentation.

The only known memory leak is in PFC in the configuration allocation code which is inside the SDK and not owned by me. The configuration data appears not to be cleaned fully when adding or removing instances during layout editing.

Code: [Select]

Detected memory leaks!
Dumping objects ->
..\pfc\alloc.h(8) : {863} normal block at 0x0000020C568DDCD0, 8 bytes long.
 Data: <VUj2    > 56 55 21 32 01 00 00 00 
{862} normal block at 0x0000020C540E9100, 48 bytes long.
 Data: <H  _    z    . C> 48 A3 02 5F FD 7F 00 00 7A 8B 8B 0A 90 2E BB 43 
Object dump complete.

Last but not least, a crash may occur on program exit. It is not user noticeable and does not trigger the foobar2000 crash reporting. It is due to a use-after-free issue when the component DLL tries to deallocate memory already freed by foobar2000 during layout editing cut/paste--not all windows are sent "WM_DESTROY" correctly and some destructors get called an additional time.

I apologize if you were holding out for any of these. However, I still expect to work on refinements, particularly on the needle accuracy, calculations and movement. Also, will be fixing any incompatibilities with the supported skins, if found. Finally, I'm focusing on adding some documentation.

• Mode: Stereo
• Levels: RMS
• Decay: Normal (1.00)
• Zero: 0.00 frames
• Range: 0.00
• Rise: 0.20
• Jitter: 0.00
• Gain: 0.00 dB (skin-dependent)
• Window: 200.00 ms
• FPS: 60.00 fps
• Corner: 0.00 pixels
• Downmix Channels: disabled
• Cubic Interpolation: disabled

Set-Location -Path "<foobar2000 profile folder>"
Remove-Item -Path "vumeter" -Recurse -Force
New-Item -Type SymbolicLink -Path "vumeter -Target "<full path to more conveniently-located, possibly shared folder>"

As shown above, what I think will be the final release candidate before a full public release is out: 0.4.0
It includes the last batch of features and fixes and barring any major bugs, the code is frozen. The documentation I'll work to publish next week is based on this feature set.

Finally, I haven't run AIMP in many years. I don't know how the skins look or what is their behavior. What you see in this component is my "artistic" interpretation. Specifically, the LEDs in LVU skins the light is continuous and the position is interpolated in between the skin's "dbs" entries; while in the AIMP analog skins, the LEDs are discrete (i.e., they don't turn on partially).

With that, thanks for reading and sharing your feedback!