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.

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

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);
      }
   }

@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.

Pattern: %composer%