Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_vis_vumeter (Read 67093 times) previous topic - next topic
0 Members and 26 Guests are viewing this topic.

Re: foo_vis_vumeter

Reply #325
PGGB-RT 5.6.5 (foo_pggb_rt)
The CPU is not supported.
Do you use it regularly?

https://hydrogenaud.io/index.php/topic,123924.msg1056871.html#msg1056871

Before deleting, you have to right-click on the Playlist view and select Undelete.

We may rule out the PGGB-RT as I don't have any custom components other, than foo_vis_vumeter on the portable foobar2000 installed and the effect is the same. See minidump from the portable version attached.

I have just discovered the PGGB-RT and it works. My CPU has AVX and AVX2 instruction sets according to Intel Ark:
https://www.intel.com/content/www/us/en/products/sku/75043/intel-core-i54570-processor-6m-cache-up-to-3-60-ghz/specifications.html
and CPU-Z:

Re: foo_vis_vumeter

Reply #326
It is definitely failing due to DirectX during the initialization that sets up the lighting and texturing effects. It is not falling back onto WARP so that part should have no effect or needed.
For future reference the runtime failure is in this function/code snippet.

From the screenshots, you have the latest driver version I could find for the graphics device and a properly updated OS. And it meets the minimum DX12 specifications outlined above including the feature level. Unfortunately, the failure code is optimized away in the release binaries so I cannot know for sure, so I'm going to guess that it is either a driver issue or you simply ran out of video memory.

Rather than keep debugging and guessing, I'll create a version on the next release that completely removes the lighting effects. You can test whether that work arounds the issue in your system at that point.

Re: foo_vis_vumeter

Reply #327
Released 0.9.0. Besides a couple of bug fixes, it has Automation (scripting) support. Tested with JSP3, but hopefully it works with other interpreters. I kept the exact interfaces as the original component and I've tried to implement all the functions. However, at this point the behavior of these calls is not 1:1 and my usage testing has been simple. It also assumes that there is an instance of the component running to get valid values for the properties, as in the snippet below.

Code: [Select]
function get_text() {
  var VUMeter = null;
  var Left = 0;
  var Count = 0;
  if (fb.CheckComponent("foo_vis_vumeter")) {
    VUMeter = new ActiveXObject("VUMeter");
    Left = VUMeter.LeftLevel; // returns the left channel level for the first VUMeter instance (this is affected by the mode selected)
    //VUMeter.RegisterWindow(window.ID); // nop
    var VUWindow = VUMeter.CreateWindow(window.ID); // returns a reference to the first VUMeter instance's UI element
    Count = VUWindow.GroupCount; // returns the current number of folders (groups) in the "vumeter" folder
    VUWindow.LoadNextSkin(""); // causes the first VUMeter instance's panel (skin) to change to the next one in the group (in ASCII order) -- similar to how the hidden menu option works
  }
  var text = "VUMeter test " Left + " " + Count + "\n";
  return text;
}

Here is the work in progress documentation for the functionality.

Code: [Select]
IVUMeter
========

  Properties
  ----------
    LeftLevel     number  read - current left channel level in dB.
    LeftPeak      number  read - current left channel peak level in dB.
    RightLevel    number  read - current right channel level in dB.
    RightPeak     number  read - current right channel peak level in dB.
    Offset        number  read, write - preamplifier gain setting in dB.
    UpdatePeriod  number  read - current sample window setting in milliseconds.

  Functions
  ---------
    RegisterWindow(ID) --> will not function as the original due to architectural differences
      Arguments
          ID  number
      No return value.

    RegisterRect(ID, Left, Top, Width, Height) --> will not function as the original due to architectural differences
      Arguments
        ID      number
        Left    number  pixels
        Top     number  pixels
        Width   number  pixels
        Height  number  pixels
      No return value.

    CreateWindow(ID) --> will not function as the original due to architectural differences
      Arguments
        ID  number
      Returns an `IVUMeterWindow` instance.

var Layout = {
    BothH : 0,
    BothV : 4,
    Left  : 1,
    Right : 2,
    Mono  : 3,
};

IVUMeterWindow
==============
  Properties
  ----------
    Visible          boolean  read, write
    Enabled          boolean  read, write
    Layout           Layout   read, write
    LockAspectRatio  boolean  read, write
    SkinName         string   read, write
    GroupName        string   read, write
    SkinCount        number   read
    GroupCount       number   read

  Functions
  ---------
    SetBounds(Left, Top, Width, Height) --> will not function as the original due to architectural differences
      Arguments
        Left    number  pixels
        Top     number  pixels
        Width   number  pixels
        Height  number  pixels
      No return value.

    SetConfig(GroupName, SkinName, Layout) --> will not function as the original due to architectural differences
      Arguments
        GroupName  string
        SkinName   string
        Layout     Layout
      No return value.

    Groups(Index)
      Arguments
        Index  number
      Returns a string containing the group name that corresponds to the index.

    Skins(Index)
      Arguments
        Index  number
      Returns a string containing the skin name that corresponds to the index.

    LoadSkin(GroupName, SkinName)
      Arguments
        GroupName  string
        SkinName   string
      No return value.

    LoadPrevSkin(GroupName)
      Arguments
        GroupName  string
      No return value.

    LoadNextSkin(GroupName)
      Arguments
         GroupName  string
      No return value.

In addition, for @p.h., I've attached a version (0.9.0.1) with the texture and lighting code completely removed--and only x86 and x64 versions. Feel free to try it and report back.

Re: foo_vis_vumeter

Reply #328
Released 0.9.0. Besides a couple of bug fixes, it has Automation (scripting) support. Tested with JSP3, but hopefully it works with other interpreters. I kept the exact interfaces as the original component and I've tried to implement all the functions. However, at this point the behavior of these calls is not 1:1 and my usage testing has been simple. It also assumes that there is an instance of the component running to get valid values for the properties, as in the snippet below.


Awesome work, thanks!

Re: foo_vis_vumeter

Reply #329
In addition, for @p.h., I've attached a version (0.9.0.1) with the texture and lighting code completely removed--and only x86 and x64 versions. Feel free to try it and report back.
Thx.

Config fooBar-32bit. CUI / PSS (with transparency on) / JSplitter (with transparency on) / VU Meter (DirectX 12).

Both 0.9.0 and 0.9.0.1 look fine. I do not see any difference whether running 0.9.0 or 0.9.0.1. Should there be a difference?

I tested a transparent AIMP skin, which is fine on JS3 ilovefb2k, but displays standard background of Dark Theme with this component. Does look a lot better than the BIN version because VU Editor makes a checkerboard of the transparent parts while making the BIN, which doesn't happen in the AIMP version.

Is support for transparency somewhere on your todo list?

Also still missing the option 'Force Lock Aspect Ratio on Fullscreen'. So fullscreen still looks silly on a lot of VU skins.
This RFC does not look very complicated to add support for imo.

Re: foo_vis_vumeter

Reply #330
In addition, for @p.h., I've attached a version (0.9.0.1) with the texture and lighting code completely removed--and only x86 and x64 versions. Feel free to try it and report back.

@oops Thank you very much. Please find crash log attached. This time, foobar2000 doesn't crash at the very moment I click OK to add the VU Meter. It looks as if it manages to load background for the visualisation, so it takes a few seconds.

Re: foo_vis_vumeter

Reply #331
Please find crash log attached. This time, foobar2000 doesn't crash at the very moment I click OK to add the VU Meter. It looks as if it manages to load background for the visualisation, so it takes a few seconds.
It is loading everything now including the BIN files and DirectX gets fully set up. Window is created and the component begins rendering and painting the first frame. But it is now failing on the EndDraw() call during/after drawing the rounded rectangle background. This is a fundamental and simple Direct2D operation. I don't know where to go from here. I am personally very saddened that Haswell Processor Graphics don't seem to be working with the DirectX 12 API.

Re: foo_vis_vumeter

Reply #332
I do not see any difference whether running 0.9.0 or 0.9.0.1. Should there be a difference?
Since I've not outlined how to take advantage of the custom shader/effects publicly, no. There is a prerequisite that you must know how to code HLSL and understand the rendering pipeline to even begin.

I tested a transparent AIMP skin, which is fine on JS3 ilovefb2k, but displays standard background of Dark Theme with this component.
Thanks for testing.

Does look a lot better than the BIN version because VU Editor makes a checkerboard of the transparent parts while making the BIN, which doesn't happen in the AIMP version.
The BIN file is composited by the VUEditor into a bitmap with all zeroes for the alpha channel for the base image. If you really wanted transparency, you could probably figure out how to programmatically modify the base image to include the alpha data in the checkerboard area. If you do, with a small header flag it could be made to work, though you will still end up at the same point with the pseudo transparency dilemma.
I do the transforms and compositing for the AIMP versions. To be honest I really, really much prefer the BIN files because it abstracts out all of that complexity, the representation is compact and mapping the audio levels is straightforward.

Is support for transparency somewhere on your todo list?
I would like to, but I don't know how to do it...yet. I've tried experimenting with what mark2k3 suggested but could not get it to work. Been scouring GitHub and MSDN for other ways to approach the problem but coming up empty.

Also still missing the option 'Force Lock Aspect Ratio on Fullscreen'. So fullscreen still looks silly on a lot of VU skins.
This RFC does not look very complicated to add support for imo.
A RFC is a formal specification document and includes detailed justification for the change. Our discussions in this forum are far from that ;) When "Lock" is enabled it carries over into fullscreen mode. And even in fullscreen, "Lock" can be set by the context menu. I'm failing to see what the "ask" difference is to the options that are available. Why it is not possible to accomplish what you need with the existing options?

Re: foo_vis_vumeter

Reply #333
It is loading everything now including the BIN files and DirectX gets fully set up. Window is created and the component begins rendering and painting the first frame. But it is now failing on the EndDraw() call during/after drawing the rounded rectangle background. This is a fundamental and simple Direct2D operation. I don't know where to go from here. I am personally very saddened that Haswell Processor Graphics don't seem to be working with the DirectX 12 API.

Thank you for your help.

Is the WARP an option here?
Could increasing a memory allocated to the GPU help? I could check what I have set in the BIOS.

Re: foo_vis_vumeter

Reply #334
The BIN file is composited by the VUEditor into a bitmap with all zeroes for the alpha channel for the base image. If you really wanted transparency, you could probably figure out how to programmatically modify the base image to include the alpha data in the checkerboard area. If you do, with a small header flag it could be made to work, though you will still end up at the same point with the pseudo transparency dilemma.
I asked the following in the musicbee forum, but no answer yet:
Reply #32 on: December 14, 2024, 03:23:53 PM
@BoringName
Using BinExtractor1.2 works fine.

VU Editor does something nasty to to the source Back image png when building a BIN. It stores the transparent parts of a background to a grey checkerboard when building the BIN.
How do I replace a background png with a modified png with transparent parts inside the BIN?

Can your tool be modified to replace the background png or is there another way?


It is BTW an excellent tool to retrieve the background from a BIN and makes it a lot easier to modify/create BIN files and combine Left/Right in one file.

I do the transforms and compositing for the AIMP versions. To be honest I really, really much prefer the BIN files because it abstracts out all of that complexity, the representation is compact and mapping the audio levels is straightforward.
I only tested because I wanted to see if your plugin handles transparent VU backgrounds, and yes it does.

Is support for transparency somewhere on your todo list?
I would like to, but I don't know how to do it...yet. I've tried experimenting with what mark2k3 suggested but could not get it to work. Been scouring GitHub and MSDN for other ways to approach the problem but coming up empty.
Thx for trying.

Also still missing the option 'Force Lock Aspect Ratio on Fullscreen'. So fullscreen still looks silly on a lot of VU skins.
Why it is not possible to accomplish what you need with the existing options?
In the skin I set the VU Meters to no lock (especially since VU cannot use transparency and I don''t want ugly backgrounds). I control the size I want them displayed in and stretch. I stretch width up to 175% or height up to 150%. This works well for all next to each other skins and others I do not use.
When I go fullscreen however, since the aspect ratio is unlocked the whole screen is utilized (in my main system 2560x1600) and that looks terrible.
So what would like is a separate independent setting that controls lock aspect ratio for fullscreen.

Re: foo_vis_vumeter

Reply #335
Is the WARP an option here?
If you're willing to try WARP, let me see how to build a version where it is the primary and not the fallback adapter. Because it is pure software rendering, it will likely be slow and use up a large percentage of the CPU cycles. I really just added it in case someone was silly enough to try using foobar2000 through Wine/DXVK.

Could increasing a memory allocated to the GPU help? I could check what I have set in the BIOS.
Not manually controllable. The system allocates it. If I recall correctly, Haswell can use up to 2 GiB out of the main memory (it is called a unified memory architecture if you want to look it up). Try to see using Task Manager if the shared GPU memory gets filled up. I suspect it will not fill or run out--from the memory footprint on the profiler when I'm debugging.

Re: foo_vis_vumeter

Reply #336
The BIN file is composited by the VUEditor into a bitmap with all zeroes for the alpha channel for the base image. If you really wanted transparency, you could probably figure out how to programmatically modify the base image to include the alpha data in the checkerboard area. If you do, with a small header flag it could be made to work, though you will still end up at the same point with the pseudo transparency dilemma.
I asked the following in the musicbee forum, but no answer yet:
Reply #32 on: December 14, 2024, 03:23:53 PM
@BoringName
Using BinExtractor1.2 works fine.

VU Editor does something nasty to to the source Back image png when building a BIN. It stores the transparent parts of a background to a grey checkerboard when building the BIN.
How do I replace a background png with a modified png with transparent parts inside the BIN?

Can your tool be modified to replace the background png or is there another way?

@oops

I considered asking you to do something similar as what you do with AIMP.

If a BIN is contained in an archive (zip/rar) and also included is one or two PNG's that those PNG's supersede the ones inside the BIN.

But I don't see the point in asking that unless the container where your plugin lives in is transparent. There's no point in support for transparent PNG if you only are going to see the standard background of the theme through it.

Re: foo_vis_vumeter

Reply #337
Released 0.9.1 with only minor changes.

I control the size I want them displayed in and stretch. I stretch width up to 175% or height up to 150%. This works well for all next to each other skins and others I do not use.
When I go fullscreen however, since the aspect ratio is unlocked the whole screen is utilized (in my main system 2560x1600) and that looks terrible.
So what would like is a separate independent setting that controls lock aspect ratio for fullscreen.
Appreciate the more descriptive explanation. Check the fullscreen behavior in 0.9.1. See if it behaves to your liking; no additional option needed.

Is the WARP an option here?
Attached 0.9.1.1 is the WARP-only version that will skip using any of the existing hardware adapters. It will crash foobar2000 at runtime if the WARP DLL cannot be found. I saw massive slowdown if using the COM interface at the same time, so don't use those features unless you like a stuttering animation.

Re: foo_vis_vumeter

Reply #338
Check the fullscreen behavior in 0.9.1. See if it behaves to your liking; no additional option needed.
It's excellent.

The reason I did not ask you to implement it this way is that some users might prefer to see the VU fill the whole screen in fullscreen mode.

And BTW first time I asked for a change for fullscreen was https://hydrogenaud.io/index.php/topic,126733.msg1056461.html#msg1056461 point 2.
I think my wording there was also quite descriptive.

Anyway, thank you for fixing/implementing this.

Re: foo_vis_vumeter

Reply #339
Released 0.9.1 with only minor changes.
Is the WARP an option here?
Attached 0.9.1.1 is the WARP-only version that will skip using any of the existing hardware adapters. It will crash foobar2000 at runtime if the WARP DLL cannot be found. I saw massive slowdown if using the COM interface at the same time, so don't use those features unless you like a stuttering animation.

Thank you for building the WARP-only version. It doesn't crash, but stutters so much, that it makes foobar2000 unusable at all. Foobar2000 uses about 80% of CPU, and 150MB is allocated to the GPU.

Was there at some point a DirectX 11 version?

Re: foo_vis_vumeter

Reply #340
Thank you for building the WARP-only version. It doesn't crash, but stutters so much, that it makes foobar2000 unusable at all. Foobar2000 uses about 80% of CPU, and 150MB is allocated to the GPU.
Was there at some point a DirectX 11 version?
There is no DirectX 11 version. For reasons I will not go into, I need to develop familiarity with graphics processing hardware and architecture at a very deep level; particularly focused on managing CPU and GPU synchronization. DirectX 12 and Vulkan offer the opportunity/control required, and this component is the result of that ongoing exercise.

As for WARP, try removing other components in foobar2000. In my case, the stuttering magically got better when I removed JSP3. The entire application stutters because everything is running on the same modal loop/message pump--including (my mistake) repainting and building the command list for the GPU. This experiment appears successful, nevertheless, in that it has become clear that the graphics driver is likely where the issue is located.

To use the full DirectX 12 version on that machine, you'll need to "fix" the driver. It turns out DirectX 12 was deprecated on 4th Generation Core processors due to security vulnerabilities. So you'll have to downgrade the driver version if you want to get back functionality. Obviously, that comes with the tradeoffs and risks of using software with published and known issues. Please proceed with caution if you decide to do this.

Re: foo_vis_vumeter

Reply #341
Other solutions are GDI based.
Hey @marc2k3 or anyone in the know. I modified a DirectX 12 resource/texture to be able to blit into it any GDI-drawn DC.

Could you kindly elaborate more or have a sample of where/how to use the paint_background_using_parent() method suggested?
How is this set up in foobar2000 to test that it works? I assume using Panel Stack Splitter in Columns UI is the "traditional" way to achieve transparency. Which options are enabled and disabled to display the desired effect(s)?
What is the expected result supposed to look like? I assume that only the background transparent and the foreground at full opacity.

References (for quick access in future):

Re: foo_vis_vumeter

Reply #342
So you need 32bit fb2k for testing. Panel stack splitter was last updated in 2009.

https://foo2k.chottu.net/

Create a columns UI layout like this...



Then with PSS highlighted, click the "Configure panel.." button.

Now select the "Behaviour" tab and enable "Use background image".

Use the file picker to select an actual image from somewhere. You might end up with something like this...



Now add your own component instance to the CUI layout tab with PSS as the parent.



If working, you can see your panel contents with PSS wallpaper as the background.

Re: foo_vis_vumeter

Reply #343
Code wise, I don't have transparency as an option. I only allow it when a panel is added as Columns UI toolbar because that requires it.



When I create my HWND render target, the D2D1_RENDER_TARGET_USAGE is determined on my own Type enum...

Code: [Select]
	enum class Type
{
DUIPanel,
CUIPanel,
CUIToolbar
};

Code: [Select]
HRESULT PanelBase::create_render_target() noexcept
{
if (!m_render_target)
{
RETURN_HR_IF(E_FAIL, !factory::inited);

const auto usage = m_type == Type::CUIToolbar ? D2D1_RENDER_TARGET_USAGE_GDI_COMPATIBLE ? D2D1_RENDER_TARGET_USAGE_NONE;
const auto properties = D2D1::RenderTargetProperties(D2D1_RENDER_TARGET_TYPE_DEFAULT, D2D1::PixelFormat(DXGI_FORMAT_B8G8R8A8_UNORM, D2D1_ALPHA_MODE_IGNORE), 96.f, 96.f, usage);
const auto hwnd_properties = D2D1::HwndRenderTargetProperties(m_wnd, m_size, D2D1_PRESENT_OPTIONS_RETAIN_CONTENTS);

RETURN_IF_FAILED(factory::d2d->CreateHwndRenderTarget(&properties, &hwnd_properties, &m_render_target));
LOG_IF_FAILED(update_rendering_params());
}

return S_OK;
}

Re: foo_vis_vumeter

Reply #344
So you need 32bit fb2k for testing.
Create a columns UI layout like this...
Code wise, I don't have transparency as an option. I only allow it when a panel is added as Columns UI toolbar because that requires it.
Thank you, my friend! Appreciate taking the time to screenshot and writing that up. Here we are:
Spoiler (click to show/hide)

Got to clean up all of the hacks and temporary code, fix minor issues. For example, regular window client area background returns when going to fullscreen blocking the background except for the 10 or so pixel border. Hoping to find time to do so and make a proper release next week.

Another helpful reference:

Re: foo_vis_vumeter

Reply #345
So you need 32bit fb2k for testing.
Create a columns UI layout like this...
Code wise, I don't have transparency as an option. I only allow it when a panel is added as Columns UI toolbar because that requires it.
Thank you, my friend! Appreciate taking the time to screenshot and writing that up. Here we are:
Spoiler (click to show/hide)

Got to clean up all of the hacks and temporary code, fix minor issues. For example, regular window client area background returns when going to fullscreen blocking the background except for the 10 or so pixel border. Hoping to find time to do so and make a proper release next week.

Another helpful reference:
@oops @marc2k3

Great news.

Technically speaking... This will work in CUI x64 too. Just pack the plugin in a JSplitter, which is set to transparency.

I only use PSS (32bit) for control, stretching, background/art background.
PSS crashes when VU 2024 goes fullscreen.
So I added a JSplitter (set to transparency) in this PSS. The PSS handles positioning/size of the JSplitter daughter panel and paints background and possible art.
This JSplitter only has one component, which is VU 2024 and now there's no crashes going fullscreen and back.

Since JSplitter is also x64 this means transparency will work from fooBar x64 / CUI x64 / JSplitter x64.

I use this bit of code to make handling the JSplitter panel a bit easier.
Code: [Select]
"use strict";

/*
JSplitter script to use full panel for first plugin without maximizing the plugin by caption

Set context=1 to be able to activate context menu for JSplitter on right mouseclick
Set background=0 to disable background which enables transparency

author Defender - ver 1.0 - 2024-12-21
*/

////////////////////////////////
let context = 0; // 0=plugin full width/full height - no access to context 1=plugin half width/full height - enable access to context

let background = 0; // 0=Do not paint background - transparency 1=Paint paintground
let gradient = 1; // 0=Do not paint gradient 1=Paint gradient when background=1

let g_colback = 0xFF131E26; // rgba(19,  30,  38, 255)

let g_colgrad_t = 0x803F6480; // rgba(63, 100, 128, 128)
let g_colgrad_b = 0x00000000; // rgba(0,    0,   0,   0)
/////////////////////////////////

let ww = 0;
let wh = 0;

function on_size(width, height) {
ww = width;
wh = height;

show_panel0();
}

function show_panel0() {
if ( window.GetPanelCount() > 0 ) {
var P0 = window.GetPanelByIndex(0);

var x = 0;
var y = 0;
var w = ww;
var h = wh;

if ( context == 1 ) {
x = ww/4; y = 0; w = ww/2; h = wh;
}

P0.Move(x, y, w, h);
P0.Show();
}
}

function on_paint(gr) {
if ( background == 1 ) { gr.FillSolidRect(0, 0, ww, wh, g_colback);
if ( gradient == 1 ) { gr.FillGradRect( 0, 0, ww, wh/2, 90, g_colgrad_t, g_colgrad_b);
}
}
}

Re: foo_vis_vumeter

Reply #346
I asked the following in the musicbee forum, but no answer yet:
Reply #32 on: December 14, 2024, 03:23:53 PM
@BoringName
Using BinExtractor1.2 works fine.

VU Editor does something nasty to the source Back image png when building a BIN. It stores the transparent parts of a background to a grey checkerboard when building the BIN.
How do I replace a background png with a modified png with transparent parts inside the BIN?

Can your tool be modified to replace the background png or is there another way?

If you have the original transparent PNG image. It should be easy to derive a 1:1 mask and remove the added checkerboard in the base image bitmap of the BIN. Literally just traverse the bitmap array one pixel at a time and zero it out if the equivalent pixel is transparent in the PNG or skip/set alpha channel to 1 if not. If you don't want to program it yourself, you could easily script it using ImageMagick--there are plenty of examples on their website and the BIN bitmap array is a simple 32bpp BI_RGB bitmap with the header stripped out.

Another idea is to use VUEditor to create a skin that is the same size and aspect ratio as your image but where the background is completely transparent. Using the resulting base (undesired) checkerboard pattern, just subtract it out of the (desired) base bitmap.

You can add a flag to the BIN to instruct the component to use transparency in the bitmap. For example, since the maximum is 1024 frames, you can use the Zero Frame word in the BIN header (e.g., make it negative [two's complement] or flip the most significant bit, whatever other simple scheme).

Edit: Unrelated side note, subtracting the composed frames that VUEditor spits out vs. the base image, alongside diff'ing the subtraction results between adjacent frames, provided the key insight to decoding the BIN file format.

Re: foo_vis_vumeter

Reply #347
I asked the following in the musicbee forum, but no answer yet:
Reply #32 on: December 14, 2024, 03:23:53 PM
@BoringName
Using BinExtractor1.2 works fine.

VU Editor does something nasty to the source Back image png when building a BIN. It stores the transparent parts of a background to a grey checkerboard when building the BIN.
How do I replace a background png with a modified png with transparent parts inside the BIN?

Can your tool be modified to replace the background png or is there another way?

If you have the original transparent PNG image. It should be easy to derive a 1:1 mask and remove the added checkerboard in the base image bitmap of the BIN. Literally just traverse the bitmap array one pixel at a time and zero it out if the equivalent pixel is transparent in the PNG or skip/set alpha channel to 1 if not. If you don't want to program it yourself, you could easily script it using ImageMagick--there are plenty of examples on their website and the BIN bitmap array is a simple 32bpp BI_RGB bitmap with the header stripped out.

Another idea is to use VUEditor to create a skin that is the same size and aspect ratio as your image but where the background is completely transparent. Using the resulting base (undesired) checkerboard pattern, just subtract it out of the (desired) base bitmap.

You can add a flag to the BIN to instruct the component to use transparency in the bitmap. For example, since the maximum is 1024 frames, you can use the Zero Frame word in the BIN header (e.g., make it negative [two's complement] or flip the most significant bit, whatever other simple scheme).

Edit: Unrelated side note, subtracting the composed frames that VUEditor spits out vs. the base image, alongside diff'ing the subtraction results between adjacent frames, provided the key insight to decoding the BIN file format.
The optimal solution for me would be that when you find a PNG with the same name as the BIN (or two PNG's with a 1/2 at the end of the name) that PNG overrules the one from within the BIN.
Or allow BIN's to be inside a RAR/ZIP container together with the partly transparent PNG.

This would be the easiest solution imo.

What I have been doing until now?
With BIN Extractor I ripped the original PNG from an existing BIN.
I alter the PNG by taking parts of the background in this PNG out. There are some websites that can help you with that.
Then I use VU Editor to easily find angles and needle position.
I create/paint a PNG needle (also a PNG) and use the angles I found to create information for a skin.ini.
Result is an AIMP style skin, which runs beautifully transparent with the ilovefb2k JS3 script but suffers from bad needle movement. With your software it runs transparent as well and has good needle control, but until now no transparent background.

I attaches two different end results.
First attachment is a BIN I made with VU Editor based on a transparent PNG with ended up inside the BIN with the checkerboard.
The second is the same thing but translated to an AIMP style ZIP (which BTW also contains the "lights" and "glass" PNG's.
So the PNG's I would like you to use to overrule the ones in the BIN are inside the AIMP style zip.

For reference I also included the whole VU project I created based on ripping a single existing original BIN. It contains all the stuff to create a Left BIN, right BIN or just the Centered BIN, with two different "lights" colors and two different needles.

All this work messing around with VU Editor would not be needed and I would not have to create a needle if your software would accept external PNG for background.

Re: foo_vis_vumeter

Reply #348
The optimal solution for me would be that when you find a PNG with the same name as the BIN (or two PNG's with a 1/2 at the end of the name) that PNG overrules the one from within the BIN.
Or allow BIN's to be inside a RAR/ZIP container together with the partly transparent PNG.

This would be the easiest solution imo.
Not the easiest solution. Nor efficient. I made that mistake with the INI files. It is painful to track and match files by their file names. Extensions are not proper ways to differentiate files either. Compressed archives can have any amount of garbage in them as well, it is more cases that need to be filtered out leading to lots of defensive programming.

In addition, the separate-PNG alternative doesn't solve the issue. Several reasons:
  • You're assuming simply providing the transparent base image "just works" without fixing the pin/needle and led/lamp deltas as well. This is very, very, very untrue.
  • A PNG generally does not include the "glass" that you find composited into the base by VUEditor.
  • Adding it to an archive or having it side-by-side with the BIN is duplicating data. It is inefficient. Plus, PNG uses DEFLATE, archiving it with another compression scheme (or DEFLATE again) is also redundant.
  • The program still must read the entire BIN file into memory because it contains large amounts of data besides the base image pixel array.
  • The PNG pixel array is top-down whereas the BMP pixel array is bottom-up in file form.
  • For transparency, need to use premultiplied alpha and not straight alpha. This has its own complications when applying the deltas. For example, dark backgrounds appear OK, but light ones bleed through and look very broken.

My suggestion:
  • Uncompress the single-side BIN file.
  • Use ImageMagick to convert the PNG base image to BMP. Generates a V5 bitmap whose pixel array is bottom-up but with proper alpha. Example: magick.exe base.png output.bmp
  • Substitute the BMP pixel array into the uncompressed BIN file. Also bitwise-OR 0x80 into the 7th byte (starting from 0) if the bitmap array has alpha and is top-down or 0xc0 if the bitmap array has alpha but the array is kept unrotated in the bottom-up order.
  • Recompress the BIN file, preferably using BZIP2 since LZMA is hard to identify as it does not have a magic number.
  • If you want to do the "right" side meter, repeat the steps and concatenate the compressed BIN files together.

This can easily be accomplished with Python or any other similar scripting language, be made generally-applicable.

All this work messing around with VU Editor would not be needed and I would not have to create a needle if your software would accept external PNG for background.
I won't post the obligatory xkcd comic panel. But this is how we end up with lots of standards and unmaintainable varieties. There has been a working format for many years. Let's try to work within those parameters as much as we can. The juggling of the INI files has taught me that flinging around of file handles and with having yet another variation of packing the data to debug does not lead anywhere fun.

Re: foo_vis_vumeter

Reply #349
The optimal solution for me would be that when you find a PNG with the same name as the BIN (or two PNG's with a 1/2 at the end of the name) that PNG overrules the one from within the BIN.
Or allow BIN's to be inside a RAR/ZIP container together with the partly transparent PNG.

This would be the easiest solution imo.
Not the easiest solution. Nor efficient. I made that mistake with the INI files. It is painful to track and match files by their file names. Extensions are not proper ways to differentiate files either. Compressed archives can have any amount of garbage in them as well, it is more cases that need to be filtered out leading to lots of defensive programming.

In addition, the separate-PNG alternative doesn't solve the issue. Several reasons:
  • You're assuming simply providing the transparent base image "just works" without fixing the pin/needle and led/lamp deltas as well. This is very, very, very untrue.
  • A PNG generally does not include the "glass" that you find composited into the base by VUEditor.
  • Adding it to an archive or having it side-by-side with the BIN is duplicating data. It is inefficient. Plus, PNG uses DEFLATE, archiving it with another compression scheme (or DEFLATE again) is also redundant.
  • The program still must read the entire BIN file into memory because it contains large amounts of data besides the base image pixel array.
  • The PNG pixel array is top-down whereas the BMP pixel array is bottom-up in file form.
  • For transparency, need to use premultiplied alpha and not straight alpha. This has its own complications when applying the deltas. For example, dark backgrounds appear OK, but light ones bleed through and look very broken.

My suggestion:
  • Uncompress the single-side BIN file.
  • Use ImageMagick to convert the PNG base image to BMP. Generates a V5 bitmap whose pixel array is bottom-up but with proper alpha. Example: magick.exe base.png output.bmp
  • Substitute the BMP pixel array into the uncompressed BIN file. Also bitwise-OR 0x80 into the 7th byte (starting from 0) if the bitmap array has alpha and is top-down or 0xc0 if the bitmap array has alpha but the array is kept unrotated in the bottom-up order.
  • Recompress the BIN file, preferably using BZIP2 since LZMA is hard to identify as it does not have a magic number.
  • If you want to do the "right" side meter, repeat the steps and concatenate the compressed BIN files together.

This can easily be accomplished with Python or any other similar scripting language, be made generally-applicable.

All this work messing around with VU Editor would not be needed and I would not have to create a needle if your software would accept external PNG for background.
I won't post the obligatory xkcd comic panel. But this is how we end up with lots of standards and unmaintainable varieties. There has been a working format for many years. Let's try to work within those parameters as much as we can. The juggling of the INI files has taught me that flinging around of file handles and with having yet another variation of packing the data to debug does not lead anywhere fun.
I just don't agree with you.

And yes I have already been thinking about this while testing VU 2024, VU JS3 and using VU Editor and BIN Extractor.

I've spent endless hours recreating BIN's (and making AIMP from it). First by making two screenshots of the BIN running in foobar in it's native resolution  one screenshot with nothing playing and the second one at max, combining the two to get rid of the needle. Then repainting a needle, and creating the glass from the background and fitting the lights to exactly the correct spot. The background retrieval is a lot easier now because of BINextractor.

I probably don't have to tell you, but you can actually see what VUeditor does when creating the BIN.
It renders frames, these frames contain 1024 transparent (!) PNG's for different needle positions where the bottom part is obscured by the glass.png and 1024 (transparent!) png's with the rendered lights by changing it's alpha per frame. And on top of that it stores the background png. The needle, glass and lights themselves are not stored in the BIN, only the rendered frames. The transparent parts of the background png are unfortunately stored as a checkerboard.
The running VU meter overlays a frame of transparent needle+glass and a frame of transparent light on the NOT transparent background which is inside the BIN.

Preferably the VU Editor app would be modified to store the background without checkerboarding it, but developers of that tool are long gone.

The issue I have with your solution is the following. In order to create a BIN, I need to create a needle, glass and lights, I also have to find all the "knots" again. Then rebuild the BIN.
And if I did everything right the resulting frames would be exactly the same as there were in the original.
So why do this? All the frames inside the original BIN are already correct, just feed VU 2024 with a new background PNG with the same dimensions that superesedes the background png inside.

"This can easily be accomplished with Python or any other similar scripting language, be made generally-applicable."
Really? People use VU meters and maybe want to put in another background, that's it. They are not developers, programmers or the like.

I just don't understand your hesitation to just accept a same dimensioned PNG that replaces the one inside while rendering.
You are using the transparent frames stored in the BIN for overlaying too, because you don't have the needle, glass and light PNG's.