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 71672 times) previous topic - next topic
foobrik and 37 Guests are viewing this topic.

Re: foo_vis_vumeter

Reply #350
I just don't agree with you.
Cool. Disagreements always welcome. Let's find some common ground. From your description of what is actually in the BIN file, I think you're slightly off the mark, let me try to clarify.

What you're describing is closer to the output of VUEditor in that you imply that the (up to) 1024 frames are stored in that BIN file alongside the background. That's not exactly how it is stored. Let's just take on the background and the needle to keep it simple.

The only full image that is stored in the BIN file is the "background" (I think of it as a combination of the static elements "back" and "glass"). As you allude to, VUEditor stores this image in the BIN with the checkerboard pattern for the transparency and it is equivalent to the "Back.bmp" when using VUEditor to render the frames individually. From what you describe, the point of misunderstanding is that the rest of the frames with the needle are also stored in the same method as the "Back.bmp". They are not.

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.
The BIN file stores each frame (really each distinct frame since many positions are repeated), as a difference or delta versus the base image. In other words, it just contains the location and the new color of the pixels that are different. You can see it in the size of the BIN file (even uncompressed) compared to the ballooning size when you dump out the frames from VUEditor. The smart part of the VUEditor and cleverness of the BIN file format is that it uses this compact scheme to store the data, avoids duplication, and yet one is able to recreate every frame. There is no compositing, I simply paint the background and then just substitute the frame-specific pixels.

I've spent endless hours recreating BIN's (and making AIMP from it).
As you experienced, the AIMP version is a nightmare in relation to the BIN method. With every new distinct element added (or "complications" to use watchmaking terminology), it requires extra rotations, translations, transformations, masking, scaling, compositing, and others in specific and unspecified orders to achieve the desired effect.

The background retrieval is a lot easier now because of BINextractor.
As much as I applaud BoringName's initiative to create BINextractor and open up the creativity of the community, I've personally never needed to use the tool. Most everything it does can be done quicker using the already well-done VUEditor and basic/ubiquitous command-line utilities.

Really? People use VU meters and maybe want to put in another background, that's it. They are not developers, programmers or the like.
That does a disservice to the creative effort that it takes to build a VU Meter, whether BIN, AIMP, LVU or some other method and the potpourri of tools at the disposal in a creator's workshop. Heck, using foobar2000 or finding and using VUEditor/GIMP/Affinity/Photoshop requires a bit more skills than your average computer user. If all you just want to do is put a different background on someone else's work, I've explained how. Similarly, if you want to work around a legacy tool's limitation, I outlined how to create it in a generic, reusable form. Work smarter, not harder.

Since no one will take what I said seriously without results, here is a quick-and-dirty Python script (with only stdlib dependencies) to modify your own BIN file to remove the checkerboarding for the "left channel" (the output BIN is uncompressed):
Code: [Select]
import binascii
import io
import lzma
import math
import subprocess
import sys

def decompress_lzma(compressed_path):
    with lzma.open(compressed_path, 'rb', format=lzma.FORMAT_ALONE) as f:
        file_content = f.read()
    return file_content

class HeaderNotSupported(Exception):
    pass

def unhexlify(bytedata):
    return binascii.unhexlify(bytedata)

def bytes2int(bytedata):
    return int.from_bytes(binascii.unhexlify(bytedata), byteorder=sys.byteorder)

def getint(bytedata):
    return int.from_bytes(bytedata, byteorder=sys.byteorder)

def read_bmp(file_path):
    content = None
    with open(file_path, 'rb') as f:
        content = f.read()
        content = binascii.hexlify(content)

    ID = unhexlify(content[:4]).decode('utf-8')
    SIZE = bytes2int(content[4:12])
    RESERVED = bytes2int(content[12:20])
    OFFSET = bytes2int(content[20:28])
    DIBHEADER = bytes2int(content[28:36])
    if DIBHEADER == 124:
        print('Header Type: BITMAPV5HEADER')
        WIDTH = bytes2int(content[36:44])
        HEIGHT = bytes2int(content[44:52])
        NBITSPERPIXEL = bytes2int(content[56:60])
        RAWIMGSIZE = bytes2int(content[68:76])
        PIXELARRAY = unhexlify(content[284:284 + RAWIMGSIZE])
    else:
        raise HeaderNotSupported('Header not supported')
    return OFFSET, RAWIMGSIZE, WIDTH, HEIGHT, NBITSPERPIXEL, PIXELARRAY

def rotate_top_down(width, height, pixel_data):
    row_size = width * 4
    rotated_data = bytearray()
    for row in range(height):
        start = row * row_size
        end = start + row_size
        rotated_data[0:0] = pixel_data[start:end]
    return rotated_data

def substitute_binary_bits(source_file, dest_file, dest_data, source_offset, dest_offset, width, height, bpp, length):
    try:
        with open(source_file, 'rb') as src:
            src.seek(source_offset)
            pixel_data = src.read(length)

        rotated_data = pixel_data  #rotate_top_down(width, height, pixel_data)

        dest = io.BytesIO(dest_data)
        dest.seek(4)
        dest_offset = 8 + getint(dest.read(2)) * math.floor(bpp / 8)
        dest.seek(7)
        zero = getint(dest.read(1))
        zero = bytearray([0xc0 | zero])  # 0x80 if rotated to top-down, 0xc0 if left bottom-up
        dest.seek(7)
        dest.write(zero)
        dest.seek(dest_offset)
        dest.write(rotated_data)

        with open(dest_file, 'wb') as file:
            file.write(dest.getvalue())

        print('Substitution completed successfully.')
    except Exception as e:
        print(f'An error occurred: {e}')

def main():
    compressed_bin = '7inch_3 X RR transparent.bin'
    source_file = 'test.bmp'
    dest_file = 'test.bin'

    command = ['magick.exe', 'L_0.png', 'test.bmp']
    subprocess.run(command, capture_output=False, text=True)
    source_offset, length, width, height, bpp, pixel_data = read_bmp(source_file)
    uncompressed_data = decompress_lzma(compressed_bin)
    substitute_binary_bits(source_file, dest_file, uncompressed_data, source_offset, 8 + 1024 * 4, width, height, bpp, length)

if __name__ == '__main__':
    main()

Figure 1. Left side replaced with transparent bottom-up bitmap. Right side unmodified. Using DUI.

I don't expect anyone to agree with my approach. However, I think separation of concerns between building the data and displaying the data/creator's intent is the right one. I still don't see a compelling reason to have loose PNG files floating around in the vumeter folder or duplicate existing data in an archive (plus double compression) as there is a "simple-ish" method (admittedly not less work) to create the BIN file with the desired properties. In addition, as I see it, by encouraging fixing these observed issues and limitation as close to the originating source as possible we will benefit the ecosystem more than just a loner creating a one-off patch in the downstream viewer.


Re: foo_vis_vumeter

Reply #352
As for WARP, try removing other components in foobar2000. In my case, the stuttering magically got better when I removed JSP3.

I have tested on o portable version with just one custom component - foo_vis_vumeter and foobar2000 was stuttering.

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.

I downgraded the driver to one earlier version. To my surprise, it did the trick!  :) Thank you.


Re: foo_vis_vumeter

Reply #354
0.9.5 released!

I'm very happy with how development has been going. Lots is (small but) interesting problems solved, much documentation read and unfamiliar concepts learned, several moments of frustration turned to happiness when that "eureka" insight hit. Let's also keep up the good back-and-forth we're having in this thread. Thank you to for the trust and contributing through ideas, help, discussion, and, above all, testing.

Some detailed feature notes:
  • Implement transparent bitmap extension to the BIN VU meter file specification. Expand the spoiler tag below for extensions to the BIN specification. The results shown in a previous thread can now be reproduced using the posted script.
  • Extend render target for GDI-drawing into a texture 2-D resource to implement pseudo-transparency. Set "Enable Transparency" and "Remove Background" context menu options to enable. "Remove Background" removes the edge-sampled background and/or the included BG.png in the ZIP panel types.
  • Add screenshot capability. Use Ctrl+Left Mouse Button on the VU Meter instance you wish to picture. A file named "screenshot.png" will be placed in the vumeter\ folder. The file is replaced every time the screen grab is triggered. To clarify it is just grabbing the pixels from the back buffer just before Present(). This only includes the client area of the single VU meter instance; not the whole screen or any of the other stuff in the player, in case that wasn't clear or properly implied.
  • Centralize in-group meter switching to replace mailbox. This is a different implementation for those using the hidden main menu to switch skins. It does away with the mailbox method and watchdog timer. It should work much more reliably. The COM Automation shares this implementation so it can be used as an alternative, if desired.
  • Add "Enable Transparency" and "Apply Inertia" context menu options. Their effects are described in other points.
  • Add inertia envelope for audio levels. Disabling the "Apply Inertia" option will use a calculation where the next needle position is decoupled from the current position. The default value is enabled and the calculation that has been done in almost all of the previous versions.
  • Add "Inertia" and "Level" options to tuning dialog. Self-explanatory, using the "Cancel" button reverts the changes.
  • Fix Columns UI fullscreen within Panel Stack Splitter (PSS) crash and skip GDI drawing when fullscreen. GDI drawing the (transparent) background is pointless because the parent PSS window is not fullscreen'd. So, the fullscreen entry methods are disabled in this context. In addition, even if not prevented, going fullscreen and returning loses the transparent background. I think this is a bug in PSS (or Columns UI) [windows hosting other windows not dealing with the fullscreen gracefully]. Only closing and reopening the player would bring back the transparency.
  • Adjust context menu logic for improved display of enabled and disabled options. Meaning the context menu is configuration aware. For example, from the previous point, the "Fullscreen" option is grayed out when Columns UI+Panel Stack Splitter+Apply Transparency.
  • Update COM interface definition file and extend `IVUMeter` with additional methods. New interface methods include Print() and ComponentVersion(). Note, due to current architecture, there needs to be at least one instance of the VU Meter in the GUI for the COM Automation methods to not return E_POINTER error.
  • Update advanced preferences. The updated "Debug output" option displays newly-categorized console messages for easier debug.

I'll work on summarizing these points into the manual. In the meantime, enjoy.

Spoiler (click to show/hide)

Re: foo_vis_vumeter

Reply #355
0.9.5 released!

I'm very happy with how development has been going. Lots is (small but) interesting problems solved, much documentation read and unfamiliar concepts learned, several moments of frustration turned to happiness when that "eureka" insight hit. Let's also keep up the good back-and-forth we're having in this thread. Thank you to for the trust and contributing through ideas, help, discussion, and, above all, testing.

This version is completely broken on my DarkOne tweak theme.

For previous versions I'm using these commands for the skin loading...

Code: [Select]
	this.DarkOne4PEAK = function() {
fb.RunMainMenuCommand("View/Visualizations/Analog VU Meter skins/Peak Meter (Color Switch)/" + 0 + " " + display_system.display_arr[display_system.display_combi_colour]);
setTimeout(this.DarkOne4PEAK.bind(this), 150);
}

this.DarkOne4VU = function() {
fb.RunMainMenuCommand("View/Visualizations/Analog VU Meter skins/VU Meter (Color Switch)/" + 0 + " " + display_system.display_arr[display_system.display_combi_colour]);
setTimeout(this.DarkOne4VU.bind(this), 200);
}

In 0.9.5, all my meters are flickering back and forth between the two folders above. The only way to get it to stop doing that is to have one VU Meter only, which means things have reverted back to versions before 0.8.0.

Re: foo_vis_vumeter

Reply #356
0.9.5 released!

  • Fix Columns UI fullscreen within Panel Stack Splitter (PSS) crash and skip GDI drawing when fullscreen. GDI drawing the (transparent) background is pointless because the parent PSS window is not fullscreen'd. So, the fullscreen entry methods are disabled in this context. In addition, even if not prevented, going fullscreen and returning loses the transparent background. I think this is a bug in PSS (or Columns UI) [windows hosting other windows not dealing with the fullscreen gracefully]. Only closing and reopening the player would bring back the transparency.
Thx!

Just a quick reaction. In the attached screenshot I'm running 5x VU 2024 instances from CUI/PSS/JSplitter parent.
All instances are set to "Lock ratio on" and therefore don't stretch fill the parent panel they live in and therefore can show transparency of this parent panel. They all run fine and no issues with flickering needles or the like.

Of course I noticed transparency being lost when returning from fullscreen.
I paint background/art from the grandparent PSS panel (all the reddish backgrounds).
For testing purposes I changed one of the direct JSplitter parents to display a bright green background and thus overwriting the PSS painted reddish background/art.
Returning from fullscreen also the green background is lost.
PSS has nothing to do with this since the parent is a JSplitter.

Are you sure you are not disabling transparency in your code returning from fullcreen regardless of the nature of the splitter type of the parent?

Re: foo_vis_vumeter

Reply #357
0.9.5 released!

  • Fix Columns UI fullscreen within Panel Stack Splitter (PSS) crash and skip GDI drawing when fullscreen. GDI drawing the (transparent) background is pointless because the parent PSS window is not fullscreen'd. So, the fullscreen entry methods are disabled in this context. In addition, even if not prevented, going fullscreen and returning loses the transparent background. I think this is a bug in PSS (or Columns UI) [windows hosting other windows not dealing with the fullscreen gracefully]. Only closing and reopening the player would bring back the transparency.
Are you sure you are not disabling transparency in your code returning from fullcreen regardless of the nature of the splitter type of the parent?
Did an extra test. This time CUI 3.0.0 alpha-2 with just a single JSplitter which holds a VU 2024. No PSS around whatsoever.
Green background is lost after returning from fullscreen.

So PSS has nothing to do with this issue.

What I also noticed is when you switch quickly between fullscreen and no fullscreen, the green background that is painted in the JSplitter is displayed but replaced quickly by a dark background. This also happens when resizing the panel/fooBar window. So what's up?

EDIT: Added the FCL for your own testing purposes. It needs CUI, JS3, JSplitter and VU 2024.

Re: foo_vis_vumeter

Reply #358
0.9.0...



0.9.5...


Re: foo_vis_vumeter

Reply #359
In 0.9.5, all my meters are flickering back and forth between the two folders above. The only way to get it to stop doing that is to have one VU Meter only, which means things have reverted back to versions before 0.8.0.
Looks to me like you are triggering the panel swap multiple times. I don't have the setup with the nice buttons. When I do so manually from the main menu I see the expected behavior across the multiple instances.

Clarification on the expected behavior:
  • In the main menu commands there are 3 actions for each group: next, previous, set.
  • All of the foo_vis_vumeter instances are assigned into groups corresponding to their root folder (only goes one level deep).
  • Using the next and previous actions for a specific group will apply that change to only the instances whose current group matches the menu hierarchy's.
  • Using the previous action when the group skin of an instance is already the first in the list (in lexicographical order) has no effect on that instance.
  • Similarly, using the next action when the group skin of an instances is already the last in the list (in lexicographical order) has no effect.
  • In other words, the next and previous actions do not wrap around. This can be changed in future versions if that becomes the consensus/more intuitive/easier.
  • Using the set action on any menu hierarchy (i.e., selecting the skin by name directly) will apply that skin to ALL instances alike.
  • Why? Because that is how it worked in the old VU meter component.
  • Why do I believe it was done this way? Because if not, one could not use the main menu to change skins unless one wanted to swap only skins from the same group and there would be no mechanism to move instances into a different group "programmatically".

The grouping and panel swapping is completely rewritten to follow that behavior and applies to each instance independently and immediately. Previously, there was a mailbox and you'd be hoping that the instance you care about looks at it before the timeout. During the timeout period, all changes were blocked/ignored.

So, my recommendation is to use "Previous skin" and "Next skin" instead of the skin name. Since you have them in an array it should be simple to map them. And because you already have them in separate folders, the actions will only apply to those instances where those skins are active.

Re: foo_vis_vumeter

Reply #360
Of course I noticed transparency being lost when returning from fullscreen.
...
PSS has nothing to do with this since the parent is a JSplitter.

Are you sure you are not disabling transparency in your code returning from fullcreen regardless of the nature of the splitter type of the parent?
You're seeing the same issue I did, which is what led me to turn off fullscreening. I turn off the fullscreen using the service GUID of the immediate parent when that matches PSS. I didn't know that JSplitter had that ability. I'll probably have do the same until I track this issue down.

I'm very sure transparency is not disabled. It's just that there appears (to GDI) that there is nothing behind the existing window to clip. It's just using the routine marc2k3 suggested that is part of Columns UI itself. I think fullscreening screws up the parent-child relationship between the windows somehow because it works as expected during creation. In your video you can see the rounded corners still show through some green after returning from fullscreen so that is still there.

Re: foo_vis_vumeter

Reply #361
In 0.9.5, all my meters are flickering back and forth between the two folders above. The only way to get it to stop doing that is to have one VU Meter only, which means things have reverted back to versions before 0.8.0.
Looks to me like you are triggering the panel swap multiple times. I don't have the setup with the nice buttons. When I do so manually from the main menu I see the expected behavior across the multiple instances.

Clarification on the expected behavior:
  • In the main menu commands there are 3 actions for each group: next, previous, set.
  • All of the foo_vis_vumeter instances are assigned into groups corresponding to their root folder (only goes one level deep).
  • Using the next and previous actions for a specific group will apply that change to only the instances whose current group matches the menu hierarchy's.
  • Using the previous action when the group skin of an instance is already the first in the list (in lexicographical order) has no effect on that instance.
  • Similarly, using the next action when the group skin of an instances is already the last in the list (in lexicographical order) has no effect.
  • In other words, the next and previous actions do not wrap around. This can be changed in future versions if that becomes the consensus/more intuitive/easier.
  • Using the set action on any menu hierarchy (i.e., selecting the skin by name directly) will apply that skin to ALL instances alike.
  • Why? Because that is how it worked in the old VU meter component.
  • Why do I believe it was done this way? Because if not, one could not use the main menu to change skins unless one wanted to swap only skins from the same group and there would be no mechanism to move instances into a different group "programmatically".

The grouping and panel swapping is completely rewritten to follow that behavior and applies to each instance independently and immediately. Previously, there was a mailbox and you'd be hoping that the instance you care about looks at it before the timeout. During the timeout period, all changes were blocked/ignored.

So, my recommendation is to use "Previous skin" and "Next skin" instead of the skin name. Since you have them in an array it should be simple to map them. And because you already have them in separate folders, the actions will only apply to those instances where those skins are active.

So how would I add your LoadNextSkin code to the following below?

Code: [Select]
this.NotifyData = function(name, info) {
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]);
        fb.RunMainMenuCommand("View/Visualizations/Analog VU Meter skins/DarkOne4VU/" + vu_style + " " + display_system.display_arr[display_system.display_combi_colour]);
            window.Repaint(g_all);
}
}

Re: foo_vis_vumeter

Reply #362

So, my recommendation is to use "Previous skin" and "Next skin" instead of the skin name. Since you have them in an array it should be simple to map them. And because you already have them in separate folders, the actions will only apply to those instances where those skins are active.

I can get rid of the flickering but it basically reverts back to the way it was in 0.7.5 and beyond where there was only one skinloader instance. 

I have two folders in vumeter dir. One is PeakMeter and the other is VUMeter. When I change colors with 0.9.5, VUMeter turns into PeakMeter. 0.9.0 doesn't behave like this.

0.9.0



0.9.5




Please consider making future builds the way they were, otherwise DarkOne users are forever stuck on 0.9.0.

 

Re: foo_vis_vumeter

Reply #363
Of course I noticed transparency being lost when returning from fullscreen.
...
PSS has nothing to do with this since the parent is a JSplitter.

Are you sure you are not disabling transparency in your code returning from fullcreen regardless of the nature of the splitter type of the parent?
You're seeing the same issue I did, which is what led me to turn off fullscreening. I turn off the fullscreen using the service GUID of the immediate parent when that matches PSS. I didn't know that JSplitter had that ability. I'll probably have do the same until I track this issue down.

I'm very sure transparency is not disabled. It's just that there appears (to GDI) that there is nothing behind the existing window to clip. It's just using the routine marc2k3 suggested that is part of Columns UI itself. I think fullscreening screws up the parent-child relationship between the windows somehow because it works as expected during creation. In your video you can see the rounded corners still show through some green after returning from fullscreen so that is still there.
The attached screenshots are before and after returning from fullscreen with a CUI/PSS/JSplitter/VU 2024 instance.
So the blur is the PSS grandparent, and the green is the JSplitter parent. In the after fullscreen screenshot you can see green tips left top and right top of the test background of JSplitter parent.

If you cannot fix it, it's no big deal. I care about transparency and not about fullscreen.
So if you cannot fix it, I'll block fullscreen and most probably just get rid of the JSplitters and move the 5x VU 2024 instances back directly under PSS parents.

I'll leave it with you, nothing more I can test about it. Keep me informed.

Re: foo_vis_vumeter

Reply #364
@oops : I have become lost with the latest succession of rapid-fire updates.  It has become impossible to tell if some are purely in response to a test requested by a poster trying to get something to work in a "niche" fashion specific to them, and those that are general updates supplying fixes and changes relevant to all.  I don't use CUI or on-the-fly color changes, exotic loading/splitting techniques or special forms of transparency.  What is the latest version that does NOT include personalized experimentation??

For those regularly requesting the plugin to be altered to fit specific uses, why not offer a "development version" of the plugin that contains responses to their requests from a separate "nightly build" source?

Re: foo_vis_vumeter

Reply #365
@oops : I have become lost with the latest succession of rapid-fire updates.  It has become impossible to tell if some are purely in response to a test requested by a poster trying to get something to work in a "niche" fashion specific to them, and those that are general updates supplying fixes and changes relevant to all.  I don't use CUI or on-the-fly color changes, exotic loading/splitting techniques or special forms of transparency.  What is the latest version that does NOT include personalized experimentation??

For those regularly requesting the plugin to be altered to fit specific uses, why not offer a "development version" of the plugin that contains responses to their requests from a separate "nightly build" source?
The logic change in the component has nothing to do with my request for transparency.
And ... what problems do you encounter with using DUI with this version?

Re: foo_vis_vumeter

Reply #366
0.9.5 No falls back to the WARP software rasterizer if no DirectX 12-compatible adapter found.

Cardiacs

foo_vis_vumeter - VU Meter Visualisation 0.9.5.0 Crash Report and Dmp

Reply #367
These are the Crash reports for foo_vis_vumeter (2025-01-20 06:03:14 UTC)
    VU Meter Visualisation 0.9.5.0 causing Foobar 2.1.4.1 X64 to crash.

foo_vis_vumeter 0.9.5.0 Crashes FB 2.1.4.1 X64

Reply #368
Hi Folks,
Foobar has crashed when using foo_vis_vumeter (2025-01-20 06:03:14 UTC) VU Meter Visualisation 0.9.5.0 no changes from previous just an upgrade.

The crash report and dump is in the upload forum previous reply above.

Regards Mark


Moderator: text edit after merging topics

Re: foo_vis_vumeter

Reply #369
Please consider making future builds the way they were, otherwise DarkOne users are forever stuck on 0.9.0.
Let's not speak like we're at the end of the world. In enough detail explain what you want to happen and we'll work together towards that goal. I won't revert to the previous architecture but I'm very happy to help make it work like you expect either in the current version or to make changes to support the use case.

Things that will help me understand the screen grab:
  • It's a very busy image, where are the instances of VU Meter?
  • What is supposed to happen on color change? It seems to be working "similar" to the 0.9.0 version to me.
  • What do the visual ">" and "<" buttons supposed to do? What is it cycling through?
  • From your description and the animation, there are 2 main folders VU and Peak. Are they both instantiated at the same time, just the windows hidden?

Re: foo_vis_vumeter

Reply #370
0.9.5 No falls back to the WARP software rasterizer if no DirectX 12-compatible adapter found.
Yeah. I didn't think anyone was using it, it is not supposed to even be included in "Releases" as it is only for debug and, thus, the performance is really bad.

Do you really need/want it back?

Re: foo_vis_vumeter

Reply #371
Please consider making future builds the way they were, otherwise DarkOne users are forever stuck on 0.9.0.
Let's not speak like we're at the end of the world. In enough detail explain what you want to happen and we'll work together towards that goal. I won't revert to the previous architecture but I'm very happy to help make it work like you expect either in the current version or to make changes to support the use case.

Things that will help me understand the screen grab:
  • It's a very busy image, where are the instances of VU Meter?
  • What is supposed to happen on color change? It seems to be working "similar" to the 0.9.0 version to me.
  • What do the visual ">" and "<" buttons supposed to do? What is it cycling through?
  • From your description and the animation, there are 2 main folders VU and Peak. Are they both instantiated at the same time, just the windows hidden?

It's the end of the world!!!!!!!!!!!!  Ok, but seriously. The best thing to do is revisit this post (link below) from page 9. I think I nailed it on that post, because you corrected the issue soon after. The skinloader part of 0.9.5 has basically reverted back to those earlier times.

https://hydrogenaud.io/index.php/topic,126733.msg1055392.html#msg1055392


Re: foo_vis_vumeter

Reply #372
I'll leave it with you, nothing more I can test about it. Keep me informed.
Thank you so much for testing this out! I found the problem. It was due to my misunderstanding of Win32 window styles. Fixed. Not painting the transparency in fullscreen, but it is not lost in window mode after fullscreen or resizing. Also, fullscreen will be reenabled fully in Columns UI regardless of the configuration or parent container. Pseudo-transparency in JSplitter not tested.

For those looking for a working implementation, here it is. Be aware that the order of the operations is absolutely critical:
Code: [Select]
void vumeter_cui::ToggleFullScreen() noexcept
{
    EnterCriticalSection(&g_cs);
    if (!s_fullscreen)
    {
        GetWindowRect(&m_window_rect);
        CWindow(m_parent).ScreenToClient(&m_window_rect);

        ::SetWindowLongPtr(m_hWnd, GWL_STYLE, WS_POPUP);
        ::SetWindowLongPtr(m_hWnd, GWL_EXSTYLE, WS_EX_TOPMOST);
        ::SetParent(m_hWnd, ::GetDesktopWindow());
        ::SetWindowPos(m_hWnd, HWND_TOP, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_FRAMECHANGED);
        ::ShowWindow(m_hWnd, SW_MAXIMIZE);

        if (m_host->get_host_guid() != guid_foo_uie_panel_splitter)
            m_host->relinquish_ownership(nullptr);
        s_fullscreen = true;
    }
    else
    {
        LONG_PTR style = ::GetWindowLongPtr(m_hWnd, GWL_STYLE); // WS_POPUP | WS_VISIBLE | WS_CLIPSIBLINGS | WS_MAXIMIZE
        ::SetWindowLongPtr(m_hWnd, GWL_STYLE, style & static_cast<LONG_PTR>(~WS_POPUP) | static_cast<LONG_PTR>(WS_CHILD));
        ::SetWindowLongPtr(m_hWnd, GWL_EXSTYLE, 0);
        ::SetParent(m_hWnd, m_parent);
        ::SetWindowPos(m_hWnd, HWND_TOP, m_window_rect.left, m_window_rect.top, m_window_rect.right - m_window_rect.left, m_window_rect.bottom - m_window_rect.top, SWP_NOMOVE | SWP_NOZORDER | SWP_FRAMECHANGED);
        ::ShowWindow(m_hWnd, SW_NORMAL);

        if (m_host->get_host_guid() != guid_foo_uie_panel_splitter)
            m_host->relinquish_ownership(m_parent);
        s_fullscreen = false;
    }
    LeaveCriticalSection(&g_cs);
}

Re: foo_vis_vumeter

Reply #373
I'll leave it with you, nothing more I can test about it. Keep me informed.
Thank you so much for testing this out! I found the problem. It was due to my misunderstanding of Win32 window styles. Fixed. Not painting the transparency in fullscreen, but it is not lost in window mode after fullscreen or resizing. Also, fullscreen will be reenabled fully in Columns UI regardless of the configuration or parent container. Pseudo-transparency in JSplitter not tested.

For those looking for a working implementation, here it is. Be aware that the order of the operations is absolutely critical:
Code: [Select]
void vumeter_cui::ToggleFullScreen() noexcept
{
    EnterCriticalSection(&g_cs);
    if (!s_fullscreen)
    {
        GetWindowRect(&m_window_rect);
        CWindow(m_parent).ScreenToClient(&m_window_rect);

        ::SetWindowLongPtr(m_hWnd, GWL_STYLE, WS_POPUP);
        ::SetWindowLongPtr(m_hWnd, GWL_EXSTYLE, WS_EX_TOPMOST);
        ::SetParent(m_hWnd, ::GetDesktopWindow());
        ::SetWindowPos(m_hWnd, HWND_TOP, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_FRAMECHANGED);
        ::ShowWindow(m_hWnd, SW_MAXIMIZE);

        if (m_host->get_host_guid() != guid_foo_uie_panel_splitter)
            m_host->relinquish_ownership(nullptr);
        s_fullscreen = true;
    }
    else
    {
        LONG_PTR style = ::GetWindowLongPtr(m_hWnd, GWL_STYLE); // WS_POPUP | WS_VISIBLE | WS_CLIPSIBLINGS | WS_MAXIMIZE
        ::SetWindowLongPtr(m_hWnd, GWL_STYLE, style & static_cast<LONG_PTR>(~WS_POPUP) | static_cast<LONG_PTR>(WS_CHILD));
        ::SetWindowLongPtr(m_hWnd, GWL_EXSTYLE, 0);
        ::SetParent(m_hWnd, m_parent);
        ::SetWindowPos(m_hWnd, HWND_TOP, m_window_rect.left, m_window_rect.top, m_window_rect.right - m_window_rect.left, m_window_rect.bottom - m_window_rect.top, SWP_NOMOVE | SWP_NOZORDER | SWP_FRAMECHANGED);
        ::ShowWindow(m_hWnd, SW_NORMAL);

        if (m_host->get_host_guid() != guid_foo_uie_panel_splitter)
            m_host->relinquish_ownership(m_parent);
        s_fullscreen = false;
    }
    LeaveCriticalSection(&g_cs);
}
Great you solved it.

I'll await the next release or revision.

Re: foo_vis_vumeter

Reply #374
I have become lost with the latest succession of rapid-fire updates.  It has become impossible to tell if some are purely in response to a test requested by a poster trying to get something to work in a "niche" fashion specific to them, and those that are general updates supplying fixes and changes relevant to all.  I don't use CUI or on-the-fly color changes, exotic loading/splitting techniques or special forms of transparency.  What is the latest version that does NOT include personalized experimentation??

For those regularly requesting the plugin to be altered to fit specific uses, why not offer a "development version" of the plugin that contains responses to their requests from a separate "nightly build" source?
As I said above, I'm very happy with the development of the component. The code base is stable at this point, many of the major problems have been hashed out and I don't think there will be any large changes going forward. In fact, most of the changes I outlined in the last release notes are less than 10 lines.

With that, I'm with you on a lot of it. I don't use CUI or fancy anything, personally. All of the requests are "niche" at this stage. But we are all evolving the component together. And part of the fun is seeing people's creative set ups and marveling at how far they push the component. But be aware, there is no version I've released that is not experimental in some way as I'm not a corporation with a professional dev team verifying and reviewing the updates (and as I've stated before, this project is a learning endeavor first-and-foremost).

I simply do not want to spend the bandwidth to offer anything beyond what is in my "master" branch or write yet another script to publish the CI builds.

One last thought. Basic functionality will likely not break because my post-build hook copies the current build DLL over the existing one in my copy of the music player. So, if you're using a single instance of VU Meter in DUI on x64 in light mode, you are using what I do and dogfood daily. But as we've learned, if that was all the component offered, non-stop complaints and wishlists flood this forum ;)