Author Topic: 3DBee (Cover Flow) Plugin  (Read 25780 times)

BoringName

  • Full Member
  • ***
  • Posts: 201
Version 1.3 available for download.
- Fixed a bug that caused the context menu to duplicate when moving the 3DBee element to different panels.
- Set the font colour of the context menu to the current mb skin foreground colour.
- Improved startup. Seems smoother to me and the bug that made the artist/album text disappear when moving the 3DBee element to different panels appears to be fixed.
- Added Boroda's code for localisation of floats when reading the INI files. I can't really test it so hopefully Boroda can give some feedback on that. You will need to change the commas in the INI files back to decimal places or it will fail. Which probably isn't great either but my plan is to get rid of those files.
- Better handling of null values reading the ini files.

I've found a way to make the fonts look better (I think) so that shouldn't be too far away.

kaivsdoom

  • Jr. Member
  • **
  • Posts: 20
Boring Name ,Boroda you guys are awesome!
3DBee works perfectly for me.
Many Thanks   :D 

kaivsdoom

  • Jr. Member
  • **
  • Posts: 20
I have one more question.
When I click on an album in flow, nothing happens.
This works perfectly from the library.
Was that intended, or must something be changed in the settings. Regards

boroda

  • Sr. Member
  • ****
  • Posts: 4595
- Added Boroda's code for localisation of floats when reading the INI files. I can't really test it so hopefully Boroda can give some feedback on that. You will need to change the commas in the INI files back to decimal places or it will fail. Which probably isn't great either but my plan is to get rid of those files.

no, this workaround must always correctly read US notation (dot) for decimal point, no matter if current windows locale is US or Russian/European, and no matter how floats are written to the file (using US notation or current windows locale notation). if float are written to file using current locale, which uses commas instead of dot, then Replace('.', localizedDecimalPoint) method just won't replace anything, and all be working fine anyway.

sometimes the problem is that float.Parse() method always expects string written using current locale, that's why a workaround is sometimes needed.

note that .ToString() method uses by default (without additional parameters) current user locale.

new plugin version doesn't fix this issue, because i've given you wrong code example. "localizedDecimalPoint" declaration must be of course "static readonly", not "const". expression evaluation after "localizedDecimalPoint" declaration must be done on user's pc (using user current locale), not at compile time.

here is the correct example for reading floats:

Code
static readonly char localizedDecimalPoint = (0.5).ToString()[1]; //global declaration
...
//code inside some function
string number = "0.22"; //it's just input example

number = number.Replace('.', localizedDecimalPoint);

float fpNumber = float.Parse(number);
...

also, i think it's better to write .ini files always using US notation (no matter which is current user locale). you at the moment don't write anything to .ini files by plugin, but if you will be ever, here is the example to always write floats using US notation (no matter if current locale is US or Russian/European):

Code
static readonly char localizedDecimalPoint = (0.5).ToString()[1]; //global declaration
...
//code inside some function
float fpNumber = 0.22f; //it's just output example

string number = fpNumber.ToString().Replace(localizedDecimalPoint, '.');
...

boroda

  • Sr. Member
  • ****
  • Posts: 4595
I have one more question.
When I click on an album in flow, nothing happens.
This works perfectly from the library.
Was that intended, or must something be changed in the settings. Regards
you are right, i even haven't noticed this. BoringName is it intended, or is it a bug?

phred

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 9304
Note that my library is in excess of 40,000 tracks among more than 3,000 albums.

Starting with v1.2 and continuing with 1.3, there is an increased use of RAM and drive activity. I understand that given the size of my library this is to be expected. But it was not noticeable in  1.0 or 1.1. Typically with MB open and playing my RAM usage is around 7%. With the two most recent versions, it's close to 40% and spiking around 60%. This is slowing down everything on the PC. Including editing tracks that are not currently playing nor in the now playing list.

Obviously scanning 40,000 tracks uses RAM. Is there any hope that you'll be able to implement my previous suggest about 3DBee only caching the current playlist or now playing list? I think that should help in my case. For the time being I've had to disable it.

Thanks for considering.
Download the latest MusicBee v3.5 or 3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Posting screenshots is here
Searching the forum with Google is  here

BoringName

  • Full Member
  • ***
  • Posts: 201
I did set it up as a static char (not a const) but I didn't set it as readonly. I'll double check everything.

Clicking on the album cover within the 3DBee window currently doesn't do anything unless you have mouse scrolling enabled. If that's enabled you can click and drag the covers to make them scroll. It's a bit glitchy though and enabling that setting hides the scrollbar. But there is nothing in place to interact with musicbee yet.

I have plans to add more interaction with music bee. So clicking on an album might change the file list to display all the songs on that album. And add context menu items so you can click on a cover and add that album to the queue.

Initially it was just going to be a visual thing for my partner as I transitioned her away from iTunes and she missed Cover Flow. I said I would try and find a replacement and here we are. She didn't actually use it for anything, she just liked seeing the covers there and have them flip around. So replacing that was my main focus. But I will keep working on adding more functionality.

Starting with v1.2 and continuing with 1.3, there is an increased use of RAM and drive activity.

I'm not sure what could have happened there. My system is using less RAM than it did in version 1.0 but It is quite a small library.

If you have "Load all covers into memory" unchecked, the only other setting that will effect memory is Album Buffer.

This is basically how it works. When you select an album it has an index number and this is what happens (simplified)
All covers in the range of index - nbLeftAlbum and index + nbRightAlbum are read from the HDD and loaded into RAM.
These covers are loaded into GPU memory and then cleared from RAM. Garbage collection decides when to free up that RAM but it should be pretty quick.
Any albums outside the range above plus the album buffer (half left of index and half right of index) value are removed from GPU memory.

And that cycle just repeats constantly as the flow moves around. A few seconds after the flow stops, all CPU activity should stop and any used ram should free up after a few seconds. The garbage collection can be finicky sometimes and doesn't always free up RAM on a regular basis but it gets there in the end.

The other issue that I need to improve is when you edit tag info. Currently this will cause 3DBee to reload everything which is particularly bad if you have a large library and "load all covers into memory" enabled. There is probably a better way to deal with this but if the user changes the album name 3DBee will crap itself if it doesn't reload as I think it causes the UniqueAlbumID to be changed and the old one doesn't exist anymore.
I'd suggest disabling 3DBee if you are planning on making a lot of changes. But if you have "load all covers into memory" disabled it shouldn't cause that much trouble. It will only reload the images near the currently selected album as detailed above.

How much ram usage are we talking about?


phred

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 9304
I decided to start the day with a PC reboot. Usually it's on 24/7. I wish I had noted some measurements yesterday. But here's where I am right now.

RAM usage on startup without 3D enabled is around 100mb. With 3D enabled on startup is about 150mb and when in use (flowing to current album cover) RAM is between 180 and 200mb and then settles back to around 150.

I do not have "load all covers into memory" and the album buffer is set for 50. I will also had that hard drive activity is not as prevalent as it was yesterday. Since my music tracks are on a HDD, I can hear it spin, so it was rather noticeable. I'm considering swapping out the HDD for a SSD in the near future. 

The big issue, as you mentioned, it when tag editing is being done. Are you suggesting I load all covers into memory if I'm going to be editing more than one or two albums?

In summary I would say at this point things are no different than with v1.0 and 1.1.

Download the latest MusicBee v3.5 or 3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Posting screenshots is here
Searching the forum with Google is  here

BoringName

  • Full Member
  • ***
  • Posts: 201
That RAM usage seems fine to me. Yours is slightly more than mine because of the larger library and probably better quality artwork.

Don't enable "load all covers into memory" if you are editing a lot of stuff. Each time you make a change it will load everything in again. Actually with a library your size I would never enable that setting unless you have a good video card with lots of VRAM, 8gb+ would probably be needed. My partners 2000+ albums takes up 6gb. And I'd only do it if I was planning on having MusicBee open for a long time.

Memory usage could probably be better. I'm currently looking at updating all the OpenGL code as it's using very old methods that have been deprecated for a long time. Trying to update it while translating the code to C# would have been too much for me to do at once. That should increase performance quite a bit and I'm hoping it should remove the need for all these workarounds with loading buffers and just loading in a playlist or now playing etc....

BoringName

  • Full Member
  • ***
  • Posts: 201
Actually it looks like there is a memory leak, I'll see if I can fix it up.

edit: actually no, it's one I just made while testing something out....as you were.
Last Edit: February 01, 2023, 11:05:25 AM by BoringName

phred

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 9304
Don't enable "load all covers into memory" if you are editing a lot of stuff. Each time you make a change it will load everything in again.
I never had it enabled, and don't plan on enabling it. Not even for testing.

Thanks.
Download the latest MusicBee v3.5 or 3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Posting screenshots is here
Searching the forum with Google is  here

BoringName

  • Full Member
  • ***
  • Posts: 201
Version 1.4 available for download.
- Tried another method for loading localized floats from ini files. Hopefully this one works....
- Editing song tags will no longer cause a reload. Adding and deleting songs will still cause a reload for now.
- New playlist config button on the config page. This will open a window where playlists can be selected to always be buffered in Vram. I can't really test its limits so if you enable a particularly large playlist it might cause problems. A different playlist config file is created per library.
- Improved cover display speed slightly so it should look a bit better when scrolling through albums quickly.

Being able to buffer playlists isn't that helpful when all the covers are on display the whole time but I wanted to get this update out to fix the tag reloading issue.

It was fairly major rewrite of the code that handled the buffering of covers so hopefully I haven't created any new issues.

I'm going to start working on filtering what covers are displayed based on what is in the file panel. It's probably going to take a while....
Last Edit: February 05, 2023, 09:35:23 AM by BoringName

kaivsdoom

  • Jr. Member
  • **
  • Posts: 20

Hello
I tested version 1.4, but it doesn't work optimally.
the coverflow doesn't always run when you click on the albums in the library.Unfortunately I can't reproduce the error because I can't find anything in the errorlog.In the end I had an initialization error in the 3dBee dll and the plugin was switched off.I'm back to the 1.3 version. Goes very well

Regards :)

BoringName

  • Full Member
  • ***
  • Posts: 201
the coverflow doesn't always run when you click on the albums in the library

Where are you clicking?

Just keep in mind it won't flow if you click on a song in the same album that is already displayed. I know that sounds obvious but sometimes in testing I will be thinking something isn't working just to realize a big album had basically filled the file list panel so it wouldn't have mattered where I clicked, it was all the same album cover.

I also just fixed an error that can occur when you have a playlists set to be buffered and then remove them all. I didn't change the version number, I just updated the zip file.

kaivsdoom

  • Jr. Member
  • **
  • Posts: 20
hello

the error occurred when i jumped from the music folder to the playlist last added, e.g. different albums, then the flow doesn't work properly, at least for me, so back