Can you tell me why foobar doesn't see the plugin update? I have to download and install it manually.

When foobar is started, it will throw the error below, and get stuck in an infinite loop throwing the same error. foobar cannot start.

Thanks for posting Version: 0.8.0. I don't know if you worked on the skinloader or not but in this version it still only loads one instance. Plus sometimes it won't even load that one instance as you can see when I load the color cyan, at the end of the animation.

• There is now a EBU R 128 mode that uses libebur128. So, if you prefer an alternative loudness calculation to my implementation of BS.1770 that is it. It is a bit leaky. I squashed some of the issues with the CRT memory debugger and address sanitizer. There may still be some more, and I cannot vouch for the accuracy of the calculations. Use at your discretion.
• I found a "tap and press" gesture in the original component to change skins when testing how skins changed in groups, so I implemented it.
• The skin change menu will ONLY change skins within the group. It is a NOP otherwise. I put a watchdog timer of 2 seconds on it to avoid issues.
• Since I got tired of right clicking the menu to change the tuning parameter, holding Esc, Right Alt or AltGr while moving the mouse wheel with do the same. Also, mouse buttons 4 and 5 will change it but since foobar2000 grabs those by default to move to the prev/next track in the playlist it might not be as good as the modifier methods. One small issue is that I didn't have time to fix the tooltip to reflect the change in real-time since I got sidetrack searching for the EBU R 128 memory leaks. I'll get to it soon.
• To try to keep some loose feature parity with the BoringName's MusicBee plugin, I added ability to open separate left/right panel files (ending in 1.bin or 2.bin). I finally found the explanation for the curve adjustment parameter so that should work as well. But if you don't like any of the RAR skin's INI file overriding your settings, there is now the option to ignore the INI file.
• Do not expect write back of the custom settings into the INI file due to the licensing restrictions of the RAR format.

@ApacheReal : Nothing about your config is related to PNG handlig in foobar2000. You use only third party components and hacks to render your UI. The transparency hack for example is very inefficient, especially if the component behind there drawing the image was only designed to render the image on resize. It may keep re-decompressing and rescaling it a hundred times per second.

lly, here is the release notice for 0.8.0.

Quote from: Majestyk on 2024-12-08 03:51:28

Thanks for posting Version: 0.8.0. I don't know if you worked on the skinloader or not but in this version it still only loads one instance. Plus sometimes it won't even load that one instance as you can see when I load the color cyan, at the end of the animation.

Try now. I tried to replicate the original's behavior. There are a few skins that take a longer time to load where all might not change together. Mainly it's the ones where the BIN is packed inside a RAR with the settings. The way this works is using a mailbox. So, try adding a delay in between the two fb.* commands. I'm going to take a shot in the dark and guess that the reason only VU is changing is that it clobbers the PEAK change before the render/uncompress thread opens the mailbox.

In addition, I added a few extra things. Let me elaborate:

• There is now a EBU R 128 mode that uses libebur128. So, if you prefer an alternative loudness calculation to my implementation of BS.1770 that is it. It is a bit leaky. I squashed some of the issues with the CRT memory debugger and address sanitizer. There may still be some more, and I cannot vouch for the accuracy of the calculations. Use at your discretion.
• I found a "tap and press" gesture in the original component to change skins when testing how skins changed in groups, so I implemented it.
• The skin change menu will ONLY change skins within the group. It is a NOP otherwise. I put a watchdog timer of 2 seconds on it to avoid issues.
• Since I got tired of right clicking the menu to change the tuning parameter, holding Esc, Right Alt or AltGr while moving the mouse wheel with do the same. Also, mouse buttons 4 and 5 will change it but since foobar2000 grabs those by default to move to the prev/next track in the playlist it might not be as good as the modifier methods. One small issue is that I didn't have time to fix the tooltip to reflect the change in real-time since I got sidetrack searching for the EBU R 128 memory leaks. I'll get to it soon.
• To try to keep some loose feature parity with the BoringName's MusicBee plugin, I added ability to open separate left/right panel files (ending in 1.bin or 2.bin). I finally found the explanation for the curve adjustment parameter so that should work as well. But if you don't like any of the RAR skin's INI file overriding your settings, there is now the option to ignore the INI file.
• Do not expect write back of the custom settings into the INI file due to the licensing restrictions of the RAR format.

         if (name == "DisplayColour") {
          window.SetProperty("DisplayColour", info);
          display_system.InitColours();
          display_system.setColours();
         fb.RunMainMenuCommand("View/Visualizations/Analog VU Meter skins/DarkOne4PEAK/" + vu_style + " " + display_system.display_arr[display_system.display_combi_colour]);
         setInterval(() => {
             fb.RunMainMenuCommand("View/Visualizations/Analog VU Meter skins/DarkOne4PEAK/" + vu_style + " " + display_system.display_arr[display_system.display_combi_colour]);
          }, 200);
          setInterval(() => {
             fb.RunMainMenuCommand("View/Visualizations/Analog VU Meter skins/DarkOne4VU/" + vu_style + " " + display_system.display_arr[display_system.display_combi_colour]);
          }, 200);
          window.Repaint(g_all);
      }
   }

Since I assume only Peter's components get updated automatically, here is the release notice for 0.8.0.

you keep making claims that everything leaks memory. I'm confident SDK exposed methods don't leak memory, but when used incorrectly your component can. If you disagree, should be simple to show what leaks. Your current claim is equal to saying Visual C runtime leaks memory because it has malloc and new.
Also I haven't noticed any leaks in libebur128. If it indeed does, I'd appreciate you telling the source file name and line where memory is allocated that then isn't freed?

I fixed automatic updates for this component. The reason they weren't working is because the component is listed with a different name than it actually uses.

I'd like to request that foo_vis_vumeter have the ability to recognize user-extracted RAR's of this type and have the ability to recognize the BIN's same-name INI file in the skins folder and apply the same ignore/not ignore defaults to them.

In 0.8.0 I'm having a problem with the Tuning menu when selecting an option and then using the scroll wheel. With the exception of ZERO and GAIN, the scroll wheel does not operate properly.

Instead of changing the levels it instead cycles through the menu choices. So if FPS is selected and I scroll the mouse (without pressing anything), it will cycle through the Tuning menu options. Then it eventually stays on GAIN.  So in other words I can only change the level of ZERO and GAIN.

I tested this on 0.7.7 and it works perfectly fine.

The name mismatch was bigger. In the code your component is called "VU Meter Visualisation" and in the repository "Analog VU Meter Visualisation". This makes the update checker think it's a different component.

Btw, the libebur128 has a crash bug with extreme samplerates.

In 0.8.0 I'm having a problem with the Tuning menu when selecting an option and then using the scroll wheel. With the exception of ZERO and GAIN, the scroll wheel does not operate properly.

Yikes, I just noticed the same thing here.  Oops mentioned that he added different ways of accessing the tuning menu ("Add `Escape` and `RAlt/AltGr` as modifier keys on the mouse wheel to change tuning parameter") but the once you get there you can only change the VALUE of "gain", otherwise the wheel just cycles the parameter NAMES without allowing a value change.

I think I got it close enough. Sharing the tuning parameters in case it helps others:

Code: [Select]

Mode	Stereo
Levels	RMS
Range	0.00
Decay	1.25
Rise	  0.17
Jitter	0.11
Gain	 +9dB
Window	40ms
FPS      25

Quote from: Majestyk on 2024-12-08 10:58:18

In 0.8.0 I'm having a problem with the Tuning menu when selecting an option and then using the scroll wheel. With the exception of ZERO and GAIN, the scroll wheel does not operate properly.

Try 0.8.1. Zero and Gain are special because they can use all of the other modifier keys. Sorry for the breakage.

I'm a little perplexed by this. I thought the Tuning option that had the check mark would be the only active one. These settings imply otherwise. Does it really matter what the non selected Tuning option is set to?

• If you select a skin that is not a BIN (i.e., ZIP from AIMP or LVU), then the Zero option is grayed out and disabled implying it is not used.
• If you select one of the loudness modes (i.e., BS.1770 or R 128), then the Zero and Range options are grayed out and disabled.
• The newly-added tuning parameter switching through the mouse wheel is aware of these special behaviors. It would not allow moving into a disabled tune setting. However, it does allow moving out.
• Locking the tune, disables that popup menu freezing all of the settings at their current values.

Quote from: Majestyk on 2024-12-08 23:58:26

I'm a little perplexed by this. I thought the Tuning option that had the check mark would be the only active one. These settings imply otherwise. Does it really matter what the non selected Tuning option is set to?

The implication that all the settings matter and apply is the correct interpretation. So, it definitely matters what the non-selected tuning option is set to. The "check mark", only means this is the one that will be affected by the mouse wheel and middle mouse button.

I think I got it close enough. Sharing the tuning parameters in case it helps others:

Code: [Select]

Mode	Stereo
Levels	RMS
Range	0.00
Decay	1.25
Rise	  0.17
Jitter	0.11
Gain	 +9dB
Window	40ms
FPS      25

It's funny, this doesn't work for me unless I put gain to +17. Is there something in my fb2k prefs that isn't set right? If I use Peak instead of RMS I can set it to +9.

Minor bug... The radio button in the Decay menu is rarely displayed.

Quote from: Majestyk on Today at 11:45

Minor bug... The radio button in the Decay menu is rarely displayed.

Intentional. Will only have the radio dot next to the named setting if the current setting is that value. If I recall correctly, it is 0.75 for Slow, 1.00 for Normal and 1.50 for Fast. Little details