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 74778 times) previous topic - next topic
0 Members and 36 Guests are viewing this topic.

Re: foo_vis_vumeter

Reply #275
Oops, thanks for 0.8.2. With regards to the new Configure (Tuning) options, I was curious what "Panel" is for. To me it seems to imply that you can have independent settings for each VU Meter, but that doesn't seem to be the case.
Just displays and can change the panel/skin of the instance from where the dialog was launched. Since it is the only instance-capable options it is kind of a howto for how one would extend the dialog functionality to do more complex behaviors.

Just thought I'd mention that I also have this issue. I know it's minor but hopefully something can be done about it in the future.
I am investigating.

Some minor feedback about the "Configure" screen.
  • mouse wheel behavior is opposite of tuning menu (tuning menu -- roll up is increase)
  • mouse wheel step differs from tuning menu (eg. gain -- tuning menu, one wheel stop is 1dB)
I prefer the tuning menu behavior :)
The steps are the minimum size steps because I assumed one would want full control when using the dialog. Scrubbing is the primary way of setting the value close to what you'd want. After scrubbing you could use the direction keys or the mouse wheel for finer-grain control. I noticed the direction inversion as well. It is kind of jarring but the trackbar does not propagate the mouse wheel message, so I don't know how to make it consistent...yet.

PLEASE don't diss the new "Configure" screen!  What could be more intuitive than a visible pointer moved by the mouse pointer, right + and left -, with a changing real-time value visible the whole time.  I am not a fan of "mouse wheeling" for tuning.
No, no, don’t get me wrong.
Not dissing … just suggesting tweaks … i am very very glad to have the configure panel.
Positive and negative feedback are welcome. No one's feelings are getting hurt. I make decisions based on what is easy, practical or intuitive to myself at the time. There might be better ideas, different ways of approaching a problem, things I haven't noticed in my, admittedly limited, testing. We're having a good discussion.

I am curious though also on the point raised by Majestyk, if that could be clarified.
See above. Basically, there are component-based options and instance-based options. The "Configure" dialog supports both.

I do not understand, I cannot remove a frame, fill the screen and paint it in front. I only control and can paint the window/panel I designate for VUmeter to live in. If Fullscreen is selected in this VUmeter or the VUmeter is doubleclicked, I have no way of knowing/acting upon this action. CUI/PSS responds with an instant foobar crash.

Preferences as in main fooBar Preferences. There is no mention of colour 23-23-23 anywhere.
Even if I switch to Light Mode (Preferences - Display - Columns UI - Colours and fonts - Mode) the colour used for unselected slider and selected slider stays the same.  Everything else is correctly changed to Light mode.
What I was trying to get to with that snippet is show you what Windows operations are being performed so that you can get a head start in root causing the crash.
As far as the colors go, those seem to be the default track bar control colors. I don't think you will find them anywhere as they are not part of the Windows system colors. They appear to work through that notification system I alluded to.

Re: foo_vis_vumeter

Reply #276
If Fullscreen is selected in this VUmeter or the VUmeter is doubleclicked, I have no way of knowing/acting upon this action. CUI/PSS responds with an instant foobar crash.
@Majestyk

I think you are using a modified DarkOne skin too with CUI/PSS.
What happens if you select fullscreen on a DirectX12 VUmeter?

Re: foo_vis_vumeter

Reply #277
If Fullscreen is selected in this VUmeter or the VUmeter is doubleclicked, I have no way of knowing/acting upon this action. CUI/PSS responds with an instant foobar crash.
@Majestyk

I think you are using a modified DarkOne skin too with CUI/PSS.
What happens if you select fullscreen on a DirectX12 VUmeter?

Yes, I have a modified DarkOne skin and I do not get a crash with fullscreen on a DirectX12 VUmeter. I do not use PSS, however. I use JSplitter, instead. This was on a 64-bit build.

Later today I'll install the oops VUMeter on a 32-bit build and see what happens.

Re: foo_vis_vumeter

Reply #278
If Fullscreen is selected in this VUmeter or the VUmeter is doubleclicked, I have no way of knowing/acting upon this action. CUI/PSS responds with an instant foobar crash.
@Majestyk

I think you are using a modified DarkOne skin too with CUI/PSS.
What happens if you select fullscreen on a DirectX12 VUmeter?
Yes, I have a modified DarkOne skin and I do not get a crash with fullscreen on a DirectX12 VUmeter. I do not use PSS, however. I use JSplitter, instead. This was on a 64-bit build.

Later today I'll install the oops VUMeter on a 32-bit build and see what happens.
Until now I only used JSplitter to replace (all) SMP panels.

I can confirm the fullscreen crash is strictly related to the nature of the direct parent splitter (PSS in my case).

The crashing layout:
PSS toplevel (lots of code) \ PSS sublevel 1 (lots of code) \ PSS sublevel 2 (lots of code) \ PSS (no code) \ VUmeter. This crashes when going fullscreen.

Modified layout:
PSS toplevel (lots of code) \ PSS sublevel 1 (lots of code) \ PSS sublevel 2 (lots of code) \ JSplitter (no code) \ VUmeter. This does NOT crash when going fullscreen.

Some findings in the layout with JSplitter:
1) Resizing the foobar window after fullscreen and back to non-fullscreen is ugly (shows the flashing (hidden) caption in on top of the JSplitter VUmeter during the resize).
2) Exiting and restarting foobar crashes startup in 50% of the cases. Crash location is variable, I've seen kernelbase and foo_uie_eslyrics.

I'm totally unfamiliar how to use JSplitter with panel(s) underneath instead of a loaded script, but I'll do some more testing to get the JSplitter solution a bit more stable.

Anyway, the fullscreen crash is PSS related.

Re: foo_vis_vumeter

Reply #279
For those interested, I have made the mouse wheel direction match between the dialog box configuration and the regular tuning. Down -> decreases, up -> increases.

Also, I improved the stepping using the keyboard arrow keys and paging keys. Arrow keys generally step one unit of the minimum for each parameter and paging keys step some multiple of that such as 10 or 5, depending on the parameter.

The stepping I've not yet figured out how to control is the mouse wheel in the dialog. Working on it.

Re: foo_vis_vumeter

Reply #280
For those interested, I have made the mouse wheel direction match between the dialog box configuration and the regular tuning. Down -> decreases, up -> increases.

Also, I improved the stepping using the keyboard arrow keys and paging keys. Arrow keys generally step one unit of the minimum for each parameter and paging keys step some multiple of that such as 10 or 5, depending on the parameter.

The stepping I've not yet figured out how to control is the mouse wheel in the dialog. Working on it.

Thank you so much for working on these tweaks. Much appreciated!

Re: foo_vis_vumeter

Reply #281
Release 0.8.3 is up. The only changes are to the configuration dialog box. Hopefully the controls and their behavior are more intuitive.

Re: foo_vis_vumeter

Reply #282
Release 0.8.3 is up. The only changes are to the configuration dialog box. Hopefully the controls and their behavior are more intuitive.

Definitely yes. Thank you for this release!


Re: foo_vis_vumeter

Reply #284

Until now I only used JSplitter to replace (all) SMP panels.

I can confirm the fullscreen crash is strictly related to the nature of the direct parent splitter (PSS in my case).

The crashing layout:
PSS toplevel (lots of code) \ PSS sublevel 1 (lots of code) \ PSS sublevel 2 (lots of code) \ PSS (no code) \ VUmeter. This crashes when going fullscreen.

Modified layout:
PSS toplevel (lots of code) \ PSS sublevel 1 (lots of code) \ PSS sublevel 2 (lots of code) \ JSplitter (no code) \ VUmeter. This does NOT crash when going fullscreen.

Some findings in the layout with JSplitter:
1) Resizing the foobar window after fullscreen and back to non-fullscreen is ugly (shows the flashing (hidden) caption in on top of the JSplitter VUmeter during the resize).
2) Exiting and restarting foobar crashes startup in 50% of the cases. Crash location is variable, I've seen kernelbase and foo_uie_eslyrics.

I'm totally unfamiliar how to use JSplitter with panel(s) underneath instead of a loaded script, but I'll do some more testing to get the JSplitter solution a bit more stable.

Anyway, the fullscreen crash is PSS related.

Just for fun I went to one my older PSS DarkOne builds and I can confirm this. Do you need fullscreen? I personally never use it. Maybe if you beg oops, he can add an option to disable and grey out the Fullscreen entry. :)

Re: foo_vis_vumeter

Reply #285
Anyway, the fullscreen crash is PSS related.
Just for fun I went to one my older PSS DarkOne builds and I can confirm this. Do you need fullscreen? I personally never use it. Maybe if you beg oops, he can add an option to disable and grey out the Fullscreen entry. :)
No, I don't need fullscreen. Looks ugly anyway when aspect ratio is not locked.

I asked @pqyt to grey out his fullscreen option and disable doubleclick on his foo_vis_spectrum_analyzer component, but he never did.

BTW. I tested my proof of concept of using JSplitter from within a PSS parent a bit more but starting/exiting foobar keeps getting random crashes, so I went back to PSS as a parent for foo_vis_vumeter. Quite impossible for me to get rid of PSS, I use a total of 944KB code in 12 PSS panels.

Re: foo_vis_vumeter

Reply #286
@oops

I'm using foobar x86/CUI/PSS.

I managed to find a workaround to enable your component to work in CUI/PSS without crashing when going fullscreen or restarting foobar.

VU = foo_vis_vumeter 0.8.3.0
SA = foo_vis_spectrum_analyzer 0.8.0.0 beta2

Old situation when going fullscreen:
Parent PSS - VU - instant foobar crash, but foo_ui_columns.dll.cfg still intact, so no issues on restart of foobar.
Parent PSS - SA - instant foobar crash, but foo_ui_columns.dll.cfg still intact, so no issues on restart of foobar.
Parent PSS - built-in oscilloscope and Shpeck - no issues.

I then wrapped all SA instances (10 with different presets) as single panels under 10 JSplitters. Parent JSplitter - SA has no issues going fullscreen and back. So that problem I had is solved.

Wrapping a VU as a single panel under a JSplitter has a different result. What you would normally do in this situation is setting the VU skin to disable aspect ratio and maximize the VU panel within the JSplitter by it's caption before you hide the caption. Looks great and going fullscreen and back again works too without issues.
Upon exiting foobar however some (in ~70% of the cases) illegal info is written is written to foo_ui_columns.dll.cfg which will give you an error upon restarting foobar. The only way to solve it is to delete foo_ui_columns.dll.cfg, restart foobar and import your last saved FCL.
This error also occurs when you only maximize the VU panel within the JSplitter by it's caption before you hide the caption and do not go fullscreen and back. In other words it is already triggered by doubleclicking the VU panel caption within it's JSplitter parent.

When you wrap a VU as a single panel under a JSplitter and do not maximize it by it's caption everything works fine including fullscreen and back without killing foo_ui_columns.dll.cfg on exit.
However this looks ugly since you can only used a fixed width/height as a panel for VU to live in.

The solution is to have some code that is put in the parent JSplitter, which forces the VU panel to be sized to maximum available width/height without the VU panel being maximized by it's caption. I attached the code.

Summarized hereunder is the minimal working solution for me which enables fullscreen and does not crash on restarting foobar (all parent panels live under at least one grandparent PSS):
Parent PSS   - Shpeck/Oscilloscope
Parent JSplit   - SA
Parent JSplit   - VU, VU panel not maximized by it's caption with extra JSplit code to utilize full panel

I am now running up to 10 instances of SA and 5 instances of VU without issues. All can go fullscreen and back. No issues on restart of foobar.

I still consider the combination CUI/PSS/JSplit/VU as bugged at least partially caused by VU, since CUI/PSS/JSplit/SA works without any adjustment and does not kill foo_ui_columns.dll.cfg upon exiting foobar.
Please investigate.

Re: foo_vis_vumeter

Reply #287
oops, with Fullscreen I've noticed an issue when going from Fullscreen back to normal view. I think it's only an issue on very small screen sizes (or you can see it when you drag foobar's window to a small size) but I think it should be addressed.

Here's my peakmeter BEFORE Fullscreen is activated...



And here is my peakmeter AFTER exiting Fullscreen...



It took me awhile to figure out what was going on and then I noticed for a brief moment (after exiting CUI's Layout, in Prefs) this window that should not be there...



This is why the peakmeter doesn't always scale properly when exiting Fullscreen, because the window (although invisible) still remains. I'm not even sure if you want that window at all, it is definitely present in Fullscreen as well, you just can't see it. I know this because I can click the invisible close button in the top right corner.


Re: foo_vis_vumeter

Reply #288
oops, with Fullscreen I've noticed an issue when going from Fullscreen back to normal view. I think it's only an issue on very small screen sizes (or you can see it when you drag foobar's window to a small size) but I think it should be addressed.
I noticed this too, but I think/thought it is more of a JSplitter issue.

JSplit draws the caption around VU and clearly thinks there's more height than there actually is.

Re: foo_vis_vumeter

Reply #289
oops, with Fullscreen I've noticed an issue when going from Fullscreen back to normal view. I think it's only an issue on very small screen sizes (or you can see it when you drag foobar's window to a small size) but I think it should be addressed.
I noticed this too, but I think/thought it is more of a JSplitter issue.

It's not JSplitter. It happens on PSS too. I don't even need to go into Fullscreen (which is good because it crashes). I just have to drag fb2k to a smaller size and it happens. I'll make an animated GIF.

EDIT... I won't bother with the animation. The PSS looks exactly like my 2nd (of three photos) in my post above.

Re: foo_vis_vumeter

Reply #290
oops, with Fullscreen I've noticed an issue when going from Fullscreen back to normal view. I think it's only an issue on very small screen sizes (or you can see it when you drag foobar's window to a small size) but I think it should be addressed.
I noticed this too, but I think/thought it is more of a JSplitter issue.

It's not JSplitter. It happens on PSS too. I don't even need to go into Fullscreen (which is good because it crashes). I just have to drag fb2k to a smaller size and it happens. I'll make an animated GIF.

EDIT... I won't bother with the animation. The PSS looks exactly like my 2nd (of three photos) in my post above.
Yes you are absolutely right.

Problem occurs after coming back from fullscreen and only on the VU instance that was put in fullscreen.

EDIT: Spectrum Analyzer from a JSplitter does not suffer from this.


EDIT2: Only happens with me after fullscreen. Does not happen while making the available window smaller, maybe because the JSPL code I added.

Re: foo_vis_vumeter

Reply #291
Ok, I couldn't resist posting some more animated GIF's. :)

This my modded Darkone with the original VU Meter with JSplitter, being dragged.



Now I'm dragging the oops VU Meter with JSPlitter, plus I'm activating Fullscreen.



Lastly, I'm dragging the oops VU Meter with Panel Stack Splitter.



Ok I'll comment on this... Firstly, notice how smooth the Original VU Meter is when dragging. And yes I know dragging the window is meaningless, but I just thought I'd illustrate this compared to the others.

Second, notice how the oops VU Meter using JSplitter struggles to stay in place while dragging. Again, I know dragging is meaningless and this alone is not an issue. But watch what happens when Fullscreen is selected. Now it has some strange white artifacting when dragging (which is more than likely the 'window frame' that I have shown in post #287).  Also, the VU Meter coordinates go astray after Fullscreen is activated...although it only seems to affect a smaller screen area.

Third... The oops VU Meter with PSS has a really tough time when dragging. It goes blurry and blinks on and off. Again, not a real issue. However, it does have the coordinate issue... and in this case Fullscreen (which doesn't work with PSS) doesn't need to be activated.






Re: foo_vis_vumeter

Reply #292
@Majestyk

I have the same findings in my CUI/PSS skin and I had the same issues you had testing JSplit oops VU with the 'window frame' while dragging, but don't suffer from that anymore.

I attached a video that is comparable with your second gif.

It contains 5x JSplit with oops VU (under a PSS) and 4x JSplit with pqyt Spectrum Analyzer (under a PSS).
All JSplit are set to use pseudo-transparency and use my bit of code to drive the underlying plugin. All panel configs within JSplit are set to caption off (after the caption was not maximized).
All VU are set to not locked aspect ratio.

As you can see in the video there is no 'window frame' white artifact (caption? or non-painted JSplit background) you suffer from in any of my 5 JSplit VU instances and 4 JSplt SA instances.
I did not go fullscreen, so the coordinates bug was not activated.

Re: foo_vis_vumeter

Reply #293
@oops

Request for Change

1) option in settings "disable fullscreen" which deactivates the fullscreen context and disables the doubleclick to go fullscreen.
Reason: CUI/PSS/VU will instantly crash fooBar.

2) option in settings to activate/deactivate "fullscreen lock aspect ratio".
Reason: I don't use VU lock aspect ratio in the skin itself and I provide a window to PSS/JSplit/VU that has reasonable aspect ratio's. However if you click fullscreen in that case the whole screen is filled and very ugly.

3) option in settings to enable pseudotransparency.
Reason: CUI, PSS, JSplit, SMP, JS3, JS2, WSH all support it. Lots of plugins too and it looks very nice. How is it done? Copy the screen underneath the window where the VU will live in and display this bitmap as background.



Re: foo_vis_vumeter

Reply #296
There is a bug in your project.
Meters work in mono mode when R-128 is chosen.
I can confirm this in 0.8.3 with both BIN and AIMP meters.
Sorry to say that a single value output is all I can get from the ebur128 library when using its interface. If you read the technical paper, that one value is the objective of the loudness calculation. However, don't confuse "monoaural" (as in down mixing) with what is displayed because the internal state of the library for the calculation does use multi-channel data (up to home theater 5.0 audio). The component displays that single loudness (LUFS) value calculated by the library in all meters.

In the BS.1770 mode's calculation, because I implemented it from the paper, I grab data at different points to get per-channel loudness. The downside is that because the final summation is not displayed in the meters, the individual channel values will appear "too low". Note: I do calculate the final channel summation, and you can display it if you select Mono layout.

So, you have two options. Each option has different tradeoffs.

Re: foo_vis_vumeter

Reply #297
1) option in settings "disable fullscreen" which deactivates the fullscreen context and disables the doubleclick to go fullscreen.
Reason: CUI/PSS/VU will instantly crash fooBar.

2) option in settings to activate/deactivate "fullscreen lock aspect ratio".
Reason: I don't use VU lock aspect ratio in the skin itself and I provide a window to PSS/JSplit/VU that has reasonable aspect ratio's. However if you click fullscreen in that case the whole screen is filled and very ugly.

3) option in settings to enable pseudotransparency.
Reason: CUI, PSS, JSplit, SMP, JS3, JS2, WSH all support it. Lots of plugins too and it looks very nice. How is it done? Copy the screen underneath the window where the VU will live in and display this bitmap as background.
  • Implemented option to disallow. I use fullscreen, so it will never be removed as an option/feature and it will be enabled/allowed by default.
  • Don't know what you mean.
  • I've tried several things. WS_EX_LAYERED/WS_EX_TRANSPARENCY either don't work or tank the DirectX performance on top of causing funny effects on the layout. I tried blit'ing the background into a bitmap (using SRCCPY) but that didn't work. None of it seems to play nicely with DirectX. I'm sure there is a way of doing it, but I don't know it. Sorry.

As for the other stuff @Defender and @Majestyk, I just don't have a setup to test and reproduce most of what you're showing. I'm flummoxed when trying to understand the different permutations. My usage is substantially simpler. You would laugh at the noob if I shared a shot of my player window.

The jumpiness during the resize, I'm thinking is due to just using WM_EXITSIZEMOVE to do resizing. For performance reasons, I also do not draw during resizing and only restart the timer and redraw the client area on completion of the window size change. Speaking of which, I rely on the GetClientRect() function to get the window bounds to draw in. Both DUI and CUI do a lot of funny business to the window. After I create the original window, I just draw in the square I'm given. There is definitely a possibility that my calculations are incorrect. But from the experience getting certain things to work, I bet my role in some of the misbehavior is not the leading cause.

Re: foo_vis_vumeter

Reply #298
  • Implemented option to disallow. I use fullscreen, so it will never be removed as an option/feature and it will be enabled/allowed by default.

Thanks!

Re: foo_vis_vumeter

Reply #299
1) option in settings "disable fullscreen" which deactivates the fullscreen context and disables the doubleclick to go fullscreen.
Reason: CUI/PSS/VU will instantly crash fooBar.

2) option in settings to activate/deactivate "fullscreen lock aspect ratio".
Reason: I don't use VU lock aspect ratio in the skin itself and I provide a window to PSS/JSplit/VU that has reasonable aspect ratio's. However if you click fullscreen in that case the whole screen is filled and very ugly.

3) option in settings to enable pseudotransparency.
Reason: CUI, PSS, JSplit, SMP, JS3, JS2, WSH all support it. Lots of plugins too and it looks very nice. How is it done? Copy the screen underneath the window where the VU will live in and display this bitmap as background.
  • Implemented option to disallow. I use fullscreen, so it will never be removed as an option/feature and it will be enabled/allowed by default.
  • Don't know what you mean.
  • I've tried several things. WS_EX_LAYERED/WS_EX_TRANSPARENCY either don't work or tank the DirectX performance on top of causing funny effects on the layout. I tried blit'ing the background into a bitmap (using SRCCPY) but that didn't work. None of it seems to play nicely with DirectX. I'm sure there is a way of doing it, but I don't know it. Sorry.

As for the other stuff @Defender and @Majestyk, I just don't have a setup to test and reproduce most of what you're showing. I'm flummoxed when trying to understand the different permutations. My usage is substantially simpler. You would laugh at the noob if I shared a shot of my player window.

The jumpiness during the resize, I'm thinking is due to just using WM_EXITSIZEMOVE to do resizing. For performance reasons, I also do not draw during resizing and only restart the timer and redraw the client area on completion of the window size change. Speaking of which, I rely on the GetClientRect() function to get the window bounds to draw in. Both DUI and CUI do a lot of funny business to the window. After I create the original window, I just draw in the square I'm given. There is definitely a possibility that my calculations are incorrect. But from the experience getting certain things to work, I bet my role in some of the misbehavior is not the leading cause.
ad 1) Thx! Now fooBar CUI is protected from crashing trying to fo fullscreen in a VU that has PSS as a parent.

ad 2) I'm just asking for a separate option lo lock/unlock aspect ratio for fullscreen. I attached a mockup of what I mean ans also included some screenshots what happens with a long/narrow skin I just made.

ad 3) Thank you for trying. I know there are two active (?) developers around that successfully implemented this feature recently. @marc2k3 with JS3 (and subsequently all written scripts for JS3. @Case with the wave minibar mod. Would be nice if they would point you in the right direction.
In the meanwhile I will try to make a portable version of a small CUI/PSS/JSplitter skin which makes things easier to test.