- This doesn’t work with WASAPI exclusive mode.BoringName, first congrat's on the release of such a sophisticated plugin for MusicBee!
I been using WASAPI exclusive for years and now i switch to shared. I can't hear the difference. It is all about the audio latency and win 10 fixed that. And the latency is all about playing or producing music and not listening.What concerns me is that only Wasapi-Exclusive and ASIO completely avoid a trip to the Windows Mixer. I don't have vumeter installed yet, pending BoringName's response to my last post, but will report on CPU if I do. Can you post a screenshot of the meter panel you are now using?
What is your CPU usage level when using vumeter?
It sure looks nice but it uses way too much CPU power, MB goes from 0,0001 to 25% (peaks at 80°) on Rayzen 5500U. Big problem.
MB is the latest version 3.6.9010.
Windows 11 updated.
Wishlist: Stereo/combined mode option (one or two meters as is common with analog vumeters)
Can you give a brief description as to why Wasapi Exclusive CANNOT be used with the plugin, while other audio visualizers like the CEN Spectrum can?
Can you give a brief description as to why Wasapi Exclusive CANNOT be used with the plugin, while other audio visualizers like the CEN Spectrum can?
The simple answer is I don't know. I only noticed the issue just just before I was about to post the plugin. I'd already delayed posting the plugin due to all the website shenanigans and didn't want to delay it further.
Rough guess might be because I'm using the Naudio library to query the audio device and maybe that's locked out because Musicbee has exclusive access. I will have to do some research on it.
It sure looks nice but it uses way too much CPU power, MB goes from 0,0001 to 25% (peaks at 80°) on Rayzen 5500U. Big problem.
MB is the latest version 3.6.9010.
Windows 11 updated.
Wishlist: Stereo/combined mode option (one or two meters as is common with analog vumeters)
I'm using a Ryzen 5 7600 with windows 10 and I can't get Musicbee to get over 5% CPU even if I scroll the hell out of 3DBee at the same time I'm running a test file for the VUMeter.
I'm also not seeing any "background" usage in exclusive mode.
After fixing a friends laptop this week running windows 11, all I can say is windows 11 can die in a fire and I won't be doing any testing on that OS, Sorry. I can't see any reason at all for the VU plugin to be hitting 25%, that's insane. There is nothing in there that should be that demanding.
As for your wishlist, options to choose which meters to show are planned.
Does the plugin use only CPU or also GPU?
Also about background process.
VU METER is in pannel
When playing CPU spike
When pausing still CPU spike.
When stopping CPU usage normal.
Placed into Programdfiles86\Musicbee CPU usage drops to 20 % and "background process" goes away.
9/7/2024 9:05:47 PM - 10.0.19045.0 - 3.6.9014.38238P - System.ObjectDisposedException: Cannot access a disposed object.
Object name: '#=ztCnISMIcvHfKsYDzkA=='.
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.ControlCollection.Add(Control value)
at System.Windows.Forms.Form.ControlCollection.Add(Control value)
at #=zkVeMgIxXhhF9BfCrZlpLyXY=.#=zDTHJELQ=(Control #=z7S5NXtI=)
at #=zvPmJo7aD6sroOzVPSi7fX7s=.#=zDTHJELQ=(Control #=z7S5NXtI=)
at #=zziapYCHkKIL0B5EplaYmmhGl87_u.#=zu6tTUJjTFwFH(#=ztt6cRBfm7he6 #=zg__Ik9c=, Boolean #=zG5pTnsiSrZv04CgNQw==)
at #=zziapYCHkKIL0B5EplaYmmhGl87_u.#=zwQkNOsuRu_VO(Boolean #=zcOnfLKIsgZ_uUoto$w==, Boolean #=zqyGiT1lKtqzM)
at #=zziapYCHkKIL0B5EplaYmmhGl87_u.#=zfCXwpcY2tu4q3AJ_aISLuTyI3lun.#=zOgklf368i2wP.#=zMyQZypCpf82y()
at #=zziapYCHkKIL0B5EplaYmmhGl87_u.#=zfCXwpcY2tu4q3AJ_aISLuTyI3lun.#=zOgklf368i2wP.#=zU5RWQ17zKxdW(Object #=z0TOEPTs=, EventArgs #=zTAVcBww=)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at #=zkxPwEgpbqlyH5MwA11oLVr4=.OnClick(EventArgs #=zTAVcBww=)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.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)
9/7/2024 9:06:58 PM - 10.0.19045.0 - 3.6.9014.38238P - System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidCastException: Unable to cast object of type 'NAudio.CoreAudioApi.Interfaces.MMDeviceEnumeratorComObject' to type 'CoreAudioApi._MMDeviceEnumerator'.
at CoreAudioApi.MMDeviceEnumerator..ctor()
at MusicBeePlugin.audioDevice..ctor()
at MusicBeePlugin.pluginLogic.startPlugin(MusicBeeApiInterface lnkApi)
at MusicBeePlugin.Plugin.ReceiveNotification(String sourceFileUrl, NotificationType type)
--- 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.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at #=zb1GcBWSkGklkX$LMig==.#=zqHOVe3GaBxHU()
Hope you've got enough information here to provide a fix.
Thanks.
edit: Steve has just added a new api command for peak values so I should be able to sort out the WASAPI problem.You had me scared until this part!! Looking forward to the Wasaspi-Exclusive version--thank you Steven and BoringName.
MusicBee v3.6.9018.33710P (Win10.0), 9 Sep 2024 8:14:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: '#=z8$pAChtyNR9TsebcPA=='.
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.ControlCollection.Add(Control value)
at System.Windows.Forms.Form.ControlCollection.Add(Control value)
at #=zlaX4bVxzSN1gY8OokRxL8x0=.#=zIFRO0Jw=(Control #=zu_XQi8k=)
at #=zWS4fE84iG023zFm61fWoVnk=.#=zIFRO0Jw=(Control #=zu_XQi8k=)
at #=z09qWh4vN1pxXik4I5_AJNu9yIDR5.#=zh7WzTcSnBG_m(#=zx9khceqPIm5Y #=zp_P$VYw=, Boolean #=ztnynhcXxlmCs5KeFxQ==)
at #=z09qWh4vN1pxXik4I5_AJNu9yIDR5.#=zm9tdxp6y9smd(Boolean #=zcRWjBoLPvNxR0R7G1w==, Boolean #=zFqDNeoCoUVnu)
at #=z09qWh4vN1pxXik4I5_AJNu9yIDR5.#=z40T2IVGLSEusAJT4wLxmQyEe9LzA.#=zCUyzp6vHgqYe.#=zyMxeqLuA4ulg()
at #=z09qWh4vN1pxXik4I5_AJNu9yIDR5.#=z40T2IVGLSEusAJT4wLxmQyEe9LzA.#=zCUyzp6vHgqYe.#=zQvlir00vvCvh(Object #=zTiuP_8k=, EventArgs #=zYI1p7L0=)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at #=z4KQEmLYFKcS8h5G3MN3v5Jc=.OnClick(EventArgs #=zYI1p7L0=)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.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)btw, could you add the option to always show only 1 meter (average of left and right channels)?Getting ready to try out the new plugin, but wanted to add my +1 to Boroda's wish above. a lot of us don't have the screen real estate to show double meters. For L/R displays, bar-type displays are a better choice, like the new javascript Foobar meters below:
What is not so great yet is the needle action.
It's quite jerky, and is also seriously 'behind the beat'.
AIMP on top, which is pretty much spot on on the beat:
There is also a small graphics flaw when using VU meters that use 'two needles on top of eachother' trickery.
As you can see here, the bottom needle does not get covered by the glass:
Would it be possible to have the plugin panel using the colour of the skin for the background instead of being black?
My MB process will sit between 9.5-10% with VU running.
Some further playing around I did. I had MB running with music playing. CTRL-ALT-DEL to bring up the task manager and MB completely crashed. If task manager is already running before I start MB I can switch back and forth no prob.
I also discovered that if VU meter is active (I have it currently in the right sidebar) MB will launch with the same 10% CPU load - even before I start playing music.
Could it be a conflict with any other plugins? In your first post you mentioned possible issues with 3Dbee. I did have it installed, but not being used. I uninstalled it just to see if that'd help, but no change
I got this error randomly. Had to hard stop MB. After that all layer settings were screwed.
10/09/2024 10:06:06 - 10.0.22631.0 - 3.6.9018.33710D - System.ObjectDisposedException: Cannot access a disposed object.
Object name: '#=z8$pAChtyNR9TsebcPA=='.
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Control.GetSafeHandle(IWin32Window window)
at System.Windows.Forms.ToolTip.Hide(IWin32Window win)
at System.Windows.Forms.ToolTip.TimerHandler(Object source, EventArgs args)
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)
WISHLIST: Higher resolution background jpgs. Maybe set a standard. Like if common screen resolution is 1920x1080 then vertical Vu meter's skins jpg should be width x 800 and horizontal 1200 x length. Or in HD res for full screen floating window. Also maybe offering different (HD, SD UHD) versions of skins if available
I think the percentage of users with a full screen floating window for their VU Meter will be exceptionally low. A vast majority are going to have them set to less than 1/4 of the screen size so except for people running 4k monitors, anything over 1/4 of 1920x1080 is a waste really.Not only a waste, but it's even likely that will have negative results.
There is also a small graphics flaw when using VU meters that use 'two needles on top of eachother' trickery.
As you can see here, the bottom needle does not get covered by the glass:
(https://i.imgur.com/rkAF8LL.gif)
Also notice that the VU meter here has been cut off a couple of pixels on the right side:
(https://i.imgur.com/mIIFGDj.png)
It will probably be a week or two before I release another version.
- Zip files now supported. If you have a folder and a zip file with the same name in the skins folder it will read from the zip file. It will also be listed twice on the context menu. Folder skins are listed first and
@BoringName: Thanks for new version 1.2!
Bug: trying to load supplied skins from zip files results in this message "Error loading skin attempting reset" with "OK" superimposed:
Edit: also, can the single meter option be made so that it doesn't need to fit in a double-sized window compared to the dual option? Something seems backwards there!
It's great, but wouldn't it be better to add an option to the plugin to import zipped meters (and unpack them on importing) manually?
using the new plugin version CPU usage is 8-9% and GPU usage is ~2%. not sure if BoringName has done something for this. but it's a single (average) meter.
Regarding CPU issues. I may have mad a mistake. I recently switched to win11 and didn't notice that in task manager info under processes (25%) for some reason doesn't matched information in details (5%). So
that you know.
I lied.So did Katie (https://www.youtube.com/watch?v=7qg3UHoksuw&list=PLJUP6vuIPrIl6YGnVx5WH5xcOn51-BWVm&index=5), and same as with you, we're much the better of it.
So did Katie (https://www.youtube.com/watch?v=7qg3UHoksuw&list=PLJUP6vuIPrIl6YGnVx5WH5xcOn51-BWVm&index=5), and we're the better of it.
So please tell us more sweet little lies. (https://www.youtube.com/watch?v=uCGD9dT12C0&pp=ygUldGVsbCBtZSBsaWVzIHRhbGwgbWUgc3dlZXQgbGl0bGUgbGllcw%3D%3D)
It's great, but wouldn't it be better to add an option to the plugin to import zipped meters (and unpack them on importing) manually?
Do you mean have a button that opens a file dialog where the user can select a downloaded zip and it will import it into the VUSkins folder, so the user doesn't have to try and find the folder themselves?
It's not a bad idea but with the differences between portable and installed and issues with file permissions associated with the installed versions, which I think you alluded to with the additional support comment, I don't think I could be arsed. I can imagine scenarios where users dump some in the Musicbee\plugin folder and import others and I don't like the idea of moving users files around to consolidate them on startup (if required).
Not surprised, only had my first experience with 11 fixing a friends laptop last week and I hated how hard it seemed to find basic info. They have just moved things around for the sake of it to justify a new version number. I usually skip every second version anyway so I'll wait for 12 although I expect that will be worse than 11 with AI rubbish.
…but Steely Dan works too.It should. It's probably the greatest pop/jazz band/duo ever.
New version…Damn!
It's set to fill the size of the panel. If you want it smaller you can just resize it. If I set it to half the panel, the other half will be blank. I can't resize the panels programatically.But only the dual meter version "fills the size of the panel" using correct aspect ratio, as you can see below. With the panel size unchanged, selecting "single meter" blows up the size past what the panel size is still set at--in other words, it doesn't use the panel space aspect ratio. I can't fit the whole meter in the space then without enlarging the panel, which I don't have the space on my skin to do--the single meter image itself is not resizable. Surely that can be fixed?
There's a graphical glitch in hiccup's DejaVU Compact skin. He's of the opinion that it's a plugin issue and not a skin issue. But I don't see this on any other skin. The glitch extends beyond the frame of the meter and moves with the needle.I am now having some doubt if this may indeed be a flaw in my VU meter and not something caused by the plugin.
Original post to hiccup is here: https://getmusicbee.com/forum/index.php?topic=41696.msg227410#msg227410
(https://i.imgur.com/aXPkH5H.jpeg)
Surely that can be fixed?
Dadgummit
Needle action now seems so good
I am now having some doubt if this may indeed be a flaw in my VU meter and not something caused by the plugin.
Technically it's not a glitch. The needle has been rotated to an angle that places it outside the bounds of the background image and foreground image. This has to occur for some skins to work properly.I just checked, and all the images (background, needle, glass) in this VU meter skin of mine have the exact same size properties. (the height being 291px)
It's kind of interesting that your plugin also displays what happens beyond that fixed area, but it probably shouldn't?
My impression was that conforming the single meter to the existing window while maintaining the aspect ratio of the meter interface wouldn't turn it into a squished mess, but that the meter itself would be reduced in size proportionately accurate to itself--naturally resulting in black parts on either the top/bottom or sides of the meter, depending on its original dimensions, just like album art is on most player panels.. It doesn't need to FILL the space, just fit inside it and be "centered" therein, naturally resulting in some empty "black" space either on the sides or its top/bottom depending on its original dimensions. I think this is what you have illustrated and are proposing in fix #2--if so, I'm completely on board! :)Surely that can be fixed?
Two ways to fix it.
1. Unlock the aspect ratio so it becomes a squished mess.
2. Add a margin and justify options so you can centre it or display it on either side if the panel.
(https://i.imgur.com/45haDli.png)
If use skin colour is selected those black parts would be the colour of the current skin.
I don't want to do option 1 so option 2 is what I will implement at some point, unless someone can think of a better idea.
Needle action now seems so good that I don't think I care much about having any sort of peak indicators/lamps/LEDs anymore.Three of the LVU-type LED meters; personally I hope BoringName can add that format! Presented larger than need be, these resize proportionally to fit whatever the AIMP Visualization window is dragged to by the user:
While it may be visually intriguing, and it could be some 'fun' having it, it's probably not much of a concrete added value, and perhaps not worth a lot of time or effort trying to get to work. Just saying.
Technically it's not a glitch. The needle has been rotated to an angle that places it outside the bounds of the background image and foreground image. This has to occur for some skins to work properly. The issue is the panel hasn't been resized vertically to the size of the skin so it's showing the out of bounds part of the needle. The easy solution is to just drag the top of the panel down until the black area is gone.Yes, reducing the height of the window does make the referenced part of the needle not display.
Edit: Just dawned on me, the plugin is just making a clean half/half slice of dual meters that are joined together by design in the first place, so this is no bug, nothing to adjust!!
I did mention the single meter option isn't suitable for "merged skins" in the 1.2 change notes. There is probably a better way to describe them but that's all I can come up with for now. Suggestions welcome.
Technically it is not cutting off anything. It is simply showing the left meter only.The only disappointment is thatwith meters who use a linear format, while the new option will allow its use as "single meter", a slice of the right end of the meter is always cut off
The Phred on the Lookout skin metered up:You may like (the new) 'DejaVU Compact Phred on the Lookout' meter?
You may like (the new) 'DejaVU Compact Phred on the Lookout' meter?
Yes, looks great on my Lyrics panel, thanks.Good to hear/see.
About the 'linear' option:
Is this (still) a useful additional setting to have?
Am I wrong in thinking that MobilityNegative and MobilityPositive don't have any effect anymore?
dbs=8;100|7;120|6;140|5;160|4;180|3;200|2;220|1;240|0;260|-1;280|-2;300|-3;320|-4;340|-5;360|-6;380|-7;400|-8;420|-9;440|-10;460|-11;480|-12;5000|-13;520|-14;540|-15;560|-16;580|-17;600|-18;620|-19;640|-20;660|-21;680|-22;700@BoringNameNO!!! Please do not remove it. Or not until I've done some more testing. A few days ago I found the needles showing a very low level. I enabled linear and they popped right up. Playing around with it a little bit right now, I found one skin that when linear is disabled the right meter doesn't move at all (DejaVU Compact Phred on the Outlook. I will shortly file a report for hiccup on his skins thread.) And some of his others the left meter doesn't move. I need some time to go through all the skins and take notes before I file a report. For the time being, I can report that all four original skins do not move when linear is disabled.
About the 'linear' option:
Is this (still) a useful additional setting to have?
Those are weird bugs, and obviously not something that should be related to- or possibly fixed by using either linear or logarithmic curves.@BoringNameNO!!! Please do not remove it…
About the 'linear' option:
Is this (still) a useful additional setting to have?
… I found one skin that when linear is disabled the right meter doesn't move at all (DejaVU Compact Phred on the Outlook.
… And some of his others the left meter doesn't move.
I haven't implemented those settings. I assume they are meant to adjust the needle movement speed but I don't think I can implement that with how the plugin works. At the moment any method I can think of would probably make the meter less accurate or out of sync.You could probably describe it as some attack/decay setting for the needle action.
I'll conduct a full test of all of them in a couple of hours and report back.The test was done immediately following a Windows 10 reboot and with MB 3.6.9018 P.
I tested all 22 (currently) available skins and there's some weird stuff going on.Only 22?
Two of the original skins (packaged with the plugin) have issues…That's really weird.
Four of hiccup's skins displayed issues…
I'm sure you are not on drugs or imagining things, so I am wondering if there might be something specific going on on your system that might be interfering, and causing these issues?This issue may -cause- me to seek out some medication.
Antivirus software, audio drivers, 3rd party audio software, some particular customised audio settings?AV is not a problem as they were working a couple of days ago. Drivers haven't changed, and there's no 3rd party audio software.
Anything?
And just to be very sure:No, not a -new- portable install, but I will do that after I boot into safe mode and test again. But that won't be for a while.
You are using a squeaky clean portable MusicBee and VUMeter install for testing this?
I prefer total accuracy, unless it results in a near "dead" meter or would take an inordinate amount of time to code as opposed to being "pretty much accurate."Yes, looks great on my Lyrics panel, thanks.Good to hear/see.
What's your opinion on dB accuracy for these kind of VU meters?
Would you prefer total accuracy (such as with AcuVU) or do you think bending the truth a little bit is OK?
(it makes it easier to chose values that look good, and having them aligned and filling the scale in a visually pleasant way)
Removing options = bad. I agree with phred, please do not remove it. I noticed the dead right meter issue on the skin he mentioned. In general with the few skins I have ( the hiccup group) enabling it/disabling all produce a noticeable effect, usually disabled shows a more "agitated" movement. Disabling it in the hartmann & braun meter results in ZERO movement. Bottom line = please keep this option, what's available out there (AIMP etc) just is not standardized enough to support the removal of something that can positively affect performance levels.@BoringNameNO!!! Please do not remove it. Or not until I've done some more testing. A few days ago I found the needles showing a very low level. I enabled linear and they popped right up. Playing around with it a little bit right now, I found one skin that when linear is disabled the right meter doesn't move at all (DejaVU Compact Phred on the Outlook.
About the 'linear' option:
Is this (still) a useful additional setting to have?
I'll conduct a full test of all of them in a couple of hours and report back.
I prefer total accuracy, unless it results in a near "dead" meter or would take an inordinate amount of time to code as opposed to being "pretty much accurate."I understand. But to be clear about what I am talking about regarding my own VU meter skins here, it's strictly about the cosmetics.
That's really weird.You mean, you DON'T see the dead right meter on DejaVu Compact P.O.T.L. when linear is off?? Or the dead LEFT meter on the regular DejaVu Compact? Or the zero movement on the hartmann & braun? It's real, believe me. BTW, my output is Wasapi-Exclusive as always using Windows 11 x64.
Both BoringName and I have been doing some serious testing/developing this stuff for the last couple of weeks, and it looks like neither of us has experienced this kind of bugs.
I'm sure you are not on drugs or imagining things, so I am wondering if there might be something specific going on on your system that might be interfering, and causing these issues?
You mean, you DON'T see the dead right meter on DejaVu Compact P.O.T.L. when linear is off??I do, and that's exactly what I reported to BoringName earlier in this thread.
Bottom line = please keep this option, what's available out there (AIMP etc) just is not standardized enough to support the removal of something that can positively affect performance levels.With all due respect, I think both you and Phred are having a wrong view on this.
With all due respect, I think both you and Phred are having a wrong view on this.Speaking strictly for myself, and ignoring for the moment the skins that are exhibiting no needle movement, with linear disabled the needles do move, but very little. Right now barely moving from -30db. Enabling linear using the same track and skin the needles are moving between -30 and -15 with an occasional peak towards -7.
You both seem to want to keep the option only because there seems to be some bug in the plugin concerning needles in some cases moving or not.
The option is (should be) about the curve of the needle, i.e how fast it moves across the scale in certain areas and where it is positioned at certain volume levels.
Please, let's keep that functionality option separated from any current bugs that have nothing to do with a linear vs. a logarithmic curve.
I'll conduct a full test of all of them in a couple of hours and report back.I can't say the test was successful. Nor can I say it was a failure.
MusicBee v3.6.9023.27917P (Win10.0), 14 Sep 2024 13:46:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at MusicBeePlugin.VUMeter.DrawBackGround()
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)
But there's no point in having VU meters if there's hardly any movement of the needles.Yeah, it may be better to just forget about this VU meter stuff and delete everything that has been created, accomplished and shared.
Yeah, it may be better to just forget about this VU meter stuff and delete everything that has been created, accomplished and shared.[sarcastic reply mode]
(sarcastic mode on)
phred:
I can't say the test was successful. Nor can I say it was a failure.
Booting to Windows Safe Mode and launching MB resulted it a crash. A quick flash of what I think was "MusicBee can't start now." Or something similar. It flashes so quickly before it's replaced by this...
So I "installed" a fresh portable version of MB and it started as expected. I close it, installed the VUMeter plugin and when I launched MB it did the same thing. End of test.
I will wait for BorningName to take a look at things before testing again.
My first inclination to keep it is based on what BoringName mentioned a while back about the Linear option seeming to produce more accurate results IN SOME CASES. My second is that some meters have a more linear, less logarithmic scale so my guess is that "linear" is best able to represent on those scales? In any case, keeping the option "available" when it's already present hurts nothing AFAIK. Visually it produces a lower dB range of movement in the majority of cases, but whether that means "more" or "less" accurate I have no idea.Bottom line = please keep this option, what's available out there (AIMP etc) just is not standardized enough to support the removal of something that can positively affect performance levels.With all due respect, I think both you and Phred are having a wrong view on this.
You both seem to want to keep the option only because there seems to be some bug in the plugin concerning needles in some cases moving or not.
The option is (should be) about the curve of the needle, i.e how fast it moves across the scale in certain areas and where it is positioned at certain volume levels.
Please, let's keep that functionality option separated from any current bugs that have nothing to do with a linear vs. a logarithmic curve.
My second is that some meters have a more linear, less logarithmic scale so my guess is that "linear" is best able to represent on those scales? In any case, keeping the option "available" when it's already present hurts nothing AFAIK. Visually it produces a lower dB range of movement in the majority of cases, but whether that means "more" or "less" accurate I have no idea.For now that's all based on guesses and assumptions and have not been tested and verified.
Why did you boot into Safe Mode in the first place? Is it because MB crashed when you first installed VUMeter 1.3, or when you were trying a particular skin?Because even though I was certain I had no third party audio apps running, I wanted to test the odd needle behavior on as plain vanilla machine as I could. Which was safe mode. If I had seen your post that you were also experiencing the needle not moving issue before I did Safe Mode, I wouldn't have bothered with it.
All I can say is in my MB environment with Linear enabled, both channels react "normally" (whatever that is at this point!) on that skin--and the instant I uncheck "linear", the bottom "R" meter slams immediately to the left end, dead, while the top "L" meter continues albeit at a slightly lower dB level. And from what phred has reported, he sees the same thing.I do, I do.
Does that crash you listed occur only in safe mode? Safe mode might not let it load required DLL's, not sure.Yes, the crash only happened in Safe Mode, so I wouldn't worry too much about it. Especially since your explanation about the DLLs makes sense.
I believe you said you were building, or rebuilding, or demolishing your garage. Go finish that and then come back and fix things here. Now that we know that it seems like an easy fix, it can wait.Let the poor guy finish the LVU meters first while he's on a roll, the garage will still be there ;D As phred said, thanks for finally being the person who made all this happen.
Not sure how the original author of LVU handles those errors. Considering the old author just popped up 8 years later with a new version and his only response to all the queries of it triggering antivirus is "trust me bro", I haven't got much faith in it and I'm not going to risk checking if I have the meters working like they do in AIMP.Thank you for the update and looking forward to the new release!! Appreciate you taking on the LVU designs.
dbs=5;171|5;186|4;200|4;213|3;226|3;240|2;252|2;265|1;278|1;278|0;291|-1;304|-2;316|-3;330|-4;343|I've updated the same link with a fix, try it again. All the skins "should" work properly now.....Indeed they are now working as expected. Thank you.
Now isn't it time for you to be working the delivery chute of the cement mixer that's pulling into your driveway?
The LVU meter support is welcome, although they are less ambitious than the Foobar ones.
As far as LED's/LAMPS for peak values go, I should be able to combine the LVU implementation with the AIMP skins to provide a needle and Lamp for both left and right meters as Hiccup has requested. It will just require a bit of a mashup of the different INI file formats.That would be great. I have some new insights in the sense that this may be more useful than I expressed the last time I had an opinion on this ;-)
Foobar support is dead in the water. I've done all I can there. in terms of appearance it shouldn't be hard for people to make similar skins in the AIMP/LVU formats.It's a pity it has cost you so much time and effort, but I agree that if the AIMP skins work well, we can do without support for foobar2000 skins.
I noticed that the meter now seems to get the sound post-ReplayGain adjustment.
Has that been changed, and is it intentional?
I'm not sure that I like it, since for a lot of my music the needle now only uses a small part of the scale.
Is it also post-equaliser and possible VST or Winamp plugins?
Perhaps it could be an option setting to have it operating pre- or post?
About the needle action.
I have played around with the two new sample sliders, and it seems an interesting option.
Yet at the moment I think that some optimal setting for the two can be decided on that will work well for all needles, and it may not need to be an additionally available setting option.
Here's an interesting discovery I made about this:
I was curious about the needle action of professional VU meters.
Reading some articles on it revealed that the needle should go from ∞ to 0 dB in 300 ms. (for a 1kHz sine wave)
Then I started fooling around with AIMPs MobilityNegative and MobilityPositive settings to see if I could get it to have such a response, and I found that the values that are set for those correspond to exactly that.
So if you set the value to 0.3, it takes the needle 300 ms to travel that distance.
0.1 makes it take one second, etc.
(why the hell didn't they just name it RiseTime and FallTime?)
Two other things that I hope can be improved upon:
- audio/graphics sync is still not great, the needle trailing a little bit behind the music.
- the needle often seems a bit nervous and jumpy. It's especially noticeable with thinner needles and fast moving needles.
Could it be that the frame-rate of the needle image is a bit low?
(I hope you're still having fun with this ;-)
And a final observation for now:
edit:
And something I thought I reported earlier, but it seems that I didn't:
I noticed that the plugin seems to ignore the value that is set for ZeroLevel?
So when e.g. having 'ZeroLevel=-3', the needle should indicate -3dB at the zero level position, but instead it always uses 0dB.
Similarly, I'm not sure what it does with MaxLevel, if anything?
It would be good if it did use/respect these values, since it is useful for some skins to be able to set e.g. MaxLevel to 0dB and ZeroLevel to -6dB.
And same as the fall/rise aspect, it's also a factor in existing AIMP skins behaving as they are intended to.
Yes but when you think about it, the sole reason I added those sliders in was because you questioned the movement and I added in a method for you to adjust it. No one else mentioned it.Well, I am observing some issues with the needle movement, and I have done my best to describe and analyse that as best as I can.
If you set the sample number to 15...Thanks for explaining, it's interesting to get this detailed information about what is making the magic happen.
At default settings it takes a sample every 15ms.
if the peak value drops from 1.0 to 0, it will take 150ms...
Change the samples to 15 and it will take 225ms...
Not sure on a solution for the sync issue. Isn't it always going to be behind the music because it's an average of the last 150ms? (at default settings)I have no clue.
Increasing the sample number reduces the nervousness of the meter. I have noticed I need to give the meter more time for the needle to come back down before I stop the process when the music is paused/stopped. With higher sample numbers it gets half way down and then just jumps to the end which doesn't look good.Interesting, and all valid points of course.
Thinner needles are probably not going to look good in general if they are low resolution. Everything is scaled to the window size which means moving pixels around, at certain angles this might mean they appear even thinner which would probably make them look more jumpy. I did play around with Antialiasing on my other plugin but the results were not great.
Now I'm getting it from the MusicBee API. Any changes you want there would have to be done by Steven. I think he may get it from the bass.dll as he mentioned BASS in the thread when he implemented the peak value api call.Hm, that is a bit of a problem.
Can you give an example of when you would want to use those settings as you suggested? If the peak reading is 0db why would you want the meter to display -3db? Can't you just set the ZeroAngle value so it points at -3db on the meter and that will give you the same result? That will change the increment positions for all values but that will happen with either method.Because many AIMP meters will have been designed like that.
After all this discussion about trying to make the meters accurate, it seems a bit weird to want options that do the opposite.I don't really understand what you are saying here.
It's a bit of comparing apples with pears, but, since the red zone is an acceptable area for recording and production work for the needle to (briefly) be in, it would make sense to have a consumer VU meter also passing the 0dB indicator for loud passages.I completely agree with all your points here.
I'm just sharing this thought because we've discussed the fact if the needle in a plugin like this one would (or should) ever go beyond 0dB.
I know believe that it should/could.
And peak indicators could be useful if there is an option for post-processed indicators.
Then they could give some indication when the user is using too much pre-amp or has set EQ levels too high.
I'm just sharing this thought because we've discussed the fact if the needle in a plugin like this one would (or should) ever go beyond 0dB.
I know believe that it should/could.
I was curious about the needle action of professional VU meters.
Reading some articles on it revealed that the needle should go from ∞ to 0 dB in 300 ms. (for a 1kHz sine wave)
Then I started fooling around with AIMPs MobilityNegative and MobilityPositive settings to see if I could get it to have such a response, and I found that the values that are set for those correspond to exactly that.
So if you set the value to 0.3, it takes the needle 300 ms to travel that distance.
0.1 makes it take one second, etc.
(why the hell didn't they just name it RiseTime and FallTime?)
Here you can see how AIMP is correctly applying 1 sec. fall/rise, and VUMeter™ is not:
(https://i.imgur.com/IG9OyNG.gif)
Just confirming you had the MobilityNegative set to 0.3 in that test. From what I was reading it's supposed to be in the range of 0.00 and 0.10. Setting your AcuVU skin to 0.3 MobilityNegative makes for a very erratic meter in AIMP. It's normally 0.03 which takes about 3.5 seconds to drop from 0 to ∞.I'll do some repeated testing again tomorrow.
I have a feeling AIMP isn't averaging anything either. I think it's just taking the peak values and letting the mobility settings smooth out the meter which I guess has a similar effect.
Just need someone to confirm they are seeing the same thing as me in regards to the positive and negative scaling differently before I spend time on it.
edit: AIMP using the peak values and not doing any kind of average would also explain why my version is a bit behind..... I think.
@ BoringName and hiccup: the AIMP LVU plugin has been updated to version 1.2.1, following the AIMP developer's direct work with its author xrEngline on fixing the issues with the virus alerts after my request/plea to him to do so.That's great, well done sveakul!
One kind of maddening thing was that earlier today the LVU thread contained a back-and-forth in Russian between the AIMP developers and the plugin author on tweaking needle performance, *.ini settings, etc. for the new version--but these comments have all been removed now! I have asked if they are still available somewhere to read.
Have fun playing with this.
I'll have a read of the thread before I think about installing it just to see if they detail how they stopped the virus reports.No, they don't "detail" how they stopped the reports, but neither did un4seen during the bass-zip "virus" false positive scare that stopped some from downloading MusicBee. 3 detections out of 67 vendors, 2 of which are heuristic and 1 "cloud", I consider fixed.
As for the speed of the needle/LED there is nothing to change that in the ini file. Does the plugin have any options from within AIMP?
(https://i.imgur.com/NAWtFYq.png)True.
The distance between 0 and +6 is a lot smaller than -6 and 0. If you just use db offset to add 1.0db, it will end up pointing to +3 instead of where it should point (1/3 of that distance). I'll get that sorted out.
When I designed that VU meter skin, I was under the impression that the area beyond 0 dB was useless since the needle (in an audio player) would never go there.
Do you think I should change the scale and its red zone indicators somehow?
1. An LVU skin, Pick Meter 2, which played in AIMP has a beautifully fine-segmented and responsive scale--see the included GIF for how it looks in AIMP. However, also notice that in its skin zip one of the two PNG images shows as "0 bytes" size but has a 1,139 "packed" size. This results in MusicBee rejecting it with an "unable to read skin" message--understandably, but then how the heck does AIMP LVU have no problems with it?
2, A second AIMP-LVU skin, ILT4-30M.zip, has undamaged PNG files but LVU Meter 1.4 just will not open it. Plays fine in AIMP LVU with a background "glow" effect to the LED's that I was hoping could be used in MusicBee too.
The ini file might need to be changed first. You have a Maxlevel of 3 but the meter goes to +6. Which is ok if the MaxAngle is set to the 3 indicator. These 2 settings should be consistent.I just tried a quick and easy fix for AcuVU:
Then just change the ZeroLevel to -6 and run it in AIMP with a test file. Once the level gets to -6 the needle will point to zero on your meter. Each level increase after that should correspond to where your indicators need to be placed. eg) when the level gets to -3, the needle will be pointing where you need to place the +3 indicator. -4 to +4 etc....
1. Very strange, 7-zip extracts all the files but displays an error and the kaha2.png image is empty. Using windows to extract it only extracts the okho.png and kaha1.png, it misses the settings.ini file.Thanks for your fast reply when you're in the middle of all the other work! Turns out the Pick Signal 2 skin just takes up too much space for me in order to display properly--in AIMP, you've got that large resizable auto-aspect "Visualization window" that can be moved around anywhere. I did the fix for the other one and it works fine, but the response is just too slow compared to the analog meters. I keep coming back to AL-65 it seems.
Anyway, I recreated the kaha2.png, try this one - Pick_signal_2.zip (https://www.mediafire.com/file/mzypc423v8vexic/Pick_signal_2.zip/file)
2. That's my fault and will be fixed in the next version. I didn't account for LVU skins that used the same image for both channels. ZipArchive doesn't like you trying to open the same entry twice.
edit: If you really want to use the second skin and don't want to wait for the next version you can modify it to work. Just unzip it, copy channels.png to channels2.png and change the ini file so the png field under the "right" section equal channels2.png. Zip the files back up. Remember to zip the files, not the folder they are in.
Thanks hiccup too for figuring all these new adjustments, can't wait to see all the posted meters re-upped with all these new revisions, but hey man take your time and remember it's worth it even though sometimes it feels there's like 4 people actually enjoying them based on the lack of other posts here (same with the CEN Spectrum)--come on folks, let's hear from you! There's more to life than playlists and replay gain.
And now I'm going to go drink bourbon until I forget how much time I wasted due to that error.And to think you could've finished the garage by now.
And to think you could've finished the garage by now.
Now, THAT'S INTERESTING... I just discovered, by chance, that having MB volume set to "use logarithmic volume scaling" has a major effect on VUMeter plugin readings.
the -7db threshold level I have set on my compressor/limiter (LoudMax)
New version - VUMeter1.5.zip (https://www.mediafire.com/file/744h4mhyee7hvse/VUMeter1.5.zip/file)Wow!
This must be due to a combination of something else. When I run the test files they read exactly the same whether I have logarithmic volume scaling checked or not and moving the volume slider up and down has zero effect with either setting.Well I unchecked that VST the first test I did. I've had it, I found what works for me now and I'll stick with that. The VST host in MB is a bug fest anyway--try this VST and it works by itself, add another that works by itself directly after that and the whole thing crashes, etc etc. The hosts in Foobar v2 and AIMP 5.30+ are rock solid in comparison.the -7db threshold level I have set on my compressor/limiter (LoudMax)
Possibly something to do with this.
But here's a GIF of one of my test tracks (Jessie Ware - Swan Song) looking very good on a calibrated version of AL-65:Yes it is--hiccup, any chance of getting this newly calibrated version of AL-65 posted for us fans?
(https://i.imgur.com/8NtVMoe.gif)
Great!
Well I unchecked that VST the first test I did. I've had it, I found what works for me now and I'll stick with that. The VST host in MB is a bug fest anyway--try this VST and it works by itself, add another that works by itself directly after that and the whole thing crashes, etc etc. The hosts in Foobar v2 and AIMP 5.30+ are rock solid in comparison.
So it's a combination of exclusive mode and logarithmic volume scaling checked.yes that is a bug thats fixed for the next v3.6 update
- In WASAPI exclusive mode with logarithmic volume checked, moving the volume slider has a significant impact on the meter reading. As I said before, in shared mode, having logarithmic volume checked and moving the slider has no effect on the meter.Yes, exactly as I first tested and described above, in my Reply #130 post and was told, "This must be due to a combination of something else."
So it's a combination of exclusive mode and logarithmic volume scaling checked.
If hiccup can do one of those gif comparisons of the needle between Musicbee and AIMP that would be great.Sure, here are two of them.
Also Hiccup, not sure if you are aware but some of your skins are not accurate. AL-65 Elemental and Deja Vu Compact Elemental are incorrect when running the test files, with VUMeter and AIMP.Yes, I am aware and that is intentional.
I noticed the needle would sometimes go past zero when I had the sample number set to 1. So you may notice the meter going slightly past zero.Yeah, I've noticed that too with some wall-of-sound tracks.
Yes it is--hiccup, any chance of getting this newly calibrated version of AL-65 posted for us fans?Sure, I've added it to the regular AL-65 download link.
But for actual use when playing music I don't care much about the values on the scale being acurate. (if that is even possible for a VU meter)
And I am guessing that will be the case for the majority of users.
And a request for a new feature:
Could the plugin be made to recognise a (simple) folder structure for the skin location?
It would be useful to be able to have them organised a bit, same as can be done with MusicBee skins.
Do you mean an option to specify a folder somewhere outside the plugins folder? eg) D:\VUSkins\No, I'm thinking of a subfolder level.
I thought you would ask about implementing LED/lamps before something like that :)Nah, the last thing I would want to be is being too pushy.
I'm going to pretend I didn't read that.Well, the Hartmann & Braun meter that you seem to like and have selected for inclusion in your plugin is actually a milliampère meter.
I don't know how much difference it makes but I think setting the sample interval to 1ms is overkill. If you can't notice a difference at higher values then set it higher as it means less work for the machine.I can't observe any higher cpu load when changing it to e.g. 5 instead of 1.
- db offset (mouse wheel) will now correctly apply a decibel offset for LVU skins instead of the previous method.Confirming that that now works perfectly:
- db offset will adjust the meter more accurately for AIMP skins.
No, I'm thinking of a subfolder level.
Well, the Hartmann & Braun meter that you seem to like and have selected for inclusion in your plugin is actually a milliampère meter.
No correct dB values to be found in that one also ;-)
And, as soon as I set it higher than say 3, I start noticing it starts missing faster 'beats'.
So I myself don't see a reason for setting it higher than 1.
I've wasted a fair bit of time on silly mistakes but I'm liking where it's at.Perhaps a small piece of comfort on that:
About the included VU meter skins, I'm not sure, and maybe you have already done this, but it would be good to credit the creators of the AIMP skins that you have included with the plugin?
New version - VUMeter1.6.zip (https://www.mediafire.com/file/aplcrx0nektb7l8/VUMeter1.6.zip/file)Looking good! (and also very well explained and thought-through)
Changes -
- LEDs can now be added to AIMP skins. They follow a similar configuration to the LVU skins.…
Is anyone sick of having to download a new version every 5 minutes?Not me! (but you're probably tired of uploading them) ;)
Possibly for VUMeter1.7
An option for the plugin to read the replaygain tag for the playing file and automatically adjust the meter gain to compensate.
Looks like I can just directly minus the replaygain value off the peak value to get the desired result. The test track with replaygain of -20% is reading a peak value of 0.80 when playing the 0 level section. (1.0 peak value). Something simple for once!
I thought the peak value was being calculated after replay gain was applied.
An option for the plugin to read the replaygain tag for the playing file and automatically adjust the meter gain to compensate.So for you the meter output does not depend on ReplayGain values in a track?
he earlier and existing pre/post request would already allow for that (and I would prefer that solution), but if that can't be done, a separate option setting could also do the trick I guess.
This was also discussed earlier and with others, and the request that came from it was to have a pre- vs. post option.
(getting the raw sample data for pre, and post EQ/Volume/plugins audio for the other)
Would the new API call GetPCMRawData(float*, int) here (https://getmusicbee.com/forum/index.php?topic=41272.0), allow for this?
I noticed a minor sort of light halo around LEDs.
Is MaxLevel being read properly?
2. Pretty sure all that PCM stuff is beyond me. Or maybe more accurately, I'm not interested in the many rabbit holes I'll have to go down to figure it out.
Without writing a war and peace novel. OpenGL averages out the alpha between the existing image (L_0.png) and the image been drawn on top of it (L_3.png).(using Photoshop myself) I added a 1 px. border around the LED bar with its transparency set to 1%.
Thanks in advance.Is MaxLevel being read properly?No. That seems to have dropped off my to do list. I've stuck it back on there. I thought I'd already implemented it when I stopped the needle going past the max angle on the meter but I obviously didn't.
I can adjust for the Replay_Gain_track tags but I cant adjust for RVAD tags.I'm wondering how important that is.
Actually realised that makes sense so the question is. Just to start a debate, whats the consensus (or lack of) on the different options.If you accomplish getting either the pre (raw) audio, or the post audio stream (the stream that ends up at the speakers/headphones), will there be any reason to additionally consider using tag information?
Normal mode - displayed levels include all tag adjustments and gains from EQ\plugins etc...
Raw mode - displayed levels exclude all tag adjustments and gains from EQ\plugins.
Is there anyone that wants a mode where tags are included but not the EQ\Plugins?
If you accomplish getting either the pre (raw) audio, or the post audio stream (the stream that ends up at the speakers/headphones), will there be any reason to additionally consider using tag information?
Her computer is connected to our home theater system and it all sounds great without needing any volume modification.Then I am guessing you are not having some more eclectic genre playlists that can randomly shuffle between Satie and Meshuggah?
1. 'use skin colour'
2. bar-type VU meters
3. prevent needles from displaying outside the designated VU meter area.
4. allow subfolders for VU meter skins
5. minimum duration of LEDs lighting up.
6.
2. I don't believe your statement is correct. Why does it have to be wider than the background image? It just needs to be wide enough to fill the bar area.The needles can't get wide enough to fill the bar area, since these kind of meters are constructed from separate left and a right segments.
5. Not sure I will do this. I guess it's a requirement if someone wanted to make a skin simulating a bulb instead of an LED. We'll see.OK, but that is a different principle.
(check out my Smooth Slider skin to see what I mean)
OK, but that is a different principle.
This one worksIt only works because the area where the indicators are is is half the size of what the VU meter is occupying, which is a large waste of space.
https://www.aimp.ru/forum/index.php?topic=52865.msg338035#msg338035
The creativity required to make some of these skins work does blow my mind a little.Then try to figure out what I did with Smooth Slider to make better use of the available space ;-)
Then try to figure out what I did with Smooth Slider to make better use of the available space ;-)
I've sobered up a bit. That is clever. I didn't figure out what the problem was until I played the left channel test file.Try playing some Beatles stereo masters ;-)
I don't think that would work very well, because it would require a very large amount of dB steps to make the lightbars move at least a little bit smooth.
This meter can be made using the LVU method and that is probably the best method for this type of skin.
Correct. It can currently not be done with AIMP.
And just to make sure I'm not missing anything, this is currently something that can't be done with AIMP/LVU so it would be something unique to Musicbee?
I don't think that would work very well, because it would require a very large amount of dB steps to make the lightbars move at least a little bit smooth.
Also I had tried that before, but I think the ini does not accept fractions for the dB values.
Also I am wondering:
The plugin currently already accepts LED bars to be longer than the background image.
I am guessing these skins will not be compatible with AIMP either? (I haven't tested that yet)
If someone inadvertently made a needle image at half the size, it would probably still display correctly but if I allow different sized needles it won't anymore, I won't be able to check if it's size was intentional or a mistake.That's a thorough analysis of things.
LVU type skins will work with AIMP if you have the LVU plugin installed, they will also work in Musicbee
AIMP skins will work with AIMP and Musicbee. I think the plugin for these is installed by default in AIMP?
AIMP skins with LVU style LEDs added will only work in Musicbee. AIMP does load them and the needle will work but it ignores the LED settings and doesn't display them
So one thing seems clear: 100% out-of-the-box compatibility between MusicBee with AIMP skins is not a realistic (or even a desirable) goal.
Do you have any idea if there are many AIMP skins that have needles where the creator has taken some lazy approach and did not size them properly?
So it looks like there are two options?
1. allow for wider needles with the consequence that some (very few?) AIMP skins won't work well. (which skins could very easily be modified to correct the needle size)
2. implement the foobar2000 option for L+R (V)
It makes it more of a guessing game for you and me about the importance of compatibility and possible challenges with that.
Cut to the chase, my standpoint would be that getting your plugin the best as it can be is much more important than any possible considerations for staying compatible with AIMP.
I assume the Foobar "BIN" meters are still indecipherable for use elsewhere?
I just did a test converting that skin to the LVU method and you are correct. It's not very smooth. I can change it to support decimal DB values but it's not very practical having to create a large dbs list.
I saw this just recently posted at the Foobar forum, not sure how it may help here but interesting:I assume the Foobar "BIN" meters are still indecipherable for use elsewhere?
Yeah, I hit a dead end there unfortunately.
I saw this just recently posted at the Foobar forum, not sure how it may help here but interesting:
Well spotted sveakul!I saw this just recently posted at the Foobar forum, not sure how it may help here but interesting:Interesting indeed! I've asked if they would be willing to share some info on how to do it. Cross all your appendages.
That gives some hope indeed, also because I believe foobar2000 is coded in C++, and if I am not mistaken, that is also BoringName's weapon of choice?
This was just posted on another thread about the project that I missed before:I saw this just recently posted at the Foobar forum, not sure how it may help here but interesting:
Interesting indeed! I've asked if they would be willing to share some info on how to do it. Cross all your appendages.
New version - VUMeter1.7.zip (https://www.mediafire.com/file/i8vjs3h2salnccl/VUMeter1.7.zip/file)Thanks for the update and all the changes/improvements.
I volunteered to test this and got a PM from oops that a new preview release is coming in a few hours and he will send me the link (dopbox) when it is available. If you are not already in contact with him I will PM the link to you and hiccup when I get it.I'm still trying to get a working link for the new Foobar component. He sent me one via DropBox, but it keeps wanting me to "sign in to verify your identity" and "create a Google account", and there is NO WAY to bypass it. I saw this is a well-known issue on the web, and seems to derive from the sharing party creating the link in the wrong way (naming recipients instead of just using "create link"). I was able to bypass the web interface and download "a" file using wget.exe of the correct size but Foobar rejects it as being corrupted. Anyway I passed all this along to oops and we'll see what happens.
But I 'm sorry to say it seems to have quite a few issues.
- the needle frequently sticks and remains at a high position (even after the signal ended)
- MaxAngle doesn't seem to function at all anymore
- the new background colour option doesn't provide the background colour identical to the Track Information panel
and colours #2 and #4 seem to be identical
(tested with Elemental skin)
I'm still trying to get a working link for the new Foobar component.
He sent me one via DropBox, but it keeps wanting me to "sign in to verify your identity" and "create a Google account", and there is NO WAY to bypass it.Ahhh ... but there is if you use Firefox. I was having this same issue on Dropbox and another of other websites where I didn't have, nor did I need an account.
||accounts.google.com/gsi/*$xhr,script,3pBut it seems I've missed something, I'll need some info on when it triggers. I did a bunch of tests in shared and exclusive mode and it's never happened again. Frustrating!I agree ;-)
These are the skin elements available to me in the API.Then neither of those is probably getting the background colour of the Track Information panel(s).
SkinSubPanel, SkinButton, SkinInputControl, SkinInputPanel, SkinInputPanelLabel and SkinTrackAndArtistPanel
It's surprising to me that for you it's working fine, and also that nobody else is seeing or reporting this.
I've updated the zip - VUMeter1.7.zip (https://www.mediafire.com/file/i8vjs3h2salnccl/VUMeter1.7.zip/file)Tried again but same result with 'Ignore ReplayGain'
Tried again but same result with 'Ignore ReplayGain'
or how I'm handling the data (most likely).
Then neither of those is probably getting the background colour of the Track Information panel(s).
Yes, this corresponds with what I had (https://getmusicbee.com/forum/index.php?topic=40284.msg218218#msg218218) as well.Then neither of those is probably getting the background colour of the Track Information panel(s).From my testing this is where the 3 colours other than black in the dropdown come from in the musicbee skin file.
Ahhh ... but there is if you use Firefox. I was having this same issue on Dropbox and another of other websites where I didn't have, nor did I need an account.Well never say never. I installed uBlock, kept all the default settings, and entered your code into My Filters. Restarted Fireox. Clicked on the link again, and I STILL get this damn screen:
You should already have installed the uBlockOrigin addon to Firefox. Open Options and select the My Filters tab and enter thisCodeand click Apply Changes. You'll never see that popup again.||accounts.google.com/gsi/*$xhr,script,3p
But why not just pull panel.BackColor from the handle passed by OnDockablePanelCreated?
Can you, or hiccup, or BoringName please post the file foo_vis_vumeter-0.0.3.65533.fb2k-component someplace where I can DOWNLOAD it?? NOT Dropbox!! I don't want to pester the developer any more.There is nothing wrong with Dropbox or the browser or plugins you are using.
I've updated the zip - VUMeter1.7.zip (https://www.mediafire.com/file/i8vjs3h2salnccl/VUMeter1.7.zip/file)Sorry, but that one also seems to have some regression compared to earlier versions.
I'm going to wait on this one (1.7x) until the behind-the scenes revisions using the same version number settle down, I get 'em mixed up.I've updated the zip - VUMeter1.7.zip (https://www.mediafire.com/file/i8vjs3h2salnccl/VUMeter1.7.zip/file)Sorry, but that one also seems to have some regression compared to earlier versions.
The needle frequently seems to be missing 'beats', or seems to 'exaggerate' others. With the sync/timing also not looking very good.
Not sure how to describe it better, but it's to the extend that it sometimes looks a bit as if the VU meter is listening to another song than I am ;-)
(sample sliders both set to 1)
Will test a bit better tonight.
I haven't had time to do anything custom with the VU skins.That's a pity. Considering BoringName has put in quite some effort in trying to fulfill your LVU suggestions/requests, I think timing-wise this would have been the moment to share some specific feedback and concrete results.
Not something I had considered, I'll give it a shot.
I really need a skin where someone has set a colour for the track information panel so it isn't the same as the panel.ChildBody.Default.As I mentioned before, 'Elemental' has this and displays the issue.
Is there a different element id for the track information panel?
So for me it would be next to the Track Information panels, which would require to get the bg of "ElementPanel.Default".
As I mentioned before, 'Elemental' has this and displays the issue.
And Sample Skin will allow you to see and check all existing panels, their names, and their bg values.
I'm not trying to compete with you or BoringName, and due to health issues have a limited amount of time to spend on my primary hobby, which includes two other players besides MusicBee. I never promised anything as far as timing or output, and am trying to just give some feedback when I can. I don't expect anyone to spend any amount of effort on my requests they don't choose to give. So far every LVU skin I personally liked I've tried with MusicBee and works well with the exception of the Pick Signal 2 skin which used some odd zip scheme. That's all I can really say--I don't have the technical ability to do the type of performance tweaking that you two have, but being an enthusiastic supporter carries some weight too. There sure doesn't seem to be a lot of those out there.I haven't had time to do anything custom with the VU skins.That's a pity. Considering BoringName has put in quite some effort in trying to fulfill your LVU suggestions/requests, I think timing-wise this would have been the moment to share some specific feedback and concrete results.
To me it feels like this LVU stuff may not have been completed, nor has it been tested very well yet, and it's now just left hanging there.
Can you at least give some indication on some percentage of LVU skins that are now working well in VUMeter?
Well never say never. I installed uBlock, kept all the default settings, and entered your code into My Filters. Restarted Fireox. Clicked on the link again, and I STILL get this damn screen:To be clear, in your post regarding this issue you mentioned that your were getting a -Google- popup asking you to log in using your Google account. Your current screenshot shows that Dropbox is asking you to log in and there is no sign of the Google login request.
I never promised anything as far as timing or output, and am trying to just give some feedback when I can. I don't expect anyone to spend any amount of effort on my requests they don't choose to give. So far every LVU skin I personally liked I've tried with MusicBee and works well with the exception of the Pick Signal 2 skin which used some odd zip scheme.Fair enough. I probably misunderstood your original intention for you raising this LVU stuff then.
But perhaps I am misjudging or exaggerating a bit, will do some better testing tonight.Tried it again, but it's really bad. As I said, it's often as if the meter is listening to another song than I am.
#1 Can someone else whose made a plugin confirm something for me before I post another bug report where it turns out there was no bug and I'm just an idiot.....#1 Your guess is better than mine. I didn't even know SkinElement.SkinButton existed (certainly not in the C# interface I have).
#2 Now if add the following line to the skins XML file: <element id="Controls.Button.Modified" fg="255,0,0" bdr="1,20,55" />
To be clear, in your post regarding this issue you mentioned that your were getting a -Google- popup asking you to log in using your Google account. Your current screenshot shows that Dropbox is asking you to log in and there is no sign of the Google login requestphred I'm sorry, I guess I was just getting tired and frustrated last night. Yes you are right, the message I can't get past must be being sent by Dropbox, not Google. That "Continue with Google" button and logo on the message panel was what confused me--funny it was not there when I posted that screenshot, but it's back again now (see below).
phred I'm sorry, I guess I was just getting tired and frustrated last night. Yes you are right, the message I can't get past must be being sent by Dropbox, not Google. That "Continue with Google" button and logo on the message panel was what confused me.Apology accepted, but not necessary. We all get tired and then frustrated at some point. But please answer a question for me... was there actually a Google prompt to log in using your Google account?
Since you also frequently brought up the tool for creating them (both here and on the AIMP forum), I assumed you were using that tool and wanted to create and share your own VU meter skins with us.My intention is to eventually try the tool; the one admittedly amateur attempt I made with the "Avril Lavigne mod" was just done by trial and error examining the ini file for the simple.zip skin supplied with the meter. I do think the LEDs, though tiny, respond quite well to the music even after my changes.
I now understand that that was not the case. But then I also do not understand why it was an issue for you that that tool allegedly contained a virus, if you had no intention to use it. But I have probably not read or understood everything you have said and explained about it, so that's probably on me.
Ah well, so we can then put that LVU stuff to rest now, and move on to other things.
Apology accepted, but not necessary. We all get tired and then frustrated at some point. But please answer a question for me... was there actually a Google prompt to log in using your Google account?At the time I first encountered the problem, the message looked exactly like the crop screenshot I just posted above, complete with the "Continue with Google" button/prompt on it as you can clearly see. When I posted that complete screenshot for you last night, it did NOT have it; why, I do not know and at this point do not care. I'm not trying to BS anybody.
When I posted that complete screenshot for you last night, it did NOT have it; why, I do not know and at this point do not care. I'm not trying to BS anybody.The filter that I sent you, once added to uBlockOrigin is responsible for removing the Google login prompt on non-Google websites. For me, that filter was a gift from the heavens.
The filter that I sent you, once added to uBlockOrigin is responsible for removing the Google login prompt on non-Google websites. For me, that filter was a gift from the heavens.if you ever find a filter that blocks the Dropbox "sign up for free so we can confirm your identity" block on Dropbox sites, I'm all in! ;D FWIW, your filter did "blank out" the "Continue with Google" button from the block panel, so I believe you, it works.
Tried it again, but it's really bad. As I said, it's often as if the meter is listening to another song than I am.
Missing the beat, unexpected rises and falls, it's just very off.
- copied the latest bass.dll
If you're open to alternatives, why not save yourself the headache and provide a panel_skinning .xml that users can modify as they wish (independent of MB's skin).
Will try to upload gif later when satellite internet is a bit more stable.
What's your EQ preamp set to?Not used - 0
Is it the same for all tracks and do they have replaygain tags?All tracks/albums have replaygain tags
Also are you using WASAPI Shared or Exclusive?Normally WASAPI Exclusive but if using outdoor bluetooth WASAPI Shared.
Just saw the edit about portable version as I posted reply :-[
Just making sure you installed the new MusicBeeBass.dll because that's different to the straight bass.dll file.Yes.
I really don't want to be delving in to skin stuff for the sake of one colour. I was hoping I could just grab a modified foreground colour on one of the elements I can retrieve and then users could just set that colour in their skin.xml to whatever they wanted. But it seems the modified element state doesn't work.
Yes.
It's the one that is included in the latest MB patch 3.6.9042 update, right?
Also,
What's interesting, the needle now responds moments before the audio playing.
While I thought that wouldn't be possible it's clearly the case.
So maybe it's now possible to fine-tune the audio/video sync so it's neither leading nor trailing the audio?
That would be a relevant and substantial improvement.
Or, if I am the only one that cares about this, have it using "ElementPanel.Default" as the default colour, and I'll never bother you again about it…
I'll leave the 3 main colours there and add a custom option that opens a colour picker so the user can enter whatever color they want. Probably easier than stuffing around with skin elements, for me anyway.Yeah that might work.
Still, it's a lot of work for you, and adds complexity for the user.
An ideal solution would probably be if the plugin panel would take the bg colour of the panel that is right above it.
But there probably isn't an API available for that?
Would it be possible to have resizing the VU meter working like this?:
I just did enough to get it working and have tacked on changes since which makes it hard to implement that kind of resizing now. With work required to add a vertical option it might be worth doing both at once and cleaning up the code a bit.Thanks for explaining and considering.
Thanks for explaining and considering.
Just to make sure we are on the same page, I don't suggest "adding a vertical option".
My suggestion would be to make this default behaviour and get rid of the existing "Lock Aspect to Y Axis" option.
Also, I don't think many users would have a need for using the bg colour of the panel below the meter instead of the one above it.
(the black bars are showing at the top of the meter, not at the bottom)
But if the meter is placed on top of all other panels, then it should probably take the colour of the one below it.
Already added a custom colour option with the ability to save 16 custom colours.Ok, but if the skinning elements that I listed before would be used, I believe all situations would be covered, and there would only need to be 5 pre-configured colouring options. And most users could probably select one and never have the need for changing it to another one.
How many skins would it actually effect? The skin I'm using, Track Information just inherits from ChildBody.Default which isn't an issue.It's just that my proposed solution would erase any need for guessing or making assumptions on unknown variables such as:
Hi BoringName, I don't mean to pester you, but I was wondering if you had changed or updated 1.7 since hiccup made this comment about it: https://getmusicbee.com/forum/index.php?topic=41692.msg228441#msg228441 (https://getmusicbee.com/forum/index.php?topic=41692.msg228441#msg228441)
I've been using 1.6 with good results and didn't want to update if there are still visually obvious errors in the meter response. Thanks a lot!
Sounds great BoringName, I'm amazed at the speed you have in figuring out/turning out this stuff!! Please keep us informed on the development. Foobar just went "public" on oops's new 32/64-bit beta release of the old foo_vis_vumeter to much acclaim.
If you continue work on this I would encourage you to include a way to adjust any option values (sensitivity, decay, rise, etc) by using keyboard up/down arrow keys with a function key, or a simple slider GUI, as opposed to the mouse wheel. This is because wheels get less precise with age and can skip or fail to change values.
Just don't works on my MusicBee.What MusicBee version are you using?
Just don't works on my MusicBee.What MusicBee version are you using?
not the latestWhat MusicBee version are you using?latest
Man hiccup you got the chops! Editing BIN files and whatnot. Excellent!I appreciate the appreciation and the feedback!
Tested on Foobar 1.6.18 with original 32-bit DLL and preamp=0, very responsive and highly accurate.
Wishlist: make a version of same meter calibrated for use with the new 32/64 bit DLL optionsWell, that should not be necessary.
use green instead of yellow LEDs through -1.0 (keep existing colors for 0, +1, +3) and make the fixed yellow 0-6+ bar red instead.I designed this one for the main purpose so that some educated testing, guessing and referencing/comparing can be done.
In case it is useful for testing foobar2000 VU meter skins or compatibilty, I thought to create a calibrated version of DejaVU Compact for foobar2000.
Just in case it's useful or interesting, there are now two versions of the skin in the download: a dual-bin version (often used for left/right skins) and a single bin version that has the two combined.In case it is useful for testing foobar2000 VU meter skins or compatibilty, I thought to create a calibrated version of DejaVU Compact for foobar2000.That will be handy thanks. I've got everything loading from extracted files. I still need to sort out the different compression and file layout types. The bin files come in a number of configurations, some have the meters stored as separate files in the bin and some have all the data in a single file.
After all, also all of the hundreds of existing VU meter skins were designed for the older version of the plugin, so the new plugin should be as compatible with that one as much as possible so all skins work as intended.OK on VUEditor. Now that the new 32/64 bit DLL is out with the myriad of options people will be moving to it steadily as I did. I may even get rid of my 32-bit Foobar now after the list of it and its other plugins have pretty much completed the move to 64-bit. The good thing is it won't affect the existing BIN structure of yours or any other existing skin so it's just a matter of sliding those over so to speak.Quoteuse green instead of yellow LEDs through -1.0 (keep existing colors for 0, +1, +3) and make the fixed yellow 0-6+ bar red instead.I designed this one for the main purpose so that some educated testing, guessing and referencing/comparing can be done.
At this point we don't know if BoringName is going to succeed in getting these fb2k skins to work.
If he does, I'll then probably decide on which implementation I like better, and from then on either create/modify fb2k or AIMP skins.I'll keep your request in mind when that happens. (or just remind me by that time)
edit
Are you using foobar2000 frequently, and would you be using this version frequently?
If so, I'll create version to your personal liking.
Yes I do use Foobar freqently, as much as I do MusicBee actually. The Deja Vu Compact LED Calibrated Elemental I modified and posted a while back in the skin repository thread is actually my favorite MB-specific skin.Ok, let me know if you are using a specific foobar2000 skin that the VU meter should blend-in with.
I was about to release another version before I start doing some major changes and then I found this sucker - Grundig (https://www.aimp.ru/forum/index.php?topic=52865.msg325260#msg325260). I just fixed a few problems for skins with upside down needlesHmm, actually I have been using that same Grundig plugin for a while now with the last couple of versions of your VUMeter below my lyrics panel, and it's always worked fine here as-downloaded, actually one of my favorites. The needles aren't upside-down they are side-to-side, as designed. What problems were you having with it? At any rate, looking forward to your new 1.8 plugin!!but this thing isn't working at all.
edit: Nevermind, it's working I've just fried myself staring at binary crap for the last few days and didn't notice I had a huge DB offset. So yeah, I'll probably post a new version tomorrow and then get cracking on some of the bigger changes mentioned previously.
https://getmusicbee.com/forum/index.php?topic=41767.msg228505#msg228505 (https://getmusicbee.com/forum/index.php?topic=41767.msg228505#msg228505) ;DYes I do use Foobar freqently, as much as I do MusicBee actually. The Deja Vu Compact LED Calibrated Elemental I modified and posted a while back in the skin repository thread is actually my favorite MB-specific skin.Ok, let me know if you are using a specific foobar2000 skin that the VU meter should blend-in with.
(or a screenshot will do)
Comment from the developer of the new 32/64 foo_vis_vumeter plugin, might assist BoringName or hiccup:In case there are things regarding this that you'd want to raise at the fb2k forum, and my skin would be helpful with it, feel free to share it with them.
https://getmusicbee.com/forum/index.php?topic=41767.msg228505#msg228505 (https://getmusicbee.com/forum/index.php?topic=41767.msg228505#msg228505) ;DA 'sveakul edition' has been added. (same download link)
I tried like hell to figure out how to extract the graphics though to do a slight color change, and that VUEditor has me stumped. Made me appreciate the EASE of dealing with the AIMP analog and LVU meters in comparison. What I was trying to do is brighten up the colors a bit--for the green, going to RGB (2, 234, 2) and for red to (255, 13, 13). And changing the color on the needle pointer to what you used on your original needle for that skin (an orange color).I chose these colours because in my opinion they created the best total balance for this skin.
New version - VUMeter1.8.zip (https://www.mediafire.com/file/p5czze9yxoy5g3i/VUMeter1.8.zip/file)
- No of samples slider changed to buffer size. This will delay the meter slightly. Around 16-18 seems to make it match up with the wave meter for me. The interval slider may have a small effect on this.
Edit: I was meant to do something with the old sample no setting but in typical fashion, only remembered straight after I posted this. This can still be altered manually in the mbVUMeter.Settings.xml file. It's either getting set to 1 and removed next version or I'll add a third slider for it. Probably the former.
What do you have set for the following
I just installed 1.8 right over 1.6, same settings, and I'm sorry this version has serious problems.
An anomaly I noticed related to what you talked about with the sample change to buffer size: in the xml file, the setting label for <sampleNo> remained, and took on whatever the new "buffer size" number was set to on the slider--there was no separate "<buffersize> settng. So how would that jibe with being "set to 1 and removed" if this is where the buffer number is being stored?
What do you have set for the following
- WASAPI
- Ignore Replaygain
- Pre-amp (equaliser)
I use wasapi exclusive.
One thing that also sets it apart is how well the needle functions while indicating RMS values, and the peak indicators perfectly indicating peak values.
1. have the buffer offset working for both the needle (RMS) and the peak indicators.
2. if possible, make the plugin 'event mode active?' aware.
I have created/tweaked two versions of my DejaVU Compact Calibrated skin that should work very well for testing.
An AIMP version and a foobar2000 version.
They should make it easy to compare the pros and cons of either.
I've actually removed any kind of averaging. The mobility settings are doing all the work. It basically acts as an average because it smooths out the peaks.Oh, so it is not RMS but peak based.
New version - VUMeter1.8.1.zip (https://www.mediafire.com/file/c3lji2ljc6psg7f/VUMeter1.8.1.zip/file)
Changes
- Sample no setting changed to buffer. Sorry this will probably reset whatever value you currently have set so you need to recheck the slider value after updating.
- LED will now obey buffer settings.
Oh, so it is not RMS but peak based.
That will be why it looks more lively than AIMP and foobar2000 then.
and:
- LEDs now all light up continuously, irrespective if music is playing or not.
;-)
New version - VUMeter1.8.2.zip (https://www.mediafire.com/file/t8qwqwfyc85zfcu/VUMeter1.8.2.zip/file)Great, working very well.
- Setting "Lock Aspect to Y Axis" removed. The window will now automatically lock the appropriate axis based on the panel size.
Am I correct that what we called '22' is now (the default) '1'?
Hm, the brain cells that connect my eyes and ears may be tired. I'll give them a rest for a while.Am I correct that what we called '22' is now (the default) '1'?I haven't made any changes in that regard. I thought it would be better to wait and see if anyone else had any input on it just in case it's a hardware specific thing. 22 works for me but I'm not a great measuring stick for this kind of thing.
Hm, the brain cells that connect my eyes and ears may be tired. I'll give them a rest for a while.
But for now it seems that I was slightly wrong when I said that '1' works best for event mode.
It then also leads a little bit, so perhaps something like '5' will be better.
And hopefully some other users will provide their specific experiences and opinions on this.
Not holding my breath. But I wouldn't be surprised in the slightest if most people are happy to sit back and go with what you think is best. If you were not involved, VUMeter probably wouldn't have progressed much past version 1.0 and it's all the better for it.Thanks for that, and sorry for probably having been a bit pushy about things.
Not holding my breath. But I wouldn't be surprised in the slightest if most people are happy to sit back and go with what you think is best.Ok, the brain cells that are tasked with audio have come to an agreement with the ones that do visual.
For event mode '5' is perfect.
For non-event mode it's '25'.
Thanks hiccup for that info. I've decided to stick with version 8.0 of the plugin, partly because you put so much effort in using RMS as the basis for your calibrated meters that I just don't want to compromise by using "mobility settings averaging" instead. No shade to you BoringName, but that just seemed like a step back to me after the time you had taken pouring over precision, etc with the meter's development.
I know the BIN meter version is taking a time out right now--a well deserved one! Is that envisioned as a separate plugin, or as an add-on to the AIMP analog + LVU combo?
That's an interesting stance to take. What if I didn't say anything? I'd understand if you said you preferred the movement of one method over the other but it seems you are making a decision because you think there is a difference and not a difference you have witnessed. As long as you like the movement of the meter, does it matter how it gets there? It's still calibrated. Its just a different method of removing the peaks.Don't take this the wrong way please. It's because you ARE involved enough "to say anything" that I take your original development method as being important. I'm the kind of person to whom it does matter how/why the needles are moving, as opposed to if I like what I see--I'd rather BELIEVE what I see, in terms of an established audio measurement. Remember I'm the guy who sweats updates of BASS files nobody else cares about. The fact that your "LED use Peak" option for LED versions is valuable to me is because that also works with a defined measurement. If it's just about averaged movement and the subjectivity of what "looks" best, it becomes something different than how I had pictured the original intent.
For what it's worth, I wasn't using RMS averaging until 1.5 and Hiccup stated very early on they were using a sample no. of one which removed any averaging anyway.
Could have sworn this had different values when I looked earlier :)Yes, you may swear. Do you ever get tired of yourself? I do ;-)
I've decided to stick with version 8.0 of the plugin, partly because you put so much effort in using RMS as the basis for your calibrated meters that I just don't want to compromise by using "mobility settings averaging" instead. No shade to you BoringName, but that just seemed like a step back to me after the time you had taken pouring over precision, etc with the meter's development.My 3 cents on that:
Don't take this the wrong way please.
But then I focussed on the needles a bit more (which I find more important), and they could use a tiny tweak to make them slightly faster.
Also, 'accurate' is a term that should probably never be used for any VU meter.
Just a heads up. The next version will support a directory structure for the skins folder. Due to this, the plugin will no longer support unzipped AIMP/LVU skins.I'm almost starting to feel guilty about asking for this feature, seeing that nobody else has ever asked for this.
I'm almost starting to feel guilty about asking for this feature, seeing that nobody else has ever asked for this.
I am guessing it's going to be something like how MusicBee handles its skin selection menu?
I have to admit that I learned to appreciate that in the current version of the plugin, skins don't have to be zipped.
Thanks to you, and to kamen for his sophisticated spectrum analyzer, we finally have some enjoyable and useable visualization for MusicBee.Do you guys sit and stare at musicbee while music is playing?
Stare at it, listen to it, read it, tweak settings, all kind of stuff! ;)Thanks to you, and to kamen for his sophisticated spectrum analyzer, we finally have some enjoyable and useable visualization for MusicBee.Do you guys sit and stare at musicbee while music is playing?
Fair enough, not judging.
even though I want it to look how I want, I start music playing and then leave it.
No lyrics, or anything animated, don't see the point.
The Vu skins are in User/appdata/Roaming/Musicbee/Vu meter..,
I could also modify my test program to save all the image files if that would be any use to anyone who wants to convert the bin files into a different format or even use them as source files to use in the VUEditor.Wow, you keep going above and beyond. That will be very useful.
I could also modify my test program to save all the image files if that would be any use to anyone who wants to convert the bin files into a different format or even use them as source files to use in the VUEditor.Your fast progress on the BINs-for-MusicBee has been phenomenal to say the least. Yes I think it would be a great idea to have an option to extract/save the image files; for me it wouldn't be for converting to a new format but for being able to re-color and then re-import lamps, etc. into the original BIN.
You can extract frames with the VUEditor but they are fully drawn frames with the needle, glass and LED drawn onto the background. I could extract the needle/glass and LED positions and save them on a transparent background separate from the background image. Unfortunately the needle and glass can't be separated so they might require some editing to re-use properly.
My guess is that it is using lamps only and no needles, but then I'm still not sure how it works exactly.
When Peak was selected, both LEDs and needle would follow the Peak level of the bar meters.
New version - VUMeter2.0.zip (https://www.mediafire.com/file/qvcbuxo2jbhb4s4/VUMeter2.0.zip/file)Congratulations with the 2.x birthday of your plugin child ;-)
I appreciate that Linear was kept as a movement option, which depending on the meter I sometimes prefer using.@sveakul:
It was just added in the last Foobar plugin update to its selection of Levels options.And it has now been removed for the latest version of oops' plugin.
Oops, I forgot to bring a present.New version - VUMeter2.0.zip (https://www.mediafire.com/file/qvcbuxo2jbhb4s4/VUMeter2.0.zip/file)Congratulations with the 2.x birthday of your plugin child ;-)
I posted a gif before falling asleep, starts with "Linear" enabled on the AL-65 Calibrated skin. The source is a high-level chilltrax that then goes into a quiet part before an upswing. Part way through you'll see a part of the VUMeter menu pop in, that's where I dis-abled Linear, and right away it settles into a slow meander, before re-enabling Linear towards the end. Just so you don't think I've been crazy reporting this.Obviously you are not crazy. You are just using a skin that is not intended for playing music.
The plugin should not keep this 'linear' option only because someone wants to use the test version of a skin that was clearly not designed for playing music.Wow, I guess I'm that "someone", haha.. You know, I'm not trying to insult you or confuse people by using "linear" with your meters, calibrated or otherwise. I figured they were all designed for playing music. My preference for more and quicker "movement" is why I brought it up; I made another gif using the regular, NON-calibrated AL-65 that shows the same effect (linked below) going from linear "on" to "off", so put it down to my taste as opposed to the meter.
@BoringName:
If you agree, I think it would be good to remove the 'linear' option.
I think it has brought enough confusion and misunderstanding now.
As mentioned before, oops has also removed it from his plugin. Probably for the exact same reasons.
I'm not trying to spread misinformation or upset anybody just express an observation and opinion.I'm sure that you are not.
By now I have asked several times for you to list some existing VU meter skins that are not working well with the default setting and only work well when unchecking the 'linear' setting.I think you meant to say, "..and only work well when
But you are now only mentioning one single skin of mine, which to me indicates that I perhaps should work on that one.
It is in no way a valid argument to keep an option setting that is (in my opinion) useless, is misunderstood, and is (and will be) confusing users.
I hope you like it.
I personally don't understand why anyone would want to use it because it makes the meter wildly inaccurate but I guess it can make the meter a bit more dynamic in some cases.I'm getting annoyed at myself for asking this same question over and over again:
Obviously it is your prerogative to keep in an option that is pretty much useless, but to me it is sort of a stain in a for the rest pretty much perfect implementation of what is good and effective.
Hiccup's calibrated skins should not be used for music but only for testing?They were created at the very first development stages of the plugin when it was using peak levels.
And if so why didn't they come with this caveat on the download links.
Should the 'Linear' option be checked or unchecked?
Hiccup's calibrated skins should not be used for music but only for testing?
And if so why didn't they come with this caveat on the download links.
I have to admit I'm a bit confused about the calibrated issue as well.What probably makes this 'calibrated' stuff a bit complicated to understand is this:
A lot of time has been spent getting the meter accurate as it can be and complaining about the linear option which trades accuracy for a more dynamic meter (sometimes) while stating calibrated meters shouldn't be used seems contradictory to me.
Because I happened to name one example doesn't mean there was a "single skin" that made me ask to preserve the linear OPTION for users; I'm at a loss to explain the degree of personal "affront" you seem to take at the whole concept, most if it directed at me, as if I am some kind of incompetent.
About the single skin that made sveakul ask to keep in the 'linear' option:
Because I happened to name one example doesn't mean there was a "single skin" that made me ask to preserve the linear OPTION for users;You 'happened' to name that single one only after me repeatedly asking for a couple.
Until somebody finally does that I will remain convinced it is a useless setting.
A request/suggestion:
For foobar2000 skins you can have bin1 and bin2, for left and right meters.
But you can also have bin3.
That one is for when using a skin in mono mode.
See the new AcuVU skin that I mentioned above to see how that works.
(use foobar2000 32bit for this, it looks like the 64bit plugin also isn't able to display it)
I'll look into the mobility options. I believe the "mobility" terminology probably just came from it being translated. Decay seems to be the most used term for the fall of the nedle. I've seen attack used for the rise but not sure that would solve the issue of people not knowing what it means. Rise/Fall speed might be easiest to decipher for a larger percentage of users.Maybe simply call it 'needle action'?
I'll look into the other problems but at this stage I think there is a 99.8% chance I am not going to bother implementing the bin3 option for a couple of reasons.Fair enough.
"There are people who make things happen, people who watch things happen, and people who don't know anything happened." By the level of participation in this thread, and the huge percentage of users of EVERY music player who struggle to understand anything about it or CARE to, I think that test would fail in most courts :-\ . Most wouldn't even know it had ever been there in the first place. And afterwards, if they did notice anything changed in how their Metallica album swings it, would ignore it after 5 seconds. Stores are full of light/temperature/age spoiled beer, and most people just think it's "supposed to" taste that way. There's those adult beverages again, haha..Until somebody finally does that I will remain convinced it is a useless setting.
I suppose I can just remove it and see how many people complain. That's a true test of how popular it is.
If I'd done a bit more testing at the start, I could have saved myself a hell of a lot of work and the linear option never would have come to be.I can understand it can be difficult to abandon something you have put a lot of work and thinking in.
But can we now finally agree it is not working out as you hoped it would, and its current implementation is not useful at all.Here I go again, but didn't BoringName answer that question in his post above?
On the contrary, it creates a mess, both in the outcome, the discussion about it, and what users believe that it does.
And nobody asked for it in the first place. Why the hell cling on to it?
Closer to the point of this.. because you personally have deemed something "worthless" is not a reason to cajole the developer to remove that option for everyone else. That's what I don't understand, hiccup--you're free to NOT use it already; so why force your own choice on everybody else? I want to be able to make the same choice to use or not use it as you have.That's what you have said before.
FWIW I'm not sure what to say about using "nobody asked for it in the first place" as a measure of whether to include a technical option in just about anything.
I keep saying this is my last post dealing with all this, now it is. I am now merely a mum observer, and harbor no bad feelings towards anyone.
@BoringName: I was just looking through some old posts on the AIMP forum and spotted a rare comment on the analog meter movement that might be of interestJust curious:
Finally I saw this formula on the Foobar forum: https://hydrogenaud.io/index.php/topic,126733.msg1053239.html#msg1053239 (https://hydrogenaud.io/index.php/topic,126733.msg1053239.html#msg1053239)
That's why I said calling it "Linear" isn't correct because you are using the peak value which is logarithmic.
It's still technically logarithmic as well but a smoother curve.
Why not just change the names for the two states:
On = (was) Linear = (new) Logarithmic
Off = (was) blank = (new) Curve Smoothing
I might look at a better solution that actually smooths out the curve without messing up the extremes, like what hiccup suggested.For what it's worth:
I might look at a better solution that actually smooths out the curve without messing up the extremes, like what hiccup suggested.OK then. You and hiccup seem to have everything under control
Hi Bee-liever.I might look at a better solution that actually smooths out the curve without messing up the extremes, like what hiccup suggested.OK then. You and hiccup seem to have everything under control
Us end users in peanut-gallery will just keep mum for now :-X
But I can easily change the curve to become more and more linear by simply increasing the 20.
I don't think this will be directly applicable to the challenge you are facing with this, but I thought to mention it anyway.
But I'm still on the position that I think that first an actual problem should be found and defined, before making any effort to come up with a solution.
And after dozens of posts, I still do not understand what the problem is that would require a solution here.
I was just playing around with this very thing in a spreadsheet. I was considering removing the linear option and adding a slider into the needle action menu to adjust the curve. Probably just 10 points in either direction although that might be overkill.....Well, here is the difference I get between 20 and 50.
But instead of having an opinion based on facts, you seem to prefer it being based on guesses, assumptions and emotions.I came out of "mum" (pardon the pun) because when I continue to be personally attacked it goes beyond some setting in a meter. My opinions about anything are my own matter, I don't have to justify them up to anybody's book of standards. The few GIF's I posted at the beginning didn't impress anybody so I gave up on that, I don't have time. As far as your last sentence, if it isn't OBVIOUS that I said that in exasperation and resignation about the whole course of the discussion I don't what to say except "people do say things like that." It was only when BoringName "re-entered" with the surprise (to me) statement that it was checking that OPTION that provided the most accuracy that I continued any further. Since he said he intends to hard-code that now as "selected" all my concerns may vanish.
You have also said before something like 'fine, remove that option'. And now you want to keep it again. What's next?
Since he said he intends to hard-code that now as "selected" all my concerns may vanish.I now understand that (as BoringName also suspected) you had it backwards from the beginning.
You seem to have his ear for further modfiying HOW he hard-codes it, so you still have the ability to get what you want, and that's fine.And you still don't get it.
because when I continue to be personally attacked…I believe you have that backwards too.
New version - VUMeter2.1.zip (https://www.mediafire.com/file/6xfax8o2th4xxav/VUMeter2.1.zip/file)Wow again!
New version - VUMeter2.1.zip (https://www.mediafire.com/file/6xfax8o2th4xxav/VUMeter2.1.zip/file)I've been away for a spell and I see there's been lots of activity here. I just updated to 2.1 from 1.8.2 and upon launching I get an "Error loading skin" popup near the VUMeter element and the skins dropdown is showing "empty" for each one.
edit: On the off chance the meter just displays a blank panel after upgrading. Close musicbee and edit the mbVUMeter.Settings.XML file which should be located in AppData\Roaming\MusicBee\Plugins\VUMeter or just the Plugins\VUMeter folder.
Either delete the MobilityPositive and MobilityNegative lines entirely or set them both to 0.04, save it and start Musicbee.
<?xml version="1.0" encoding="utf-8"?>
<SavedSettingsType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<keepRatio>true</keepRatio>
<framerateMax>60</framerateMax>
<lastSkin>SPL Mk2 Phred on the Lookout</lastSkin>
<linear>false</linear>
<dbOffset>2</dbOffset>
<hideHeader>true</hideHeader>
<singleMeter>false</singleMeter>
<sampleInterval>15</sampleInterval>
<buffer>1</buffer>
<suppressMsg>false</suppressMsg>
<peakLED>true</peakLED>
<removeGain>false</removeGain>
<customColours />
<bgColour>0</bgColour>
</SavedSettingsType>I just updated to 2.1 from 1.8.2 and upon launching I get an "Error loading skin" popup near the VUMeter element and the skins dropdown is showing "empty" for each one.Welcome back from the civilized world phred!
Welcome back from the civilized world phred!Hmmm ... thanks, I think. We'll see how civilized it is come this Tuesday here in the US.
Not sure if this helps, but what I usually do when installing a new version of the plugin is first use the 'uninstall plugin' feature' in MusicBee to remove the previous version.Before I followed your suggestion, I did what I should've done first - reboot the PC. And that took care of the issue.
What version of MusicBee are you using? Include the letter at the end!I just love it when my own words come back to haunt me.
;-)
Before I followed your suggestion, I did what I should've done first - reboot the PC. And that took care of the issue.Ok, great I guess.
Looks like perhaps some other tool or program is keeping something hostage until you restart Windows completely.Possible, but I think unlikely as my PC reboots automatically once every 24 hours. So any hostage taking is (or should be) removed at two in the morning.
Ok, but you are updating the plugin while the computer is on, not when it's off?Looks like perhaps some other tool or program is keeping something hostage until you restart Windows completely.Possible, but I think unlikely as my PC reboots automatically once every 24 hours. So any hostage taking is (or should be) removed at two in the morning.
Ok, but you are updating the plugin while the computer is on, not when it's off?I tried to update the plugin when the computer was off, but nothing happened. :-)
So when it's on, the alleged culprit software will be running?Perhaps. There's nothing in the processes that looks unusual. I've got ESET running a full memory and disc scan now. It'll take a while. I'll report back.
Perhaps it's some AV software?
I tried to update the plugin when the computer was off, but nothing happened. :-)Try using smaller magnets. (assuming you're not using an SSD)
Perhaps. There's nothing in the processes that looks unusual. I've got ESET running a full memory and disc scan now. It'll take a while. I'll report back.It doesn't necessarily have to be related to some virus suspicion.
Try using smaller magnets. (assuming you're not using an SSD)I did but the stuck to my head.
It doesn't necessarily have to be related to some virus suspicion.Which tuned up clean. I add two new VU skins and there seems to be no problem, so I have no choice but to sit and wait to see if anything odd happens again. My PC runs 24/7 with an auto-reboot during the overnight. But it's been turned off during my absence so maybe it was just getting used to being power up again. ¯\_(ツ)_/¯
Have you been testing this on a specific skin that behaved dull without any boost?
Here's the settings file in case it's helpful
[What I did for the curve adjustment is…Ok, thanks for explaining.
Could you please briefly remind me what 'Suppress INI checks' does?The change list from version 1.4 includes, "New option to suppress duplicate value messages with LVU skins"--if that's it, the menu wording needs to be made more clear as to what that actually means.
I think you have explained that earlier, but I can't find it at the moment
I am wondering about the 'centre x axis' and 'centre y axis' options.
Wouldn't it be enough if the meter is always centered in the middle of the panel?
Could you please briefly remind me what 'Suppress INI checks' does?As already mentioned, it's just a check for duplicate values in the ini file. I expect most meters will work just fine even with duplicate values but notifying users of possible issues seemed like a good idea at the time. I've only come across 2 so far with duplicate values but I haven't tested a great deal of LVU meters as there isn't much that can go wrong with them. I could probably get rid of that setting.
I posted a Wishlist suggestion that I think could solve that here (https://getmusicbee.com/forum/index.php?topic=42063.msg229160#msg229160), but neither Steven nor any plugin developer has responded to it, so perhaps that's not a good or valid suggestion.Not much I can do there really
Two other ideas that I believe could solve it are:1. It is possible to get the pixel colour under the mouse but I don't know if I can do that when the mouse is not over the panel VUMeter is in. I'll test it out.
- have an actual colour picker in the plugin, so that you can simply click on a part of MusicBee's panel to set the background colour for the meter
- have the plugin check for the border colour of a skin and use that for background. (I believe the (original) foobar2000 plugin does that)
How about allowing for having the skin file accompanied by an .ini file that contains the preferred settings for that skin?
It would look something like this:
Initially it was always centered on the X axis but sat at the bottom of the panel for the Y axis, when I added the option to center it on the Y axis I added the X axis option to keep them consistent. Personally I can't imagine too many people will uncheck the X axis but I can imagine some users may want the meter to sit at the bottom of the panel for certain layouts. I might be wrong but I don't want to remove that setting yet.When the panel is wider than the proportions of the skin, it will be centered vertically anyway.
Not much I can do there reallyNow you can ;-) (https://getmusicbee.com/forum/index.php?topic=1972.msg229416#msg229416)
Well AIMP and LVU already have ini files. Checking for an associated ini file with foobar .bin files wouldn't be a problem. But I'm a bit hesitant to automatically adjust settings unless they pertain to the layout of the meter. Eg) single meter mode for LVU skins or meters that require vertical display. I don't want to be automatically changing the LED peak settings or anything in the Needle Action sub menu.Fair enough, but:
If the panel is higher than the skin, the default is already that the skin is anchored to the bottom.But if I removed the options it wouldn't be anchored to the bottom anymore, it would be centered. You don't think some users might have a layout where they would prefer it anchored to the bottom?
So for as far I can imagine it would be perfectly fine to remove these option settings.
Now you can ;-) (https://getmusicbee.com/forum/index.php?topic=1972.msg229416#msg229416)I'll add those to the background colour sub menu.
AIMP .ini's don't contain parameters for 'horizontal vs. vertical', single meter vs. dual meter, background colour, curve adjustment, LED 'curved' vs. peak, etc.I meant to imply they already have an INI file that you could add the options to. I don't want to messing around with multiple ini files. So for AIMP/LVU skins I could look for a "Layout" category and grab any options listed under that category. For foobar skins it could just be an ini file with the same name. eg) neutron.bin, neutron.ini
So I don't think there would be any conflict there?
If it is about the .ini extension that might pose a problem because AIMP skins already contain such an .ini file in the .zip, then .txt or .xml could be used instead of .ini?
When a skin doesn't have an accompanying .ini file, the plugin could resort to the setting that was last used before a skin with such an .ini file was selected?
@Boring.Name: two questions! A while back you posted an image extractor for BIN files, "BinExtractor.exe."
- New option "Use Skin Defaults". When checked this will apply any settings in the ini file listed under the [DEFAULT] section.Thanks for fulfilling this request.
Wouldn't it be more obvious and simpler to use the more standard and common hex code for this?
Also, is there a reason for the alpha value also being used? Isn't RGB enough?
Are they? Only time I've dealt with hex codes for colours is website design. Anywhere else is integers or straight RGB arrays like {120, 140, 255}It certainly is for people that use tools such as Photoshop or Paint.NET.
I don't know how he made the *.vu files. I think I'll just leave all of this to the experts for now!!Being my usual honest and blunt 'me':
The only tool I have/am aware of is VUEditor.exe. While I have the translated-to-English instructions from the developer, frankly I find them a bit too "heavy-going" for me. You start losing your edge after age 70, as well as allowable time. I'm going to do a re-read of BoringName's new mods of his 2.2.1 plugin and I'll be lucky if I come out of that in one piece, haha.. The rest I'll have to leave to the developers/coders/designers like you and him. I belong in the "enthusiastic user" department.I don't know how he made the *.vu files. I think I'll just leave all of this to the experts for now!!Being my usual honest and blunt 'me':
Considering your interest and dedication to all this stuff, why not just learn how to use the tools to create VU meter skins yourself?
I'm sure you are capable of that, and it will be both easier and more rewarding compared to trying to bend backwards in trying to extract and modify existing material?
The only tool I have/am aware of is VUEditor.exe. While I have the translated-to-English instructions from the developer, frankly I find them a bit too "heavy-going" for me.You have also frequently referred to a tool to create LVU VU meter skins. (which is what made me think you intended to use for creating and sharing your own VU meter creations)
ChangesThere is a typo when the plugin creates an .ini:
- New option "Use Skin Defaults". When checked this will apply any settings in the ini file listed under the [DEFAULT] section. An example of the available settings -
[DEFAULT]
isVertical=true
bgColour=-16711936
rise=0.03
fall=0.03
curveAdj=5
singleMeter=false
peakLED=false
There is a typo when the plugin creates an .ini:
curevAdj instead of curveAdj
In addition, I just downloaded all of hiccup's revised/updated skins and now -no- .rar skins are showing in the dropdown.See here: https://getmusicbee.com/forum/index.php?topic=41696.msg229676#msg229676
@Boring Name...Speaking for myself, I would be against adding this to the settings menu.
I would find it helpful if you'd add one more menu item: About. Which would show the currently installed version number. Thanks.
See here: https://getmusicbee.com/forum/index.php?topic=41696.msg229676#msg229676Great. Thank you. I replied in detail on the referenced thread. Apparently my three week absence resulted in my not carefully reading the changes that had been made while I was away.
.rar skins don't exist, only .zip (AIMP format) and .bin (foobar2000) skins.
So you need to extract the downloaded .rar files to get the actual .bin skin file.
@Boring Name...Speaking for myself, I would be against adding this to the settings menu.
I would find it helpful if you'd add one more menu item: About. Which would show the currently installed version number. Thanks.
And MB is throwing an error when I enable or disable "Use Skin Defaults."
Is that the only time this occurs for you, when no skin is loaded?Well now that I have the skins properly loading (thanks to hiccup) I have not seen the error appear. Not when enabling "Use Skin Defaults" nor when disabling it.
Just superb; your concepts and design brought this work to fruition in this version.What he said!!!
Is there any way to accomodate the original orientation? Foobar does so using "Left + Right (H)"
This one's a beauty, hiccup.Thanks phred.
In layman's terms, what is the difference between this and your others that results in the long loading time? During which MB is non-responsive.
For as far as I understand the cause of the longer loading time, it is because this VU meter skin is using some rather complicated layers that contain a lot of transparency.
(I could be wrong about that being the cause, but I think I'm not)
I assume it must be due to the way you have implemented the needle changing colour as it moves? Did you need to use multiple needle images for that?Nope, it's not that.
- Loading foobar skins is now done in a separate thread so the Musicbee UI doesn't freeze if loading takes a while.Well, it's nice that there's now a message stating that the skin is loading. But now the skin doesn't load at all. Testing with hiccup's DejaVU Compact LED - Fischer's Lovebird on 2.3, it loads in about seven seconds. With 2.4 I gave up after waiting thirty seconds. At that point trying to change to another skin doesn't work. They won't load. MB is still responsive, but the meter skins don't load.
- Added text to the window to indicate when no skins are loaded or a foobar skin is in the process of loading.
Well, it's nice that there's now a message stating that the skin is loading. But now the skin doesn't load at all. Testing with hiccup's DejaVU Compact LED - Fischer's Lovebird on 2.3, it loads in about seven seconds. With 2.4 I gave up after waiting thirty seconds. At that point trying to change to another skin doesn't work. They won't load. MB is still responsive, but the meter skins don't load.
Could it be your computer being strange again? Maybe it needs a restart.Not only have I done a restart, but over the past four days I reinstalled Windows.
Was Musicbee playing anything at the time? just to rule out any possible conflicts with other Musicbee functions, what happens if you select the lovebird skin then close musicbee and open it again.
- Foobar skins now use a separate shader which allowed me to optimise some of the foobar draw code. The alpha channel is set to zero for the bin file images and I was having to do stupid workarounds with the main shader I was using.Is this something that may have an affect on skin creation? Meaning:
phred : what are your machine specs as far as RAM, processor, and OS?@Sveakul... I'm running Win10 with 16gb RAM and a four core Intel i5-7500 CPU.
Sorry you are still having problems with 2.4! My OS is WIndows 11 with 32MB of RAM and a I7-13700 processor with 16 cores and 24 thread hyperthreading. I have a feeling your processor might not be up to it. BUT, you can load 'em all with 2.3.1, so I don't know, may have something to do with the new separate thread for the BIN skins but now I'm guessing. Nothing wrong with sticking with 2.3.1 when that gives you fast access to all the skin formats.Yup. 2.3.1 works as expected. I've been saying "2.3" in the past few replies, but it was actually 2.3.1. Which I'll keep until BoringName issues the next release and I'll try again.
Is this something that may have an affect on skin creation? Meaning:
- could it influence how (e.g. needle) shadows turn out?
- does this mean that adding a thin transparent border around LEDs is no longer necessary?
Edit: I just extracted Lovebird and put .bin on the end so it's effectively a skin with no compression and it loaded almost instantly. So the loading issue is with the compression library I'm using. Not sure if I will be able to do much about that.I've been using BZIP2 for compression.
You could always just use LZMA and test it with the foobar plugin before releasing it. If it fails in Foobar then use Bzip2.The LZMA versions load a lot faster in the (original) foobar20000 plugin too.
hiccup: DID you do more tuning on the Lovebird skins besides just changing the compression? It's not placebo, both DO operate more accurately and smoothly than either of those test gifs. Quick, responsive but no "jerk." This is the recipe to use for ALL your skins now. Of course "use skin defaults" is checked, Event mode, LED use peak, ignore replay gain. Plugin version 2.4, I'll pass on 2.4.1, the separate thread idea is GOOD.
Sorry if this is the wrong thread for this
OK I guessed wrong on where to ask about new meter possibilities for your plugin. I mentioned it was a DLL in my post.Sorry if this is the wrong thread for this
Probably.
That's a standalone DLL plugin.
OK I guessed wrong on where to ask about new meter possibilities for your plugin. I mentioned it was a DLL in my post.
It's OK there are already plenty of wonderful meters out there your plugin already plays just fine. It was just presented as a concept-for-comment. I think it's odd that the developer, who had already posted AIMP meters on their forum in the past, did NOT do this one as a BIN or "AIMP Analog", especially as all their meters are shown in the same window on the player.OK I guessed wrong on where to ask about new meter possibilities for your plugin. I mentioned it was a DLL in my post.
The best option would be to ask the creator of that DLL to create an LVU or foobar version of it as they would have all the source images to do that.
It won't be able to extract perfect images for needle and glass?
It will provide something that can be used as a starting point, but it will require some image editing capabilities to create something useful from them.
So I am honestly wondering, will this tool actually be making things easier, or allow for getting better results compared to using screenshots, Photoshop and VUeditor?
Would it be an idea to split posts about this BinExtractor into a new and separate topic?
The previous posts on this thread dealing with the Bin Extractor have been split off to its own thread in Beyond MusicBee.
It can be found here: https://getmusicbee.com/forum/index.php?topic=42174.0
@BoringName, i don't understand, are bin files supported by VUmeter? or are they can be used only as basis for creating AIMP meters?
The idea being if a foobar skin is loaded that uses BZIP2. VUmeter will repackage the bin to use LZMA so it will load faster next time, all in the background without the user having to do anything. Possibly enabled with a setting.If you implement something for this, I don't think it should be operating automatically in the background.
Yeah/nah ?
New version - VUMeter2.5.zip (https://www.mediafire.com/file/riakkqdwlea5t7w/VUMeter2.5.zip/file)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'.
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.
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.
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)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)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?
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.
I'm not that keen on supporting multiple layers of archives.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.
What happens with oops version if you dump a RAR in the skin folder that contains multiple bin files?
2. It just shows up on the skin selection list like the rest of them
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.
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.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?
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'm experiencing a strange problem.
Both MusicBee and VUMeter are suddenly responding extremely sluggish.
The letters of the text 'Skin Loading' always have looked a bit crooked to my eyes.
I'm pretty sure it is related to the VUMeter plugin.I'm experiencing a strange problem.The error you reported is a Musicbee error, not an error from VUMeter. Does the slowdown only occur with VUMeter enabled?
Both MusicBee and VUMeter are suddenly responding extremely sluggish.
I'm pretty sure it is related to the VUMeter plugin.
MusicBee v3.6.9101.34338P (Win10.0), 6 Dec 2024 16:32:
System.OverflowException: Value was either too large or too small for an Int32.
at System.Convert.ToInt32(Double value)
at MusicBeePlugin.VUMeter.SetPivotOffset()
at MusicBeePlugin.VUMeter.FillVertexArrays()
at MusicBeePlugin.VUMeter.Window_SizeChanged(Object sender, SizeChangedEventArgs e)
at System.Windows.SizeChangedEventArgs.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 System.Windows.FrameworkElement.OnRenderSizeChanged(SizeChangedInfo sizeInfo)
at System.Windows.ContextLayoutManager.fireSizeChangedEvents()
at System.Windows.ContextLayoutManager.UpdateLayout()
at System.Windows.UIElement.UpdateLayout()
at System.Windows.Interop.HwndSource.Process_WM_SIZE(UIElement rootUIElement, IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam)
at System.Windows.Interop.HwndSource.LayoutFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.HwndSubclass.DefWndProcWrapper(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)Here I go again...
<?xml version="1.0" encoding="utf-8"?>
<SavedSettingsType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<skinFolder>D:\MusicBee\Plugins\VU Skins</skinFolder>
<framerateMax>60</framerateMax>
<lastSkin>M4762</lastSkin>
<dbOffset>0</dbOffset>
<hideHeader>true</hideHeader>
<singleMeter>false</singleMeter>
<eventMode>false</eventMode>
<loadDefaults>false</loadDefaults>
<peakLED>false</peakLED>
<ignoreGain>false</ignoreGain>
<customColours />
<isVertical>false</isVertical>
<centerY>false</centerY>
<centerX>true</centerX>
<curveAdj>0</curveAdj>
<bgColour>-16777216</bgColour>
<MobilityPositive>0.045</MobilityPositive>
<MobilityNegative>0.045</MobilityNegative>
</SavedSettingsType>MusicBee v3.6.9101.34338P (Win10.0), 6 Dec 2024 20:14:
System.OverflowException: Value was either too large or too small for an Int32.
at System.Convert.ToInt32(Double value)
at MusicBeePlugin.VUMeter.SetPivotOffset()
at MusicBeePlugin.VUMeter.FillVertexArrays()
at MusicBeePlugin.VUMeter.Window_SizeChanged(Object sender, SizeChangedEventArgs e)
at System.Windows.SizeChangedEventArgs.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 System.Windows.FrameworkElement.OnRenderSizeChanged(SizeChangedInfo sizeInfo)
at System.Windows.ContextLayoutManager.fireSizeChangedEvents()
at System.Windows.ContextLayoutManager.UpdateLayout()
at System.Windows.UIElement.UpdateLayout()
at System.Windows.Interop.HwndSource.Process_WM_SIZE(UIElement rootUIElement, IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam)
at System.Windows.Interop.HwndSource.LayoutFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.HwndSubclass.DefWndProcWrapper(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)The VUMeter skins are in D:\MusicBee\Plugins\VU Skins
If you right click d:\musicbee\plugins\mb_VUMeter.dll, select Properties then Details, what File Version is listed there?
Is there a mb_VUMeter.dll file located anywhere else on your system?
edit: Also where was the mbVUMeter.Settings.xml file located that you deleted the "lastSkin" value from?
mb_VUMeter.dll is v2.6.0.0
mbVUMeter.Settings.xml is in D:\MusicBee\AppData\Plugins\VUMeter
There is no other mb_VUMeter.dll in the MB root, nor anywhere else on the D:\ drive.
the new auto-find-skin-folder feature doesn't complicate what you've done.
phred I thought you were all set after your BIOS update!Correct. This issue is on a different PC which is my testing box. Although I do admit I haven't tried 2.6 (nor 2.6.1) on my main PC. Which will be done once I figure out this issue on the testing PC.
Start MB anyway you can, and be sure that in "Arrange Panels" any "vumeter" element still on the left side has been dragged back over to the "pool" on the right. THEN, exit MB, and delete any instance of "mbVUMeter.dll", "mbVUMeter.Settings.xml," and the VUMeter skins folder (s) (after backing up the sins!) wherever they exist.I'm pretty sure I've done all that last night, but will try again after trying BoringName's suggestions.
...
I have now tried the suggestions from both sveakul and BoringName using 2.6 and 2.5.1. Same results with the same error message. I'm out of time for a while, but what I'll try next is a brand new, clean and naked Portable install on the test machine. Will report back with results.WAS there a VUMeter element still on the left side of Layout?
MusicBee v3.6.9101.34338P (Win10.0), 7 Dec 2024 13:32:
System.OverflowException: Value was either too large or too small for an Int32.
at System.Convert.ToInt32(Double value)
at MusicBeePlugin.VUMeter.SetPivotOffset()
at MusicBeePlugin.VUMeter.FillVertexArrays()
at MusicBeePlugin.VUMeter.Window_SizeChanged(Object sender, SizeChangedEventArgs e)
at System.Windows.SizeChangedEventArgs.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 System.Windows.FrameworkElement.OnRenderSizeChanged(SizeChangedInfo sizeInfo)
at System.Windows.ContextLayoutManager.fireSizeChangedEvents()
at System.Windows.ContextLayoutManager.UpdateLayout()
at System.Windows.UIElement.UpdateLayout()
at System.Windows.Interop.HwndSource.Process_WM_SIZE(UIElement rootUIElement, IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam)
at System.Windows.Interop.HwndSource.LayoutFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.HwndSubclass.DefWndProcWrapper(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)Continuing with my "test" saga...Phred, you're doing SOMETHING wrong, because the meter works just great here. Let me just address this first part of your post. Let's start over from nothing, another brand-new Portable.. BTW, is this with the "knackered" PC that needed a BIOS boost, chipset update, and all the rest?
On my test PC I have created a brand new, naked, virginal and unmolested Portable installation of MB. I created a small library of about twenty tracks. No new skins, no new plugins, no new nothing. I closed MB and dragged mb_VUMeter.dll (6.1) into the Plugins directory. Restarted MB, arranged the VUMeter panel to where I've been placing it during this test (and where it happily lives on my main PC) and exited MB. Relaunched it and VU panel was all black and a right-click showed nothing. And then MB threw the same error it's been throwing all during this experiment and once I clicked ok, MB closed.
BTW, is this with the "knackered" PC that needed a BIOS boost, chipset update, and all the rest?This is -not- my main PC where I previously had issues. I answered your question earlier today regarding which machine. This is a test machine that has only had portable versions of MB previously and those MB installations are removed when i'm done with whatever it is/was that I was testing.
First of all you shouldn't have tried to manually drag anything. And forget all your skins for now. You should have just opened the new MB, gone to the plugins panel and pressed the "Add Plugin" button, pointing to where you put the VUMeter 2.6.1 zip file. Then it will put the files/folders in the right place itself. Restart MB. Next, you would go to "Arrange Panels", and pull the "vumeter" element over to where you want it. Restart MB for the heckuvit. Now do you get a context menu when you can pick one of the 4 (?) default skins??Again, I commented about this in my previous post...
Don't try to find or make path changes to the xml fle until the above is a success.
On my test PC I have created a brand new, naked, virginal and unmolested Portable installation of MB. I created a small library of about twenty tracks. No new skins, no new plugins, no new nothing.For sake of completeness and perhaps redundancy , I will delete the MB installation and (once again) create a new portable with nothing but a small library and try again.
...
With MB still closed, I removed the dll, and my skins, and the ini file. No traces left in this installation. Restarted MB, went to Preferences > Plugins > Add Plugin and pointed it to a ZIP of 2.5.1. I checked and saw the dll and the default skins where they're supposed to be along with a "new" directory under AppData\Plugins\VUMeter which was empty (no .ini file yet.) Launched MB and it didn't throw an error. Open panel arrangement and dragged the VUMeter panel to where I want it, saved, and closed MB. Opened MB, saw an all black panel where the VUMeter should be with no context menu upon right-click and then MB threw the same error as above.
Restarting MB from this condition causes the same error to appear within five seconds. Still can't copy the error using the button in the error window and clicking ok closes MB.
First of all you shouldn't have tried to manually drag anything. And forget all your skins for now. You should have just opened the new MB, gone to the plugins panel and pressed the "Add Plugin" button, pointing to where you put the VUMeter 2.6.1 zip file. Then it will put the files/folders in the right place itself. Restart MB. Next, you would go to "Arrange Panels", and pull the "vumeter" element over to where you want it. Restart MB for the heckuvit. Check to be sure the plugin appears in prefs/plugins and is enabled (remember if the button says "Disable" it means the plugin IS ALREADY ENABLED--don't push it!) Now do you get a context menu when you can pick one of the 4 (?) default skins??I have once again done a clean install of Portable MB 3.5 and patched to 3.6.9101. Once again I have followed your instructions. I used the 'add plugins' button. The four default skins are in E:\MB Test\Plugins\VUMeter\VUSkins. And once again, I'm getting the same result. You're correct. I'm starting to feel that I don't -want- help anymore. I should just delete everything and stick with my main PC. No more testing. <sigh>
Don't try to find or make path changes to the xml fle until the above is a success. We're starting to reach the "I won't be able to help anymore with this" stage (kidding ;) ).
Still cant get this to work. Error Loading skin. I think i havent extracted files correctly to their correct folders. help
But you can remove all skins from the skin folder and start Musicbee with no skins available and see how that goes.I totally removed all VU skins and VU files.
I was thinking maybe one of the skins is corrupted/broken but if it's just the 4 default skins that's probably not it.Only the default skins. Plugin installed via the "add plugins" button in plugin preferences.
At this point I think it may be something to do with the computer setup, I understand this is a different computer to the one that normally has issues but is it setup the same? Same region etc... I think this might be a problem like Boroda had with my other plugin to do with commas and decimal points.Same region
Depending whether you have the installed version or portable, you need skins to be stored in the following foldersHere's another reason why I'm giving up (temporarily.) Neither you nor sveakul seem to be reading my reports as you're asking questions for which I've already supplied answers.
Installed - C:\users\<username>\AppData\Roaming\Musicbee\Plugins\VUMeter\VUSkins
Portable - C:\Musicbee\Plugins\VUMeter\VUSkins
Here's another reason why I'm giving up (temporarily.) Neither you nor sveakul seem to be reading my reports as you're asking questions for which I've already supplied answers.
I totally removed all VU skins and VU files.
I don't want anyone else to waste time on this. It's a test PC with a test config of MB.
Here's another reason why I'm giving up (temporarily.) Neither you nor sveakul seem to be reading my reports as you're asking questions for which I've already supplied answersPhred, I and I'm sure BoringName are reading them I assure you. For me, it's just that they get a bit difficult to interpret sometimes as far as exactly what was or wasn't checked from my suggestions. E.g., I know it was an extreme newbie type question to ask, but DID you double-check your antivirus on the test machine? You didn't answer. I was not trying to insult you but these are just the kind of things that even experts can completely forget about because they are looking at deeper issues. In my last post, I thought I would begin from your what you described as your first new attempt instead of intertwining with the other redundant information you wrote in the same post. For the sake of a clear "bulleted list" type of approach that would apply universally.
Phred, I and I'm sure BoringName are reading them I assure you.First off, an apology to sveakul and BoringName for my harsh, defeatist attitude last night. I know you guys are trying to help but I was getting frustrated and it showed in my tone.
MusicBee v3.6.9101.34338P (Win10.0), 8 Dec 2024 11:22:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at MusicBeePlugin.VUMeter.DrawTextCustom(Int32 x, Int32 y, Int32 r, Int32 g, Int32 b, String font, Single fontSize, String fontStyle, String text)
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)MusicBee v3.6.9101.34338P (Win10.0), 8 Dec 2024 11:29:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at MusicBeePlugin.VUMeter.DrawTextCustom(Int32 x, Int32 y, Int32 r, Int32 g, Int32 b, String font, Single fontSize, String fontStyle, String text)
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)That's all I can tell you. If you use a calibrated-by-hiccup meter (https://getmusicbee.com/forum/index.php?topic=41696.0), they are a lot more accurate than "eye candy."Doesn't matter how "accurate" they are, unless you're recording they're still eye candy.
First off, an apology to sveakul and BoringName for my harsh, defeatist attitude last night. I know you guys are trying to help but I was getting frustrated and it showed in my tone.
- launched MB and got this error before doing anything, which appears to be a different error than what I posted yesterday with v5.2.1
Oh Dear!
I got the VU meters working using the primary sound driver output, all was good. So I changed to Wasapi Shared and the meters stopped but the audio was still working. I was aware of the probs with Wasapi so I changed the sound device output to virtual cable and launched Tuneblade. Disaster! no sound from my streamer. I had to delete plugin and restart MB and my Streamer. I really think all this Hassle for what is just a cosmetic display is not worth the time. Will it get sorted?
Can you list the feature levels here please.It's getting late, but wanted you to know I've read your latest suggestions. I've downloaded my "special" version and will install it tomorrow. I will also get you the PC specs at that time.
Time of this report: 12/8/2024, 22:01:02
Machine name: MUSICSERVER
Machine Id: {E2B79A58-693E-49B6-8A22-F9E3BEF416B4}
Operating System: Windows 10 Pro 64-bit (10.0, Build 19045) (19041.vb_release.191206-1406)
Language: English (Regional Setting: English)
System Manufacturer: LENOVO
System Model: 5536A1U
BIOS: LENOVO BIOS Rev: 1.0 (type: BIOS)
Processor: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz (4 CPUs), ~3.2GHz
Memory: 8192MB RAM
Available OS Memory: 7862MB RAM
Page File: 1923MB used, 7155MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 12
DX Setup Parameters: Not found
User DPI Setting: 96 DPI (100 percent)
System DPI Setting: 96 DPI (100 percent)
DWM DPI Scaling: Disabled
Miracast: Not Available
Microsoft Graphics Hybrid: Not Supported
DirectX Database Version: 1.0.8
DxDiag Version: 10.00.19041.5198 64bit UnicodeFeature Levels: 10_0, 9_1
Progress!!Maybe for you...
Can you try this version - VUMeter_Phred.zip (https://www.mediafire.com/file/2g6tz4fkcucw98e/VUMeter_Phred.zip/file)This gets really weird using the Phred version.
and this from a little earlier
(https://i.imgur.com/AJMivVn.jpeg)
I couldn't resist.phred OpenGL is delivered by the video drivers. You need to manually update them to the ones that match your system (OS and bit level) from here:
A quick wipe and reinstall of MB and another attempt at adding the plugin.
- restarted MB and got the "no skins found" message before I even tried to add the panel
- clicked 'ok' and MB closed with an error window that I couldn't see and nothing in the error log
- I noticed the .dll in the plugins directory and in AppData\Plugins\VUMeter was the settings xml and an empty VUSkins directory
That's it for now,
The test PC is running OpenGL driver version 8.15.10.29 from November 26, 2012.
I'm not going to spend a dime on the test PC
I have run the OpenGL viewer linked to by sveakul. The current version crashed while scanning. I went to v6 and it scanned successfully. The test PC is running OpenGL driver version 8.15.10.29 from November 26, 2012. It is the latest version for the test PC per OpenGL. It also shows that I'm using the latest version of the display drivers for my on-board video. This was confirmed when I went to the Lenovo site from sveakul's link and there are no drivers for this PC for Win10. Most are for XP, and a few are for W7.Not to beat a dead horse phred, but did that OpenGL viewer NOT give you a page that straight-out shows the OpenGL version as opposed to the "driver version"--like the below shows from the website. I didn't mean to confuse things more!
Yikes! "Too low for zero" (humor!). No wonder it gave you that struggle.You mean zero isn't good? :-)
@ PhredDo try Bee-liever's package first which sounds promising:
There was supposed to be an updated driver for the Q57 chipset provided by Windows.
If you haven't already, turn on optional updates in windows update to see if it finds that new driver.
Alternatively there is the OpenCL™, OpenGL®, and Vulkan® Compatibility Pack available from https://apps.microsoft.com/detail/9nqpsl29bfff?hl=en-US&gl=US (https://apps.microsoft.com/detail/9nqpsl29bfff?hl=en-US&gl=US)
...or forget about running VUMeter on that machine, it won't be worth the hassle.I'm pretty sure this is the correct answer.
Noticed that oops' foo_vis_vumeter version 0.8.0 is now capable of playing hiccup's new meters directly from the *.rar file, complete with the option to use/not use the *.bin settings.
Forget about connecting to foobar's plugin, and if they choose to connect to yours it's an acknowledgement of your skills. Also, IMO the last thing we need is second panels or "tilts" etc. etc. Your plugin seems to me like a fully featured, "done deal," the product of an extreme amount of work and given away for free. Thank goodness we have developers like you and kamen working in MusicBee.A real loud shout-out to BoringName and agreeing 100% with sveakul's comment.
I think you tend to misinterpret "informational" posts as "expectational."
Instead we have the better, MORE useful feature of having the plugin being to switch a BIN to LZMA compression on its own, AND combine separate BIN parts into one.
Also, IMO the last thing we need is second panels or "tilts" etc. etc.
I think being able to split the meters would be a good thing for skin\theme creators so If I can pull that off without having to run a second instance of VUMeter I will.
The last visual element I would like to see for MB is the ability to assign/place specific VST plugin GUI's to fixed or floating windows,
I just tried some of my VU meter skins on foobar2000. They didn't function very well, and I got an instant headache only looking at the options trying to improve on that.Your A-47 Accuphase with BIN/INI is working like a charm right now on foobar v2.24.1 x64; beautiful RMS-area needle response and the red peak lights respond using level "mixed"--change to "peak" and the needles AND lights follow the peaks. The settings I am using with Layout "Left and Right Vertical" are:
It makes me appreciate that 'our' plugin and VU meters 'just work' with maybe only some minimal effort by the user.
edit
I am also wondering if it wouldn't be better if 'Use Skin Default' would be checked by default.
When a skin creator made the effort to create an ini for their skin, why not use it by default?
The settings I am using with Layout "Left and Right Vertical" are:
Thanks! I imagine you meant to say "v2.6.3" for the meter version.Nope, the improved needle action came with 2.6.2
Your A-47 Accuphase with BIN/INI is working like a charm right now on foobar v2.24.1 x64; beautiful RMS-area needle response and the red peak lights respond using level "mixed"--change to "peak" and the needles AND lights follow the peaksThat's nice to hear.
Don't think that your skins aren't being used and sought-after by Foobar users concerned with quality
Question: I have all of hiccup's calibrated meters from the AIMP zipped analog format before they were changed over to BIN/INI. Is there any reason to keep both formats of the same skins?To be clear, those 'calibrated' meters were created during the earliest development of the plugin, and I created them mainly for the purpose of testing and learning.
OK! When BoringName mentioned "There is no point installing this version unless you are having similar issues to phred" (the deal with locating the skin directory) I figured he hadn't been doing the "innards work" with that one, dang it. This is paranoid now, but I assume those improvements were carried over into 2.6.3?
Nope, the improved needle action came with 2.6.2
OK! When BoringName mentioned "There is no point installing this version unless you are having similar issues to phred" (the deal with locating the skin directory) I figured he hadn't been doing the "innards work" with that one, dang it. This is paranoid now, but I assume those improvements were carried over into 2.6.3?
I'm not actually sure what I changed.Thinking back, I believe we did all the discussion and testing that needle action improvements over PM,
Mediafire is just a simple solution for me. I don't get all the spammy crap because I have a piHole on the network and use ad blockers in my browser so I guess it's possibly unpleasant for some users?
I get zero income from the stuff I release here so in turn I'm going the free option. If there is a better free option available I'll consider it.
The only thing I've noticed aside from that is the Vertical Display option seems to need MusicBee to restart to appear properly. But I'm not sure if that's intentional or a bug.