Issues And suggestions- New (3.6) Jazz Font

• Jan 15, 2021 - 22:48

First I want to say, that I ike the new Jazz font there are just a few things I want to say

1) The dynamic symbols look wierd and are very small in the new Jazz Font (new on the left old on the right) Dynamics.png

2) the stems now all have sharp edges ar whatever you call that. In the old font they were rounded off, which looked nicer. Screenshot (13).png

3) The Jazz text font looks the same?

4) Suggestion: Chord extension should be displayed verically rather than horizonally - this would save space if you have muldiple extions like a A7(#5/b9/#9) chord.
This Screenshot (9).png
Insted of this Screenshot (11).png

Comments

• Jan 16, 2021 - 00:04

The sharp edges were discussed some and I do believe that is a deliberate change reflecting modern practice. However, it should probably have been considered that handwritten fonts should probably obey different rules here. Stems aren't font characters but are drawn as lines, perhaps there should be a style setting that controls this.

For text, see "Petaluma script" - that seems to be a full text font?

For dynamics, I don't know enough about these things to say for sure, but my guess is you these glyphs are too small in Petaluma Text, which indeed is not ours and so would need to be reported to Steinberg. Or maybe there is something else going on I don't know about. Meanwhile, I think you need to make dynamics 20pt text get the right result.

Stacking extensions in chord symbols isn't really anything about the font but about how we render the chord symbols, which is done with the aid of some XML files you can customize. Do a search of these forums and you'll find a number of people, including myself, who have made some attempts at cobbling together versions that stack extensions.

Reply

• Feb 7, 2021 - 18:19

These are very different fonts. Petaluma Text is not meant as an regular text font, it's more a special version of Petaluma (so, still focusing on the the music characters, not alphanumeric) in which the characters are sized and aligned in such a way that they can be intermingled with ordinary text. This is the basic distinction common to all standard SMuFL fonts - one version meant to be sized and aligned for placed on a staff, the other meant to be sized and aligned for use within text, but neither containing any actually letters or numbers. Except the special numbers used in time signatures or the special letters used in dynamics.

So, no, Petaluma Text is nothing like MuseJazz Text, they have their own symbols entirely - their own clefs, their own accidentals, etc. But MuseJazz Text predates SMuFL and does therefore contain letters and numbers etc, whereas Petaluma Text does not containing these. Instead, there is Petaluma Script for the letters and numbers. You can think of MuseJazz Text as the equivalent of a combination of Petaluma Text and Petaluma Script.

If it was seeming like Petaluma Text was the same as MuseJazz Text, prob ably it was because you weren't looking at the actual music symbols but only the letters and numbers, which don't exist in Petaluma Text at all, and therefore MuseJazz Text was being used instead. This would be the case if, for instance, you were using the "Jazz" chord symbol style, which is hard-coded to always use MuseJazz Text, because again, this was developed pre-SMuFL so there were no standards for this sort of thing.

Reply

• Feb 7, 2021 - 22:54

Well, it is useful for things like including notes and other symbols within text. And the other SMuFL text fonts are provided - MScore Text, Bravura Text, etc. So I wouldn't leave Petaluma Text out. On the other hand, I'm not really sure offering any of these in the Inspector or text toolbar is all that useful given we also have the Special Characters palette. I'm not inclined to take them out unless it is seen to cause an actual problem though - somewhere in the world someone probably relies on these.

Reply

• Feb 2, 2021 - 02:34

In addition to this, some symbols from Petaluma aren't there:
-Slash noteheads
-Measure repeat
-Chord symbol triangle (for major)
-Chord symbol circle (for diminished)

Also, the default size for 8va line text is awfully tiny.

see images here for comparison https://imgur.com/a/BrOIuAm

Reply

• Feb 2, 2021 - 04:30

If MuseScore is going to include Petaluma Script, it makes sense that one would use it for chord symbols along with Petaluma. Can MuseScore provide an out-of-the-box Chord Symbol Style XML implementation (like chords_jazz.xml) that properly maps the different tokens to the proper Unicode values in Petaluma Script and with some default out-of-the-box calculations for superscript and subscript to support chord extensions?

chords_jazz.xml is hard-wired to work only with MuseJazz Text. It looks like the only work that needs to be done is to include a Petaluma Script version of chords_jazz.xml.

I don't understand why Petaluma Script would even be included without this.

Reply

• Feb 2, 2021 - 05:15

Again, it's not our font, so I can't say how the designers of this font intended for it to be used. I can see there are some of the symbols one might want, although I don't offhand see a triangle. But yes, at some point it should be possible to build such an XML file - maybe one of the users of this font would like to try their hand at it for inclusion in some future version of MuseScore!

As for why include it, it's part of the overall Petaluma package that users requested. The musical font itself is SMuFL-compatible so it's pretty much plug-and-play compatible. But any special non-standard chord symbol features would need to be developed separately, and so far no one has volunteered to take that on.

Reply

• Feb 27, 2021 - 13:43

As MuseScore does have rounded Stems, it might be that the Flag-Symbol has a straight stem. But to me it look like the Flags start really low on the stem. Looks a bit funny.
Anyway, there’s is not real purpose to these so called ”Jazzfonts“. Just at some point someone thought: We have all these handwritten Leadsheets, let’s try to make our printed music look the same. But these things are usually not very readable. They are more or less the notational equivalent to Comic Sans :).

Stacking extensions vertically should definitely be an option, as it is not umcommonly done this way. Maybe have extensions separated by a certain character stack vertically? Like maybe #5_b9_#9 to have them stacked or something?

Reply

• Feb 27, 2021 - 23:13

I too am somewhat ambivalent about "handwritten" font styles. But, it's definitely not just an affectation, and it does have very real implications for readability.

First, there is the matter of reader expectation, what seems familiar and comfortable, and this is not something to be ignored lightly. If it were, after all, we could easily say a whole lot of rules/conventions of notation are worth following either - why bother placing stems on the left form downstem notes, or making diagonals go up and to the right where there are collisions between seconds, etc.

But more importantly, there are certain characteristics of handwritten fonts that do make them easier to read in the kind of situations where they are often used - music that is fairly loosely spaced (limited to four bars per system) and being sight-read in dimly-lit bars where one has perhaps had a drink or two already. The wat handwritten fonts tend to be weighted in stroke widths, the proportions of horizontal to vertical space occupied, etc - these things do make a difference. One doesn't specific need it to have a "handwritten" look to achieve any of this, but then, see above - it is kind of expected in this world.

Regarding stacked extensions - I did a trial implementation of an XML file that would do as you say, provide manual stacking through use of particular syntax. I think I used square brackets for this? Anyhow, if you are interested, it could be worth a search of the site. But it's definitely the sort of thing we'd like to support more directly in the future.

Reply

• Feb 28, 2021 - 19:16

That sounds convincing, but to my eyes the ”Jazz“-Font that comes bundled with MuseScore are significantly harder to read compared to traditional notation. The idea of a heavy, easy readable notation font is not bad, but these fonts somehow tend to be cluttered, have lots of weird designs. I mean, look at the # in MuseJazz. It looks pretty much like a quarter-sharp if you do not look very carfully.

The only occasions where I find this style easier to read are Chord Symbols, because they have a certain combination of weight and openness that makes them easy to discern (many heavy fonts are designed either for small text bodies or for large Design texts, both does not really fit that need).

Of course that misses the necessary drinks, maybe that changes the whole thing.

Reply

• Mar 1, 2021 - 07:44

Could if they’d actually work. The current AppImage has some linking problems for me, being unable to lookup some c++11 stuff. I do not see much advantage in taking all that effort for having a slightly newer MuseScore. Not anymore, after considering how the previous releases broke the old font. In a few months we’ll have Bullseye, and then the freeze will be over.

Reply

• Mar 1, 2021 - 17:14

Indeed, AppImage works fine on Debian in general. Could be your particular distribution is unusually old, or you have customized something about it. Absolutely work the effort of figuring out what the issue is, probably over a thousand bugs fixed since 3.2.3 and some significant new features added as well that enhance the composition workflow. Which Debian version, and what is the specific error you see when running the current AppImage?

Reply

• Mar 2, 2021 - 21:05

I’m on debian sid, so it shouldn’t be that old. I’m getting the error
/tmp/.mount_MuseScIdQY7V/bin/mscore-portable: symbol lookup error: /tmp/.mount_MuseScIdQY7V/bin/mscore-portable: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev, version Qt_5

The symbol in question should be std::__cxx11::basic_string, std::allocator >::~basic_string() I think. So it appears to be a weird dynamic linking error to glibcxx.

Reply

• Mar 2, 2021 - 23:22

Isn't "sid" the term for the "unstable" release? Quoting from the page on the debian site:

"sid is subject to massive changes and in-place library updates. This can result in a very unstable system which contains packages that cannot be installed due to missing libraries, dependencies that cannot be fulfilled etc. Use it at your own risk!"

To me that sounds like the problem right there. Any reason not to switch to an actual supported release?

Reply

• Mar 1, 2021 - 17:17

Terms like "easy" and "hard" are completely subjective, but just keep in mind, there are reasons that millions of jazz musicians prefer these sorts of fonts. Just because it isn't easier for you -0someone more accustomed to the look of old-style hand-engraved fonts which have entirely different aesthetics that exist for entirely different reasons - doesn't mean they aren't more readable to people accustomed to a different aesthetic. There's a reason multiple options are provided, because different fonts serve the very real needs of different musicians.

Reply

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