A couple of niggles...?

• Sep 21, 2014 - 12:56

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.

tuplet-placement-1.png

2.) The default diamond note-head it pretty unorthodox looking. Is that a bug? The second bar here is using the "mi" noteheads instead.

diamon-notehead.png

3.) Something weird going on with the kerning in the footer...

footer-kerning.png

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 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?

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 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 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 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...

slur-vs-tie2.png

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...

slur-vs-tie3.png

The slurs look great, but the tie is getting a little bit fat and comical looking. :)

Attachment Size
slur-vs-tie2.png 11.01 KB
slur-vs-tie3.png 11.12 KB

In reply to 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 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 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 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 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...

kern-chart.png

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).

Attachment Size
kern-chart.png 93.38 KB
Kerning_Along.mscz 2.09 KB

In reply to 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 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.

Do you still have an unanswered question? Please log in first to post your question.