Inconsistency of scale in palettes according to the type of workspace

Most liekly the issue depends on display resolution. I will investigate, but I didn't notice any such issue in my testing on my system originally.

I am not succeeding in reproducing this, but I am not totally undersdtanding the steps.

At step 2, do you really mean you are saving the score itself (File / Save or Ctrl+S)? Palettes normally have nothing to do with scores. I don't see any difference in behavior whether I save the score or not, but I want to be sure I am understanding.

At step 3 , do you mean to reload the score - with MuseScore still open - or do you mean to close then restart the program? Again, I don't see a difference either way, but want to be sure.

I can definitely imagine that any workspace or palette you saved *before* this change might look different if loaded into a build made *after*. So are you sure you are not somehow accidentally loading an older worksapce?

Hmm, I have a theory. I see now that when a palette gets written, it only stores the scaling factor ("mag") if it is not 1.0. If it is 1.0, then it doesn't bother writing the scaling factor since 1.0 is the default. However, when doing this check, I don't think it is correctly accounting for the display resolution. I suspect the best fix will be to always write the scaling factor. But since I can't reproduce the problem, I do want to fully understand it before proceeding.

In addition to answering my questions above, could you also explain *how* you are starting MuseScore? That is, from the command line, by double clicking a program icon, by double clicking a score in Windows Explorer, etc? I wonder if the determination of the display resolution somehow depends on this.

Also, I'd love to see a copy of the custom workspace, if you know how to find the file. Probably under AppData somewhere, and it would have the extension ".workspace".

I may have figured this out, although it involves some pretty major guesswork on my part.

Guess #1: you didn't actually mean to say "Key Signatures" in step 3; the issue really does affect only the five palettes you mention. Actually, also Bagpipe Embellishments, which would only be present if creating a custom version of the Advanced workspace.

Guess #2: your display has a resolution of 120 DPI, or you are using the "-x 1.25" option to scale your interface by 125% over the standard assumption of 96 DPI. Actually, it's possible neither of these are true, but that somehow Windows has decided that 120 DPI is the appropriate resolution to report to MuseScore. What's weird is that I though Windows 7 did not do this, but whatever, I need this to be true for this to make sense to me.

Guess #3: my earlier analysis of the source of the problem is correct - "mag" tags are not being written to the workspace file for these specific palettes because we are failing to account for the display resolution properly when deciding if we need to write the tag.

Here's what I think is happening:

The five palettes you list - not including Key Signatures, but with the addition of Bagpipe Embellishments - are supposed to be set to 0.8 scaling. If my earlier analysis is correct, the problem would happen if MuseScore thinks your display resolution is exactly 120 DPI, so your display scaling factor is 1.25 (120 / 96). This would cause the palette scaling of 0.8 to be recorded internally as 1.0 (0.8 * 1.25), and hence not be written to the workspace file, whereas it should have been written as 0.8. And this in turn would cause them to be rendered full size when the workspace is read back in.

So if I am right about all of this, my proposed fix of just always writing the "mag" tag should solve the problem. As a test, do see if you can find the ",workspace" file and post it here so I can look at it. If I end up seeing something other than what I am expecting to see, I guess I will have to think some more about it. But the change I am proposing makes sense anyhow, so I will submit it.

Posts crossed. Darn, it looks like you are still saying Key Signatures has the problem, which kind of ruins my theory. But I do still want to see that workspace file if at all possible!

Fixed in branch master, commit 1e0c6a171d

fix #95466: wrong size palettes with 0.8 scaling when using 120 DPI display

Fixed in branch master, commit e9c7335ee0

Merge pull request #2358 from MarcSabatella/95466-palette-scaling-glitch

fix #95466: wrong size palettes with 0.8 scaling when using 120 DPI d…

Great. Meanwhile, I have pushed my fix, a new nightly should be available soon (just the master). There definitely *would* be a problem with systems whose display resolution is exactly 120 DPI according to my analysis, and I can reproduce it if I use the "-x 1.25" option. So that much was worth fixing, and my change does work for me. We'll see if it works for you as well, but I'd still like to see that workspace file if possible.

Try here: C:\Users\*****\AppData\Local\MuseScore\MuseScore2\workspaces. Actually, with the nightly builds it might be MuseScoreDevelopment instead of MuseScore2. Or could be somewhere else entirely. Sorry, I don't really know for sure.

I've just ran some tests on my Win7 system as well, but don't see any noteworthy changes between 2.0.3(697b8fc), master-nightly(6205e12) and current git from master(3543170).
Note that my screen is set at 96dpi.

@cadiz1 To find the workspace file on Windows7, open an explorer window and enter the following location %USERPROFILE%\AppData\Local\MuseScore\MuseScoreDevelopment\workspaces
Note that this location is shared by all nightly versions; doing a reset to factory defaults for any nightly will erase this location!

Another thing to test: after creating the custom workspace, right click the time signature palette, click Palette Properties, and tell me what you see as the "Scale". Then do the same after restarting MuseScore. I'm guessing you'll see 0.8 the first time then 1.0, although that won't really prove anything - it will just be some evidence my analysis might be correct.

The new nightly on master is available, BTW. Hoepfully it fixes the problem.

Fixed in branch 2.0.3, commit 981d82f0c7

fix #95466: wrong size palettes with 0.8 scaling when using 120 DPI display

Well, since you found the workspace file, I *would* still like to see it. Just attach it here. BTW, it is in ZIP format.

Automatically closed -- issue fixed for 2 weeks with no activity.