A couple of niggles...?
Just saw MuseScore 2.0 was now in beta and installed if for the first time yesterday. First impressions are good... this is a seriously impressive app which I have no doubt competes with the big players.
So, I dived in and started engraving a short score. It's mostly very intuitive, and I applaud the development team for that. A couple of things striking me, which I wonder if I'm just missing something simple...
1.) It seems like the tuplet numbers don't always align along the beam. In the short score I'm working on, this seems to happen about 1 in every 3 times. Almost like the tuplet brackets are invisible, yes, but not being angled parallel to the beam.
2.) The default diamond note-head it pretty unorthodox looking. Is that a bug? The second bar here is using the "mi" noteheads instead.
3.) Something weird going on with the kerning in the footer...
4.) And on the subject of typgraphy... this is a more general point about fonts. I'm curious what's going on behind the scenes. If I use an OTF, is MuseScore automatically selecting the appropriate features available, such as tabular lining figures? For example, I see that lining figures are being chosen by default in text field, but it could be nice to use proportional at times. Do we have a simple way of choosing stylistic alternatives? I don't see anywhere to allow me to set those things manually. Are we able to adjust kerning and stuff like that on text elements? Again, I'm not seeing it, but I only started using this yesterday!
5. Slurs to me seem a little to thin. Or, perhaps I should say some of the slurs feel a little to thin, especially when you compare them to a tie. When I attempt to thicken the slurs up in style->general that also affect ties, which then seem too thick. Am I missing something here? Is it possible to a) adjust slur thickness globally without affecting tie thickness and/or b) adjust slur thickness on a case-by-case basis.
Anyway, I hope this doesn't come off as a negative first post. I'm overwhelmed by how great MuseScore 2.0 is, and I'm hoping to use it as my main engraver from now on.
Cheers!
Douglas.
P.S. system is Windows 7 (64bit) Home
| Attachment | Size |
|---|---|
| tuplet-placement-1.png | 22.31 KB |
| diamon-notehead.png | 7.19 KB |
| footer-kerning.png | 3.73 KB |
Comments
Tuplet brackets indeed are not parallel to the beams (for beamned triplets, but horizontal, switch them on in Inspector (F8) to check. Looks like a bug to me, for non-beamed tuplets there are diagonal.
The notehead issue seems to be with Emmentaler only, not with Gonville or Bravura. Not sure whether this is a bug or just a difference?
In reply to Tuplet brackets indeed are by Jojo-Schmitz
Tuplet number/bracket placement... yes, I guess we can call it the "non-beamed diagonal tuplet" bug. Quite a big problem.
Yeah, I see that the diamonds are normal in Bravura.
I'm having a look at the Git now. I guess this file— https://github.com/musescore/MuseScore/blob/master/fonts/bravura/metada… — is where different tweaks to the kerning and stylistic alternatives are being declared, right? I also notice an array declaring slur thickness and tie thickness, so maybe that's also what I need to look into?
In reply to Tuplet number/bracket by douglas81
See #33911: tuplet brackets for beamed tuplets don't follow the beam's slope, which I just entered.
FWIW, MuseScore uses Qt as its underlying engine for text / font rendering (as well as for much else). So any really specific questions about how MuseScore handles kerning or whatever, the answer is usually going to be, "MuseScore does whatever Qt does".
For the copyright text - what OS are you on, and what font are you using? I believe kerning of FreeSerif - the default text font in MuseScore - is not working correctly on MacOS. Your name kerns just fine on my Linux system. You could try a different font (Style / General / Text / Footer.
Slur thickness is a configurable setting - see Style / General / Slurs/Ties.
The issue with the diamond notehead in Emmentaler looks like a bug to me. I won't quibble the shape - I guess there is some point to it, and presumably it is inherited from LilyPond. But the alignment with the stem is way off. Could be something not right about the SMuFL integration, or an aspect where this glyph just isn't SMuFL compliant.
BTW, you can move the tuplet number - either by dragging or using the Inspector. If you turn on the bracket (also using Inspector) you can see why the number is aligned as it is - the bracket is not angled.
In reply to FWIW, MuseScore uses Qt as by Marc Sabatella
but slur thinkness is not configurable independantly from tie thinkness, I understand that is what the OP wanted?
In reply to but slur thinkness is not by Jojo-Schmitz
You're right; sorry, I should have read more carefully.
In reply to but slur thinkness is not by Jojo-Schmitz
Yes, so in the following excerpt, for example...
I feel like the tie is too thin compared to the slur. But, if I change the slur thickness in style->general then it also proportionally increases the tie, which then feels too thick.
In reply to Yes, so in the following by douglas81
I think here it is more related to the lenght of that slur compared to that tie, which has an effect on the thickness, rather than being a tie vs. slur issue?
In reply to I think here it is more by Jojo-Schmitz
Perhaps. Sometimes the slurs look fine, as I said. Which is why my addition question was whether or not it's possible to thicken slurs up on a case by case basis. Regardless, at the moment this is the one area where LilyPond's output seems to be better (by default) that MuseScore 2.0.
In reply to Perhaps. Sometimes the slurs by douglas81
I suspect you'll find other areas where LilyPond does better than MuseScore soon enough :-). But it is quite a compliment that we can maintain that illusion
FWIW, Elaine Gould's "Behind Bars" is considered the definitive modern reference on matters of notation and is what we refer to most often (although I definitely consult other sources as well, including a plethora of published examples from different time periods and genres of music). While Gould says on multiple occasions that ties should be *flatter* than slurs, nowhere that I can see does she suggest they also be *thinner*. And her examples all show them to be of comparable thicknesses when they are of comparable lengths.
So I don't know that there is any really objective basis for complaint with MuseScore's *defaults* here. But sure, making these configurable separately so you can, if you wish, implement a personal preference for thinners ties, seems like a valid feature request.
In reply to I suspect you'll find other by Marc Sabatella
Yep, I have Gould's book open in front of me :) That and Kurt Stone's!
Exactly, she doesn't say it should be thinner. I'm not suggesting that either. What I mean is that I want the slurs and ties to look like they are the same thickness, but as you can see, that is not the optical effect, regardless of what the number in MuseScore's settings say. Take this, for example...
That's at default. To me, those slurs are just too thin compared to the tie. So, if I go in and change mid slur thickness to .19sp, and now...
The slurs look great, but the tie is getting a little bit fat and comical looking. :)
In reply to but slur thinkness is not by Jojo-Schmitz
Placed in the wrong part of the thread.
In reply to but slur thinkness is not by Jojo-Schmitz
Can't seem to place this properly, sorry.
In reply to FWIW, MuseScore uses Qt as by Marc Sabatella
Looking at https://raw.githubusercontent.com/musescore/MuseScore/d9bf96ba9a53d8552… shows that quite a few Emmentaler note head types don't go along well with their stems, some too short, some too long.
Entered #33931: Some Emmentaler note heads don't mix and match their stems for this
In reply to FWIW, MuseScore uses Qt as by Marc Sabatella
Hey Marc!
First, again, let me say that I hope this first post of mins doesn't come off as unappreciative. I am bowled over by MuseScore 2.0 and that it is open-source is just incredible. Thank you, thank you, thank you! I will be using it for everything, I'm already convinced!
RE: OTF and Qt... okay, gotcha. So the back-end is Qt, but I wonder how we make changes on the front-end. For example, take a look at my 2nd screen-grab in the OP. I would simple like to have that text kerned a little bit tighter, but I don't see anywhere on the MuseScore GUI to do that. In InDesign (or whatever), you would just select that text and adjust the kerning to be tighter or looser (sort of like "More Stretch"/"Less Stretch").
RE: dragging tuplets... yeah, it's very intuitive that way. But for a score with hundreds of tuplets, you could imagine how this is a bug which is quite significant.
In reply to Hey Marc! First, again, let by douglas81
It didn't come off as unappreciative at all.
After all the main reason for releasing a Beta is to ask for criticism
In reply to Hey Marc! First, again, let by douglas81
MuseScore doesn't provide any user-level control over kerning, and as it is a notation program not a general-purpose page layout program, it's unlikely to get such controls any time soon. If your needs really go that far, you can create the text elsewhere and import it as a graphic, I guess. But I am assuming if the issue that prevents FreeSerif from kerning on MacOS (is that your font and OS?) is fixed, that you won't feel the need for finer control. FreeSerif *does* have appropriate kerning info in it, and it works for me on Windows and Linux, but apparently there are different formats of kerning tables that are used on MacOS, and we'd need to ship a special version of FreeSerif for that to work. Meanwhile, if you don't wish to switch fonts, you could find a version of FreeSerif built for Mac and install it yourself - MuseScore will use it in preference to the built-in version.
In reply to MuseScore doesn't provide any by Marc Sabatella
I'm on Windows 7 (64bit), so it's not a MacOS thing.
Yeah, I thought about just dragging SVG files to a custom palette (already tested that out with my own string number circles... very nice, very easy), but I lose the ability to combine that with the extendable lines.
The font I'm using is a very highly regarded OTF from a respeted foundry, so I'm confident the kerning is well implemented. Actually, I should say... my name in the usual "Composer" field displays perfectly, kerned correctly. It's only in the "Footer" as entered in file info that it looks weird (too tightly kerned).
In reply to I'm on Windows 7 (64bit), so by douglas81
Issue: Tuplets don't align along beam filed.
In reply to I'm on Windows 7 (64bit), so by douglas81
Hmm, which font are you using for the footer? And if it's the default (FreeSerif), do you have that font actually installed on your system so MuseScore is using that version in preference to the version it has compiled in? If so, what happens if you remove it?
Could you attach the score showing the kerning issue? Again, when I type your name in the copyright field of a score using the default font, it kerns just fine for me on both Linux and Windows. Does the effect you see maintain at different screen resolutions? In PDF's or prints? Maybe it's just an onscreen font scaling artifact.
In reply to Hmm, which font are you using by Marc Sabatella
I was trying to add the OPs other question to the issue's list. I was soon told that it had already been done, and I saw that it was done much more elegantly than my attempt.
Thanks Marc.
:)
In reply to Hmm, which font are you using by Marc Sabatella
It happens on all fonts to a greater or lesser extent.
I may have discovered when the problem happens, but not why.
Basically, it happens on every type of text, but only at certain sizes. For example, 9 is really bad. But then, if it's proportional to the spacium, 9 might not be so bad, but another size might.
Example...
Notice how the kerning varies as we change font size. Focusing on the "stavel" word there, it's particularly noticeable between the a and v. See how, for example, at font size 17, it's pretty good. At font size 15 is poor. Notice at 14 how close the s is to the t. At 11, we have what looks like "sta" crunched together and the vel as a separate word. And this is not just on screen, this is when I print out also.
Basically the kerning varies. It seems to me like something (Qt?) is, rather than reading kerning from the font dile, is doing it's own really bad optical kerning.
I've attached the file.
Anyone else noticing this too? A reminder, I'm on Win 7 Home (64bit).
In reply to It happens on all fonts to a by douglas81
A little P.S. I should add, it's not just on that word "stavel" ;) Look also at the distance between the first pair K and v. I mean, at 9 it's almost like there's a space inbetween. Then at 10 it's almost too close, then at 11 it's a bit too far. Similarly look at the A-T... it varies back and forth.
In reply to It happens on all fonts to a by douglas81
I'm no font expert, but I know Qt *does* use the kerning info in the font itself. Apparently the scaling algorithm doesn't handling kerning so well. Would be worth a bug report with the Qt folks.
In reply to I'm no font expert, but I by Marc Sabatella
Oh wow. Is it happening on your setup too? I hoped maybe it was just a problem with Widows 7, or something.
EDIT: and when I say it happens on every type of text, I mean - dynamics, composer, title, expressions, instrument names... everything.
In reply to Oh wow. Is it happening on by douglas81
Yeah, Googling around and I see all sorts of issues with Qt and kerning. Oh no, this could be a real deal-breaker for me.
Given that this problem is happening with all text, it causes layout problems for a lot of things... guitar fingering will not always be in the centre of the circle (I've already experienced that), tuplet numbers might not be in the right place (depending on the scaling of the score), fingerings won't be properly aligned, the list is endless and it's a huge problem.
If this is something we have to wait for Qt to fix, then—for me—MuseScore isn't typographically ready for the prime-time yet. Which is a shame. And there I was getting pretty excited about this release. Ho hum.