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 271056 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_vis_vumeter

Reply #125 –
Wow, finally!  Congratulations.  You never gave up, I'll say that much, even though you switched to foo_vis_vumeter instead of JSP3 Analog VU Meter, which actually was a smart decision for a beginner.  One question though--did you install the original 32-bit only fu_vis_vumeter, or the 32-or-64 bit version by oops from this year?  Just curious.  The new one would give you more choices of meter types/skins to use (BIN, AIMP, and LVU) instead of only BIN and has more fine-tuning available.  For now though, just ENJOY WHAT YOU HAVE! ;D

BTW, checking the "lock aspect ratio" option from the right-click menu should fix the meter sizing problem your screenshot shows.

Re: foo_vis_vumeter

Reply #127 –
Quote from: telboy1812 on
i installed this 1 https://www.foobar2000.org/components/view/foo_vis_vumeter 32bit/64bit would the aimp skin or any of yours if I dropped in my skin folder
Just to clarify the credits, the skins I have posted were all authored by hiccup of the MusicBee forum, with color changes done by me with his permission.
Did you check the "lock aspect ratio" option to fix the horizontal distortion in your meters shown on your screenshot?

Re: foo_vis_vumeter

Reply #128 –
not yet

Re: foo_vis_vumeter

Reply #129 –
Quote from: oops on
I included the file specifications in the documentation for the ".bin" as well as both forms of AIMP ".zip" files. It is as I understand them. I tried to be thorough, but I'm sure there is something that was missed.

Just some clarification for the AIMP spec. There are two plugins for AIMP, the default one and LVU which you have listed as Analog and LED. The "dbs" and "orientation" parameters are actually part of the LVU spec.

I added support for using those parameters in the AIMP skin.ini file so users of my plugin could create skins with both a bar/needle and LED as this was not supported by the AIMP plugin.

In hindsight there might have been a better way to handle that to avoid user confusion down the line. I guess if your plugin supports it then it's only really an issue if someone tries to load one of these new skins in the AIMP player as the LEDs will not work.

Re: foo_vis_vumeter

Reply #130 –
@oops : one thing I noticed related to your plugin display and the AIMP analog skins BoringName mentions with both LEDs and needles.  With BoringName's VUMeter plugin, one is able to select "LED use Peak" with these meters, and the LEDs respond to the Peak values while the equivalent of RMS is shown by the needles simultaneously.  With foo_vis_vumeter, the LEDs and needles always respond in unison--to RMS if that is selected, to Peak if that level is selected.  This is the same with the BIN variant of the DejaVu calibrated meter from hiccup.

With your plugin, is there any chance of adding the option of showing RMS with needles but Peak with the LEDs on these type of AIMP skins?  There are also a few original BIN meters with dual LED and needle displays like "KD85."

Unrelated--the attached "calibrated by hiccup" AIMP meter is the definition of RESPONSIVE and smooth with foo_vis_vumeter .5.2 when set to Decay=Slow and either RMS or Peak--almost like watching a BPM meter!  Give it a try.

Re: foo_vis_vumeter

Reply #131 –
Quote from: sveakul on
With your plugin, is there any chance of adding the option of showing RMS with needles but Peak with the LEDs on these type of AIMP skins?
Implemented in 0.5.3.

Quote from: sveakul on
Unrelated--the attached "calibrated by hiccup" AIMP meter is the definition of RESPONSIVE and smooth with foo_vis_vumeter .5.2 when set to Decay=Slow and either RMS or Peak--almost like watching a BPM meter!  Give it a try.
That was the meter that uncovered the large pivot point issue fixed in 0.5.2. Definitely unique and useful.

Re: foo_vis_vumeter

Reply #132 –
Quote from: BoringName on
Just some clarification for the AIMP spec. There are two plugins for AIMP, the default one and LVU which you have listed as Analog and LED. The "dbs" and "orientation" parameters are actually part of the LVU spec.

I added support for using those parameters in the AIMP skin.ini file so users of my plugin could create skins with both a bar/needle and LED as this was not supported by the AIMP plugin.

In hindsight there might have been a better way to handle that to avoid user confusion down the line. I guess if your plugin supports it then it's only really an issue if someone tries to load one of these new skins in the AIMP player as the LEDs will not work.
I was aware of the LVU (LumaVU) and AIMP analog distinction. It's just confusing for to call them that for those unfamiliar with AIMP. When the component reads the AIMP analog INI, the stuff tacked on to the analog one from LVU is optional. I don't know of any formal spec definition for either of these, but I haven't scoured all of the forums/documentation. Nor do I have AIMP installed. So, what you see in the component is my "artistic" interpretation/assumption on how these INI parameters come together to describe the visualization's behavior. As for the orientation parameter, the only thing I thought about it being for is a top-to-bottom or right-to-left meter. But I couldn't find an example to test, so left it unused--"if you didn't test it, it doesn't work."

Through a similar thought process, I ignore the mobility parameters from the AIMP analog INI because they don't match the RC growth/decay approach I'm taking to describing the needle movement. I prefer this approach to using unreferenced/user-supplied numbers as that is what I observe most closely matches the real circuit behavior on the oscilloscope (and the roots of the galvanometer differential equations confirm this). In particular understanding decay is tricky, which is why I decided to put both presets on top of the full user tuning in the options as these time constants can be tricky to intuitively understand. Specific information of what the instantaneous step and pulse behavior of the needle is documented here. But the tuning is there because what I've observed is most people (especially young kids) prefer it to look "nice and jumpy and smooth" over accurate which "dances badly".

Re: foo_vis_vumeter

Reply #133 –
Quote from: oops on
As for the orientation parameter, the only thing I thought about it being for is a top-to-bottom or right-to-left meter.

That's exactly what it is. Because it starts at the top, for vertical meters (orientation=1) the images are reversed. The LED are part of the background image and l.png/r.png are the section of the background without LED. They cover the LED and less of them is displayed as the peak value increases.

Example here - Sony TC K60

Quote from: oops on
Through a similar thought process, I ignore the mobility parameters from the AIMP

I just timed the needle rise and fall from 0 to 1.0 and back in AIMP a bunch of times with the stop watch on my phone and tried to match it. I didn't quite get it dead on but I'm happy with how it's turned out. I'm not sure if AIMP was the best implementation as some of the meters can be very jittery in that player.

Re: foo_vis_vumeter

Reply #134 –
Quote from: BoringName on
Example here - Sony TC K60
Perfect. Implemented it in 0.5.4 and updated the documentation.

Quote from: BoringName on
I just timed the needle rise and fall from 0 to 1.0 and back in AIMP a bunch of times with the stop watch on my phone and tried to match it. I didn't quite get it dead on but I'm happy with how it's turned out. I'm not sure if AIMP was the best implementation as some of the meters can be very jittery in that player.
That's fine. The downside of that is that you get linear movement (same speed through the jump), whereas the real thing is non-linear: it accelerates from a stop and then decelerates to stop. So instead of guessing/copying what others' interpretations are, decided to look at some real circuits which are mostly variations of a simple integrator. To a first approximation, they tune the RC time constant such that the needle/galvanometer achieves the 300ms rise/fall times for a step input. The rise and decay factors in the component represent this time constant. And consequently, it is why I've modelled the movement in this component through an exponential relationship.

Re: foo_vis_vumeter

Reply #135 –
Quote from: oops on
And consequently, it is why I've modelled the movement in this component through an exponential relationship.

I have absolutely no doubt your approach is better. I took the path of least resistance.

Supporting Foobar skins was a pipe dream until you helped me out. I thought I was good at problem solving but no way in hell I ever would have figured that out.

On one hand I'm really not the best candidate for creating these plugins as I have very little experience with audio related data and not much more with programming to be honest. Until a month or two ago I'd never even heard of RMS. On the other hand, users were asking for a VU meter with Musicbee and no one else was doing it so here we are.

Re: foo_vis_vumeter

Reply #136 –
Quote from: BoringName on
I have absolutely no doubt your approach is better. I took the path of least resistance.

Supporting Foobar skins was a pipe dream until you helped me out. I thought I was good at problem solving but no way in hell I ever would have figured that out.

On one hand I'm really not the best candidate for creating these plugins as I have very little experience with audio related data and not much more with programming to be honest. Until a month or two ago I'd never even heard of RMS. On the other hand, users were asking for a VU meter with Musicbee and no one else was doing it so here we are.
Don't put yourself down! It's a game of tradeoffs. No shame in taking the path of least resistance. You're more than killing it with your plugin.

Re: foo_vis_vumeter

Reply #137 –
@oops :  this newly revised BIN plugin by hiccup works perfectly in MusicBee but will crash the whole Foobar 2.24 x64 if I try to load it into foo_vis_vumeter .54.  Is that something you can fix on your end?



P.S. Thank you for adding the ability for AIMP meters with both LEDs and needles to show RMS with the needles and Peak with the LEDs.  Can this be done for BIN meters like this one too?  And, can that be added as a selectable option in the context menu?  Wow I don't ask for much do I  :-[

Re: foo_vis_vumeter

Reply #139 –
Friend you added the stock Foobar "VU Meter".  You need to add the one listed after that, "VU Meter (DX12),"  THAT is the foo_vis_vumeter plugin.

Re: foo_vis_vumeter

Reply #140 –
That screenshot is Columns UI. This component is default UI only.

Re: foo_vis_vumeter

Reply #141 –
a update i    found direct 12 somewhere and produced this i believe in the view menu

Re: foo_vis_vumeter

Reply #142 –
ok thank you

Re: foo_vis_vumeter

Reply #143 –
how do you choose the skin vu meter (directX 12)

Re: foo_vis_vumeter

Reply #144 –
Quote from: sveakul on
@oops :  this newly revised BIN plugin by hiccup works perfectly in MusicBee but will crash the whole Foobar 2.24 x64 if I try to load it into foo_vis_vumeter .54.  Is that something you can fix on your end?
Yes, this is a bug. I'm testing the fix.

Re: foo_vis_vumeter

Reply #145 –
Quote from: telboy1812 on
how do you choose the skin vu meter (directX 12)
Are you trying to B.S. us??  You send a screenshot with the meter already on it, then ask how do you find the meter.  I'm through holding hands with this one.

Re: foo_vis_vumeter

Reply #147 –
Quote from: sveakul on
P.S. Thank you for adding the ability for AIMP meters with both LEDs and needles to show RMS with the needles and Peak with the LEDs.  Can this be done for BIN meters like this one too?  And, can that be added as a selectable option in the context menu?  Wow I don't ask for much do I  :-[
Implemented in 0.5.7. Now RMS+Peak doesn't happen by default, it is instead selectable through the "Levels->Mixed" option. I've added an explanation for it to the documentation.

Also fixed the stop behavior for the LEDs in "Mixed" mode (they "turn off" when player stopped).

Lastly the crash should not happen anymore for the .bin file inside the RAR archive above. The base offset for the second meter when the file includes both sides and also LEDs was calculated incorrectly leading to out-of-bounds accesses.

Thanks for bringing all these issues to my attention.

Re: foo_vis_vumeter

Reply #148 –
Reporting a corner case bug, not sure if it should go here or main foobar.

Scenario:
  • fb 64bit portable installation with 64bit VU meter 0.5.4
  • ZIP up the portable fb directory
  • copy portable installation inside VM (vmware) for testing (I wanted to test some VST without installing on my main rig)
  • UNZIP the portable fb directory inside VM
  • VM does not have DirectX

When starting foobar inside the VM, it crashes out (foobar does not even open the main window).
Through trial and error I found out it was due to the lack of DirectX.
I didn't expect the above scenario to prevent foobar from starting up.

Workaround: go inside profile user-components-x64, and delete away foo_vis_vumeter folder; then foobar can start.

Reporting just FYI ... it's a very corner use case ... not critical ...

Re: foo_vis_vumeter

Reply #149 –
Quote from: boxerfan88 on
Scenario:
When starting foobar inside the VM, it crashes out (foobar does not even open the main window).
Through trial and error I found out it was due to the lack of DirectX.
I didn't expect the above scenario to prevent foobar from starting up.
That is a VMware issue or configuration issue of the VM, that is something I cannot fix. If you have Windows 10 or later, DirectX is part of the OS, so it most definitely installed. All my VMs using Hyper-V pass the hardware correctly and DirectX is supported out of the box with both foobar2000 and this component running without issue (see `dxdiag`).

For that reason, I would consider unable to create/acquire the DirectX device a critical issue and stopping the application is the right course of action (maybe could be done in a more informational/user-friendly way though). Plus, it is the least of your problems since much of the OS shell is hardware accelerated using Direct2D and the like. I also would assume several of the built-in visualizations use Direct2D so if you include those in the UI, do they cause any issues?