VUMeter Plugin

[hiccup]

New version - VUMeter2.5.zip
Changes
- Small improvements to needle movement. It should be a little less shaky. This will most likely be the final change I'll make in this regard.

Having been the instigator/tester for this needle action update, I'd like to mention that I believe it is more than only improving on some 'shakiness'.
In my opinion it has improved on 'following the music' a bit tighter, the needle action even being a bit faster in responding to larger changes in volume, and in general a substantial improvement on making the needle action agree more with what I am hearing.

Maybe this deserves taking a fresh look at the rise/fall settings of existing VU meter skins and adjusting them a tiny bit for this update, but that probably won't be needed or improve things further much.

[BoringName]

If you implement something for this, I don't think it should be operating automatically in the background.
Users tend to forget/misunderstand any setting in any software that changes their files, and will start complaining about it sooner or later.

Agreed. Probably too much potential for issues. I think I'll drop the idea.

[hiccup]

After creating a clean install of MusicBee and installing v2.5.0 of the plugin, selecting a VU meter skin triggered this error message:

Code

MusicBee v3.6.9091.35714P  (Win10.0), 24 Nov 2024 16:30:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Parameter is not valid.
   at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)
   at MusicBeePlugin.VUMeter.DrawFooFrame(Int32 frameNum, Int32 ledFrameNum, Boolean left)
   at MusicBeePlugin.VUMeter.DrawFoobarSkin()
   at MusicBeePlugin.VUMeter.OpenGLControl_OpenGLDraw(Object sender, OpenGLRoutedEventArgs args)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at System.Windows.RoutedEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.UIElement.RaiseEvent(RoutedEventArgs e)
   at SharpGL.WPF.OpenGLControl.DoRender()
   at MusicBeePlugin.VUMeter.RenderEventProcessor(Object myObject, EventArgs myEventArgs)
   at System.Windows.Forms.Timer.OnTick(EventArgs e)
   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

the skin: Fischer's Lovebird
this is how it looked when the error was thrown:

(I hadn't been able to set the correct orientation for it yet)

After clicking the error away and continuing, and later restarting MB things seemed fine.
But at a certain moment I got the exact same error message again using a different but similar 'Compact LED' skin.

[sveakul]

With the same combination of the new 2.5 plugin and MB version I am also getting the error message below, not every time but often when trying to adjust suddenly difficult skin layouts of the LED combo meters of both BIN and AIMP format, and sometime just when swapping skins, just now from Lovebird LED to AL-65 (BIN).  It seems like layout options have to be overly "fiddled" with.  Cannot be predicted but can be seen fairly quickly once you start changing skins.  Error message is always the same (I have W11 not W10 as indicated in the header).  Never occurred with plugin version 2.4.

Code

MusicBee v3.6.9091.35714P  (Win10.0), 24 Nov 2024 14:23:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Parameter is not valid.
   at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)
   at MusicBeePlugin.VUMeter.DrawFooFrame(Int32 frameNum, Int32 ledFrameNum, Boolean left)
   at MusicBeePlugin.VUMeter.DrawFoobarSkin()
   at MusicBeePlugin.VUMeter.OpenGLControl_OpenGLDraw(Object sender, OpenGLRoutedEventArgs args)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at System.Windows.RoutedEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
   at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.UIElement.RaiseEvent(RoutedEventArgs e)
   at SharpGL.WPF.OpenGLControl.DoRender()
   at MusicBeePlugin.VUMeter.RenderEventProcessor(Object myObject, EventArgs myEventArgs)
   at System.Windows.Forms.Timer.OnTick(EventArgs e)
   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[BoringName]

I can reproduce this. I'll look into it.

[BoringName]

New version - VUMeter2.5.1.zip

Changes
- Fixed the intermittent loading error with Foobar skins.

This should have been an issue since I moved the foobar loading into a separate thread. Maybe the more responsive menu gave it more opportunity to trigger.

[sveakul]

Appears fixed, thank you!

[sveakul]

Just FYI, the new 0.7.2 version of oops' foo_vis_vumeter can play BIN files directly from a RAR.  No space savings of course, but it keeps hiccups' .INI files, which it supports, neatly in the same package.  Maybe same could be added for VUMeter?

[BoringName]

Just FYI, the new 0.7.2 version of oops' foo_vis_vumeter can play BIN files directly from a RAR.  No space savings of course, but it keeps hiccups' .INI files, which it supports, neatly in the same package.  Maybe same could be added for VUMeter?

I'm not that keen on supporting multiple layers of archives.

What happens with oops version if you dump a RAR in the skin folder that contains multiple bin files?

[boroda]

However, the bin files come in a lot of flavours. 3 different types of compression status and several meter configurations. The BZIP2 compressed files open significantly slower than LZMA or uncompressed. I initially thought it was an issue with the compression library I was using but it's not, in comparison tests BZIP2 blows. It does achieve higher compression ratios but the speed trade off is horrendous.

Which is why I posted the suggestion of auto converting them.

It probably isn't a big issue for most of the skins out in the wild but I haven't tested them all. Anyone creating new skins can just select LZMA as the compression type in VUEditor.

although, i think that automatic recompression is a bad thing, i still would like to see that manual recompression to LZMA is possible because BZip2 compression is very slow on loading skin.

[sveakul]

I'm not that keen on supporting multiple layers of archives.

What happens with oops version if you dump a RAR in the skin folder that contains multiple bin files?

1.  I understand, like I said the only reason was "visual tidiness" in keeping hiccup INI files in their download package (they are read) and multiple same-name BINs together.

2.  It just shows up on the skin selection list like the rest of them

[BoringName]

2.  It just shows up on the skin selection list like the rest of them

So a single RAR file with 5 different bin files inside (placed in the skin folder) results in all 5 skins being visible to select in the plugin?

I could see a benefit to that where you could have multiple colours of the same skin in one RAR file and add an option to switch between them without navigating the skin menu. Maybe something like shift+mousewheel. If I can get keystrokes to register....

although, i think that automatic recompression is a bad thing, i still would like to see that manual recompression to LZMA is possible because BZip2 compression is very slow on loading skin.

I'll do something with this in the next version.

[sveakul]

2.  It just shows up on the skin selection list like the rest of them

So a single RAR file with 5 different bin files inside (placed in the skin folder) results in all 5 skins being visible to select in the plugin?

No, I was referring to normal cases where e.g. a skin using two BIN parts is contained in one RAR container named from the skin;  that, and hiccup's bundled *.ini files.

[hiccup]

I'm experiencing a strange problem.
Both MusicBee and VUMeter are suddenly responding extremely sluggish.
When e.g.  selecting a filtered selection of my library (e.g. an album artist) it can take around 10 seconds before that selection shows. (this uses to be instantly)
When playing a song, the VU meter is acting as if in slow-motion.

I noticed very high CPU usage for MusicBee with the plugin (above 10%, which is unusual for my system)
When clicking Help > About  in the taskbar it triggers this error:

Code

MusicBee v3.6.9100.25839P  (Win10.0), 30 Nov 2024 12:13:

System.ArgumentException: Parameter is not valid.
   at System.Drawing.Font.GetHeight(Graphics graphics)
   at System.Drawing.Font.GetHeight()
   at System.Drawing.Font.get_Height()
   at System.Windows.Forms.Control.set_Font(Font value)
   at #=z$bvI4Pm1ZF0skOuoEdiTGhY=.#=zyuMLPOoSpUObXXJhnQ==()
   at #=z$bvI4Pm1ZF0skOuoEdiTGhY=.#=zs3RUgqgTKBCA()
   at #=zlln1_jyD$ZWaXKQQSgXwKFg=.#=zAw5eJJJsqFAd(ControlCollection #=zfBTTLWpnCb$k)
   at #=zlln1_jyD$ZWaXKQQSgXwKFg=.#=zAw5eJJJsqFAd()
   at #=zlln1_jyD$ZWaXKQQSgXwKFg=.#=zs3RUgqgTKBCA()
   at #=zKr8uYe4ze4178dMe$bvtO2I=..ctor()
   at #=zuV51z$JdTg50PzutmWIYNHC6QxC$.#=zbQEsZq087MRf.#=zma46RtcMBO2NKCJvjA==(Object #=zVaGnpp0=, EventArgs #=zPm8gbzw=)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I have no explanation what started this, but it started after I had created a new library. (containing some 5000 albums)

[hiccup]

And something I have been noticing that is probably not important, but I find odd:

The letters of the text 'Skin Loading' always have looked a bit crooked to my eyes.
Since loading some skins currently takes a very long time I thought to take a screenshot and give it a better look.
Here it is:

notice how many letters have some horizontally sliced offset (k, i, n, L)
Again, not important, but mentioning it in case it is indicative of some underlying issue.