Symbol and score size still all wrong in 3.6
I should start by thanking everyone that is involved in making Musescore available for us. Available for free even.
However, I must admit that I am slightly disappointed that the sizing is still a mess (see screenshot). Maybe it is just on Linux? Does not matter much because this issue was, I remember, discussed quite often when version 3.2 came out and that is years ago. I was certain it was enough time to find a solution to this, very annoying problem. Note also that the score itself is a 200%. Why are the symbols in the bar-menu properly sized while they are super tiny in the tools menu? I deleted all previous settings, so the screenshot shows a default install (or rather an Ubuntu appImage)
Comments
See: https://musescore.org/en/faq#faq-310287
HTH
To be clear, solutions to this have existed since MuseScore 2 first came out several years ago. Normally MuseScore can detect the monitor resolution and size everything automatically, but every monitor, display drive, and operating system works differently, and on some systems, for whatever, the systems reports the wrong answer to MuseScore. So you simply need to use the "-D xxx" command line option, where "xxx" is the actual resolution in DPI.
In reply to To be clear, solutions to… by Marc Sabatella
To be clear, the fact that there are workarounds does not change the fact that there is a bug. Blaming "the system" for "giving the wrong answer" is simply an alternative way of saying that a developer is asking the wrong questions.
In reply to To be clear, the fact that… by Ralof
Some Hardware, esp. TV screens, are know to report the wrong resolution to the OS.
And yes, this might be asking the wrong question, but those are asked by the underying libraries we use, Qt.
In reply to Some Hardware, esp. TV… by Jojo-Schmitz
In any case, I think that:
Edit => Preferences => Advanced => application/paletteScale
is better advice to give than the command line DPI setting. Especially since, you know, the OS reports the wrong DPI...
In reply to In any case, I think that:… by Ralof
True. might help for the palette, not for some dialog or the toolbars though
In reply to To be clear, the fact that… by Ralof
Indeed, in an ideal world, all monitors would report sizes correctly in all cases. The reality is, it just doesn't work this way. So yes, there are bugs, shared between the developers of the device drivers, operating systems, GUI libraries, and applications. Getting them all to work together in all cases is a great goal, but as you'll see if you do some investigation of this issue, you'll see there simply is no foolproof solution at this time.
In reply to Indeed, in an ideal world,… by Marc Sabatella
I am a developer myself and I certainly understand the dilemma, but I have never experienced this problem in other software (and I use a lot of stuff for music). I guess there are a couple of ways to make this problem smaller:
Dilemma here is that if OS does not know the DPI, it is likely that the user will not know either, so that leads to...
I think what happens in Musescore is that it takes an extreme value when it does not get a reading, or possibly that the OS report an extreme value when it does not know. Maybe Musescore should assume that extreme values are wrong?
Furthermore - DPI/PPI is not really a relevant number here. My screen is 1920x1080 pixels and 48" diagonal. Do I want the symbols to be scaled according to screen inches? Should the symbol be the same size on my 48" screen as on my laptop's 15"? That is not practical since I sit 2 meters away from my big screen and only 50cm from my laptop. So if you decide that a symbol should be 1/4 inch on every screen, it might look great on the laptop but it will look very tiny on a big screen.
In reply to I am a developer myself and… by Ralof
The problem though is that the OS does give information about the DPI, it is just wrong at times
A 48" screen is very likely a TV set, esp. at that 1920x1080 resolution (Full HD). A very likely candidate for getting the DPIs being reported wrongly (here it really is very low res, sqrt(1920*1920 + 1080*1080)/48 = 46, but I'd bet MuseScore doesn't get that right)
In reply to The problem though is that… by Jojo-Schmitz
Yes, I covered that. But I also concluded that regardless if it is reported correctly or not - DPI is always, in the Musescore use case, irrelevant.
What a DPI situation makes is that an object will be displayed at the same size regardless of screen size. That is, apart from when printing, far from ideal. Imagine the laptop and the stadium 12x8 meters? Maybe 1 or 2 DPI? Should the score be in the same actual size? The 1/4" note will be hard to read from row 43 in the concert hall :)
In reply to Yes, I covered that. But I… by Ralof
Well, it is not. As screens only report y/x pixels and DPI, but never their real diameter, their physical size
In reply to Well, it is not. As screens… by Jojo-Schmitz
As Ralof, I don't understand why MuseScore needs to play with DPI in the first place.
In reply to As Ralof, I don't understand… by frfancha
How else should it work, not knowing the physical dimensions?
1920x1080 on a 10" tablet is High DPi, on a 48" TV it is low DPI. You can't treat both the same
In reply to Well, it is not. As screens… by Jojo-Schmitz
Let's put the question like this: When is DPI important for Musescore?
The physical size, while not reported, would be resolution / DPI. Given that, I think that Musescore actually did what it was told to do - display the symbols at a certain absolute size. My 48" screen has 40DPI horizontal while my 15", with the same resolution, has 128DPI. Using DPI as a factor while determining object sizes in Musescore, they WILL be displayed much smaller in a relative way on a big screen. If you measure the object sizes in millimeters or inches, with a ruler on the screen, maybe they have the same size if all the equations add up. But that is not what anyone wants!
Looking at my screenshot above, I think this is exactly what has happened - the menu bar has been set with some default sizes while the dialogs, and the symbols within the dialogs, have been sized through DPI. That is why they are tiny on my huge screen.
Conclusion: The problem is not that the OS reports the wrong DPI, the problem occurs when it reports the correct DPI!
In reply to Let's put the question like… by Ralof
DPI matters because a score when viewed at 100% zoom level should be quite approximate of the real life size of that paper.
In reply to DPI matters because a score… by jeetee
Yes, I realize that it is your goal. I am telling you that's the wrong goal. A bigger screen makes all stuff on it bigger. That is what is expected to happen. The bigger the screen gets, the further away from it you can be. If the objects on the screen stay the same size...
DPI is for printing.
In reply to Yes, I realize that it is… by Ralof
Tell that to my laptop setup where the internal screen is about 144dpi, the first external 24" monitor is 96dpi and the 2nd one (also a 24") is 244 dpi.
I do like it when the UI remains legible when moving from screen A to screen B.
In reply to Tell that to my laptop setup… by jeetee
What happens in a dual monitor setup, with your monitors, when you drag Musescore from monitor A to monitor B?
When you start Musescore with the -D option, which of your three DPI's do you choose?
In reply to What happens in a dual… by Ralof
When changing displays after launch it becomes too tiny or to large, just like many other applications.
I have separate shortcuts depending on which display it should launch.
In reply to When changing displays after… by jeetee
"just like many other applications"
No, that is not true. The wast majority have no problems with this. Methinks the idea you describe above: "a score when viewed at 100% zoom level should be quite approximate of the real life size of that paper" has led you astray. There is never a situation where that is relevant on a screen.
In reply to "just like many other… by Ralof
No, that is not true.
Sure it is, one day when covid restrictions are lifted you are welcome to come to my office setup and compare sizes. But don't go denying my reality.
There is never a situation where that is relevant on a screen.
So you're saying that publishing software is not a thing?!
It is extremely important that a zoom level of 100% matches what is be seen once printed when designing documents that are meant for real paper. It ensures a good pre-print representation of legibility of your document.
Now what I can agree on is that in essence this shouldn't affect UI elements as much as it does the score view. But then again, do you really find that a 24px toolbar button in a design created for a 96dpi screen should eat up more actual screen real estate on a lower dpi screen? Or that it should become so tiny that it is no longer identifiable on one of those retina screens?
What then in your opinion should a document level of 100% correspond with if not the real life thing?
In reply to No, that is not true. Sure… by jeetee
"What then in your opinion should a document level of 100% correspond with if not the real life thing?"
Well, when I print it, when I make it a "real-life thing", I'd certainly expect a page to perfectly fit the paper in my printer (if I have set up the format correctly in Musescore). On my screen, however, I could not care less about "real life" sizes, not as long as what I see is a scaled version of the finished result. The scale itself needs to be something that I can comfortably view on my screen, at the distance I view it from. If a page of my symphony takes up 1/4 of the screen when I use a 24" 1920x1080px, I'd expect it to still use 1/4 of the screen when I use a 48" screen that has the same resolution.
I can easily set the default zoom level in the settings (I use 250%) so that is not a problem. However, starting the program with my real DPI makes the symbols in the dialogs tiny and unreadable. Use the DPI reading for calibrating 100% zoom if you like, but icons and text sizes should ignore the DPI reading. The text and main nav bar are sized correctly, so why use another formula for the dialogs?
In reply to "What then in your opinion… by Ralof
These dialogs have their sizes set in pixels, nothing more, nothing less.
In reply to These dialogs have their… by jeetee
Seems like we're dancing to different songs here. Look at the screenshot in OP again.
In reply to Seems like we're dancing to… by Ralof
Yes I have, and what you're seeing there are icons and symbols in cells that have a certain pixel size. If you then don't scale those according to the DPI, then as you witness in that screenshot they will turn out to be tiny.
That is exactly what happens when one doesn't care about and scale according to DPI..
In reply to Yes I have, and what you're… by jeetee
Sorry, but you're wrong and I am slightly shocked that you cannot see it. How come the main toolbar is properly scaled? How come the text is properly scaled? The reason the symbols in the dialogs are wrong is simply because you try to scale them according to DPI. An attempt that makes no sense at all. The expected behavior for all software is that dialogs, the symbols in the dialog, actually everything in the application to scale equally when the resolution changes. On screen A with XX DPI , all objects should have the same proportions as on screen B with YY DPI. If your screen size changes, everything, every object on the screen, should increase or decrease in exactly the same amount, regardless of what they are...
Anyway, I don't think I'll get anywhere here, so goodbye.
In reply to Sorry, but you're wrong and… by Ralof
What you might not be aware of is that menus and text aren't defined in pixel sizes, but in points. And in the case of the file menu, that is offloaded to the OS window manager.
It's really a simple thing: The symbol being drawn on screen by default is defined as X pixels. So if you don't account for DPI that symbol will be smaller on a high DPI screen (as seen in the screenshot) and larger on a low DPI screen, because their pixels have a different physical size.
It really is as simple as that.
In reply to I am a developer myself and… by Ralof
FWIW, I experience the problem with lots of software. Please believe me, do some research if you like, it really is not a solved problem, that's why the various different settings and workarounds exist.
But yes, at some point we would like to add a way to enter the proper resolution from with MuseScore itself so people don't have to use command line options etc. Unfortunately, not all problems of this nature can even be solved with the command line options. Depending on the specifics of the system, sometimes an environment variable is needed, other times an OS setting.
DPI is the relevant value, though. That's what MuseScore needs to know in order to determine how many dots to draw to an inch. The goal is that with your score viewed at 100%, it should be life sized - same as a piece of paper.
It is a good point, though, that with extremely large monitors like your, you would sit further away and thus want icons and text at least to be bigger. So we do provide options for that in Edit / Preferences / General. Also an override for the palette scaling in Edit / Preferences / Advanced. But the score really should be life sized at 100%; if you want to view it larger than that you can simply zoom in.
In reply to FWIW, I experience the… by Marc Sabatella
In 100% zoom, I see one bar on my mobile and eight pages on my big screen. While working with the composition, but situations are bad. Now, changing the zoom is not a huge problem but it is still an unnecessary one. Maybe a button "view score as life-sized" would make more sense? The icons should in any case not be affected by that.
I've conceded that using the DPI for "100%" might be reasonable, but using it for tools and dialogs are not.
In reply to In 100% zoom, I see one bar… by Ralof
"view score as life-sized" is (or should be) the same as 100%
In reply to "view score as life-sized"… by Jojo-Schmitz
I'm offering an alternative to seeing 100% zoom as a piece of paper. It is a number that is simply irrelevant on a screen. You never see Word or any office program starting up with letter sizes equal to the print size.
In reply to I'm offering an alternative… by Ralof
Word is a text editor, not a desktop publishing software
In reply to Word is a text editor, not a… by Jojo-Schmitz
So that is what Musescore is? A desktop publishing software?
Didn't know. I guess I go elsewhere for composing then.
In reply to So that is what Musescore is… by Ralof
Score editing and publishing, creating sheet music. That indeed is the primary use.
Can be used for composing too.