Author Topic: VUMeter Plugin  (Read 50418 times)

sveakul

  • Hero Member
  • *****
  • Posts: 3262
Thanks for the clarification.  I still stand by my impression that since hiccup updated these a few hours ago they do look and react more accurately in MusicBee than the versions I used yesterday, even if not due to changes in the plugin itself.

sveakul

  • Hero Member
  • *****
  • Posts: 3262
Sorry if this is the wrong thread for this, but the AIMP people just recently put out this DLL plugin type LED VU meter that operates separately from the "regular" analog and LVU meters, "LoudnessMonitor."  Pretty and responsive but have no idea if it's port-able to a "normal" VU meter format: https://www.aimp.ru/?do=catalog&rec_id=1319


BoringName

  • Sr. Member
  • ****
  • Posts: 916
Sorry if this is the wrong thread for this

Probably.

That's a standalone DLL plugin.

sveakul

  • Hero Member
  • *****
  • Posts: 3262
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.

BoringName

  • Sr. Member
  • ****
  • Posts: 916
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.

sveakul

  • Hero Member
  • *****
  • Posts: 3262
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'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.

phred

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10266
The previous posts on this thread dealing with possible performance issues and the best way to resolve them have been split off to its own thread in Beyond MusicBee.
It can be found here: https://getmusicbee.com/forum/index.php?action=post;msg=229910;topic=42169.0
Download the latest MusicBee v3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Custom Forum Search
Posting screenshots is here

BoringName

  • Sr. Member
  • ****
  • Posts: 916

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.

Pretty much.

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?

I think the only real benefit is it makes it easy to get the background and LED images. It will be able to get the needle where no glass was used. Personally I think exporting all the frames is pretty nuts but someone on Hydrogen asked for it so I figure if that's what they want to do it's up the them.

Would it be an idea to split posts about this BinExtractor into a new and separate topic?

Maybe. I really don't want to spend any more time on it because of the reasons above.

I was floating around with the idea today of allowing the user to select a pixel in the background image and entering a new colour where it would replace the colour of all the pixels with the same colour as the selected pixel. Effectively allowing the user to change some colours on the skin while it's still packaged as a bin file.

But the pixel RGB values would have to match exactly. I can't see it being that useful except for skins that have a uniform colour. Any kind of gradients would just result in a mess. It would only work for the background image, not the LED or needle.

But I think I'll drop the idea, it's a lot of work and will probably end up creating a half arsed meter with blotchy colours. I also had nothing but trouble today trying to recompress the bin file. I did manage to automate combining meters that use separate files eg) foobarskin1.bin, foobarskin2.bin into a single bin file but only if it was uncompressed. It's a pointless endeavour really as it has zero effect on how the skin operates.

Here is the stupid crap I had to deal with today-
Compress the file with the compression library using LZMA - The compression library couldn't open it and neither could 7-zip. I doesn't save the required header details and I had no luck manually trying to generate them.
Compress the file with the compression library using BZIP2 - The file could be opened with the compression library but compressing it took over 2 minutes.
Compress the file with 7-zip using LZMA- The compression library couldn't open it. The header 7-zip creates is different to VUEditor.
Compress the file with 7-zip using BZIP2 - The file could be opened with the compression library and only took a few seconds to zip. But as reported previously, the compression library is slow as balls opening Bzip files.

And that's me done for the day.

phred

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10266
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
Download the latest MusicBee v3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Custom Forum Search
Posting screenshots is here

BoringName

  • Sr. Member
  • ****
  • Posts: 916
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

Thanks!

New version - VUMeter2.5.zip

Changes
- Small improvements to needle movement. It should be a little less shaky. This will most likely be the final change I'll make in this regard.
- Added a busy check when loading foobar skins. Because the delay is caused by the compression library I can't stop the process to reload a different skin and I don't want to deal with multiple loading threads. Just let the skin finish loading before trying to load another!
- Improved the right click menu display speed. It's much more responsive now, especially when navigating nested folder structures in the skins menu.
- Fixed the bug that occasionally caused the right click menu to display in the top left corner of the screen. Actually it was more of a workaround for a bug with a ToolStripMenuItem object that's existed since at least 2009 , I guess microsoft might fix it one day....


BoringName

  • Sr. Member
  • ****
  • Posts: 916
Given the changes I just came up with for the binExtractor program. I was just toying with the idea of automatically converting foobar skins.

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.

Yeah/nah ?

If I did run with this it would also involve automatically merging separate bin meters into one bin. Because of how the whole thing is coded I wouldn't want to mess around saving them back as separate bins.

boroda

  • Hero Member
  • *****
  • Posts: 5171
@BoringName, i don't understand, are bin files supported by VUmeter? or are they can be used only as basis for creating AIMP meters?

BoringName

  • Sr. Member
  • ****
  • Posts: 916
@BoringName, i don't understand, are bin files supported by VUmeter? or are they can be used only as basis for creating AIMP meters?

Yes, fully supported.

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.

boroda

  • Hero Member
  • *****
  • Posts: 5171

hiccup

  • Hero Member
  • *****
  • Posts: 9107
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.
Yeah/nah ?
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.

If possible, some indication when a skin exists from separate bin1 and bin2, or uses BZIP2, and then having a right-click option to transform that skin could work though.

Or without some indication implementation, just an option where a user can right-click a 'folder' containing VU meter skins (or an individual skin), and select 'convert BZIP2/dual bin skins'.
Last Edit: November 24, 2024, 09:31:04 AM by hiccup