MuseJazz, a new handwritten music font in MuseScore 3?

• Oct 12, 2016 - 16:50

I just merged a first prototype that adds an handwritten, jazz inspired, musical font to MuseScore 3 !

In MuseScore 2, we included MuseJazz, a font used only for text, chordnames etc... Along the years, many users requested a handwritten look for their score. We will try to answer this request in MuseScore 3.

In master, the existing MuseJazz font is now MuseJazz Text and a new SMuFL compatible musical text font is added and called MuseJazz. This font has been created by Abraham Lee from Music Type Foundry.

To change the musical font, you can go to Style > General > Musical Font. You will notice a new checkbox, currently labeled "use style settings for the font". If checked, MuseScore will change some style settings in a manner complementary to the design of the font. Please try a nightly build, and let us know what you think of the new font!

The first measures of Reunion featuring MuseJazz and MuseJazz Text
reunion.png

Here is a animation made with MuseScore of the 4 available fonts.

fontstyle.gif

Comments

• Oct 12, 2016 - 18:15

From what I've seen so far, I do like this. It's more subtle than similar fonts that I find distracting to the eye. I look forward to trying it out with more of my own scores!

Reply

• Oct 13, 2016 - 13:33

@all feel free to share some examples of your scores with the default MuseScore font and with MuseJazz. We want to use the best example for an update on the MuseScore social media pages.

Reply

• Oct 14, 2016 - 20:54

As far as I know, brackets are not drawn using characters from a font - they need to be resizable in a way you can't really do using fonts.

As for dynamics, I have mixed feelings on that. Yes, in theory those characters could be added to a handwritten font, but subjectively I prefer seeing them in the traditional type of font. Which is to say, I definitely wouldn't want to just use the m, p, and f from MuseJazz Text - it would need to be something specially designed to still look like dynamics.

Reply

• Oct 14, 2016 - 20:55

As far as I know, brackets are not drawn using characters from a font - they need to be resizable in a way you can't really do using fonts.

As for dynamics, I have mixed feelings on that. Yes, in theory those characters could be added to a handwritten font, but subjectively I prefer seeing them in the traditional type of font. Which is to say, I definitely wouldn't want to just use the m, p, and f from MuseJazz Text - it would need to be something specially designed to still look like dynamics.

Reply

• Oct 15, 2016 - 16:05

Regarding Dynamics, MuseScore uses the one from the Text Font and not the one from the musical font. We can see the one from MuseJazz in the Z palette though. Go to Symbols > Dynamics and change the font to MuseJazz. I believe it would be good to have these in MuseJazz Text. They are indeed different than the classic dynamics but distinctive enough to not be mistaken.

Regarding the grand staff brace, MuseScore currently draws it using a complex path extracted from Lilypond I believe. SMuFL advises to have several glyphs in the font and use a scaled version of them https://w3c.github.io/smufl/gitbook/tables/staff-brackets-and-dividers…. We might want to take a look into that to provide a better looking brace for Bravura, MuseJazz and Gonville.

Reply

• Oct 15, 2016 - 18:21

Makes sense. So it's just a matter of copying glyphs from MuseJazz to MuseJazz Text? I wonder if we should do the same for any other glyphs? I had create a few for MuseJazz Text that are nothing particularly special and the new MuseJazz glyphs are probably better choices, although I guess any change is bound to cause someone to complain. For instance, the coda and segno.

Reply

• Oct 13, 2016 - 19:38

Hurray! Thanks to all and especially Abraham Lee!

Notes on the post: The GIF seems to show only three fonts, and in the nightly builds it's Format > General Style.

Suggestions for improvements: the "use style default settings for the font" functionality may be better as an option to load various default styles, including ones with different fonts. At any rate, MuseJazz should go along with changing chord symbols to the jazz style (though I think this may have temporarily broken jazz chord symbols).

Reply

• Oct 14, 2016 - 03:44

Indeed, jazz chord symbols seem broken. I believe that's because chords_jazz.xml is hardwired to use MuseJazz but it needs to be updated to "MuseJazz Text". I'll make a PR.

Question: how finalized are the style settings for this font? Some I quite like, others I think go too far. Barlines probably don't need to be quite so thick (but if they are, double bars need to be adjusted too). Slurs & ties also I think are too thick. But these are nitpicks, overall I am very happy to see this.

Reply

• Oct 14, 2016 - 20:13

Quite set in stone, I'm afraid (just kidding). I agree about some parts going too far and I'm assessing what would be better, so please feel free to offer suggestions. One thing I would change is the tip thickness of the slurs (increase it to be about the same thickness of stems). I'd also decrease the thickness of the barlines and mid-thickness of the slurs.

@lasconic, in the images shown, are those the settings brought in through the metadata file?

Reply

• Oct 14, 2016 - 21:02

I think we are on the same page then. Slurs should be thicker than in other fonts, but not *as* thick as they are here (same with ties). Same with barlines. I'll have to play with this some more to see if there are other changes to style settings I'd suggest, but that's what jumps out at me on the first couple of scores I tried it with.

One thing that I guess is part of the font design itself: the half note head seems subjectively a bit small. It's ever so slightly larger than a quarter note - I guess to about the same extent as in other fonts - but given the thickness of the line, the "hole" in the middle doesn't seem quite as open as I might expect.

Reply

• Oct 14, 2016 - 23:21

Thanks for the feedback, Marc! These are some great observations. The best part of all this is that I'm completely impartial to the design.

You know what, though, you've made me curious. Indulge me for a moment. If YOU (or anyone else following this thread) wrote out your now famous "Reunion" score by hand, as a professional copyist might, what would it look like? Follow the same 1-page layout, same number of bars per system--basically replicate the notated page. Surprise me! (who knows... maybe there'll be a "Sabatella" music font someday...)

You can send it to me privately if you'd like.

Reply

• Oct 15, 2016 - 01:52

Hmm. One of the reasons I started using notation software so many years ago (like, like 1980's) is that I don't think I have particularly good penmanship. And whatever skills I might have had back years ago, I haven't practiced at all since - I rely on notation software almost exclusively for everything once I get past the initial sketches of a musical idea. So I don't think there would be anything useful to learn from looking at my chicken scratch :-)

I do think I have a pretty good sense of what works when it comes to music fonts for jazz, though. I've expressed the idea before that I think handwritten fonts tend to be a bit of an affectation, but I do see a very real potential value in certain aspects of them. The generally heavier weights of the strokes in most "jazz" fonts helps with legibility when sight reading in relatively dark jazz clubs, etc. And we usually do better with a wider spacing than otherwise, although that's more a software thing than a font thing. For chord symbols specifically, we usually like capital and lower case to be clearly differentiated, with relatively heavy strokes but a fairly narrow character width so that long chord symbols like "Cma7#11" can be parsed at a glance but not take a ton of room on the page.

I think that, overall, the MuseJazz / MuseJazz Text combo does pretty well on these counts. But frankly, I'd be as interested in a "regular" (not "handwritten") font that had these same design considerations.

Reply

• Oct 17, 2016 - 16:21

To answer my own question about how people actually write the quarter and half noteheads, I perused a handful of specimens I have and I can definitely see a much greater difference in size between the two. In some cases, the half-notehead is so much larger that the counter (i.e., the "hole") is almost as large as the entire quarter note. The half-note is often much larger when it is on a staff-line (sometimes touching the next staff line above and below) than when it's in a staff-space. Naturally, there's a wide range of sizes since they're hand-written. I'll play around with the half-notehead to see if I can get an acceptable larger size, or at least find a way to increase the internal whitespace. I think I'll need to do the same with the circled-X noteheads.

On the other hand, we could go the other direction and make the quarter-notehead a little smaller? This is not uncommon in hand-written scores. Just a thought.

Reply

• Oct 17, 2016 - 17:24

It's not uncommon to have smaller noteheads in handwritten scores, i agree, but I think that's mostly a matter of laziness than preference. I always think of the main goal of a jazz font being, making it easy to sightreading especially in dark environments. I don't think small noteheads help with this. But bigger "holes" in the half notes do help in making them more distinct from quarter notes.

In theory, we should handle spacing correctly no matter the size of the notehead, as long as the nominal note head size is set correctly (I think it's read from the font?). It will be interesting to see if increasing the size of the half note head causes any problems; hopefully not.

Reply

• Oct 15, 2016 - 16:31

Just committed an update for the font with different engraving defaults (and a couple more glyphs) 6895cabab9

* beamThickness = 0.4 (was 0.48)
* dashedBarlineThickness = 0.3 (was 0.4)
* slurEndpointThickness = 0.12 (was 0.8)
* slurMidpointThickness = 0.2 (was .38)
* tieEndpointThickness = 0.12 (was 0.2)
* tieMidpointThickness = 0.2 (was 0.32)

Reply

• Oct 15, 2016 - 23:58

Much better on the points I raised, thanks! I'm not so sure I agree about the beam thickness, but worth discussing. I recall seeing someone ask about that, but I can't find that now.

EDIT: it was one Facebook, and they were asking for *thicker* beams, not thinner. Personally I thought they were fine as they were. But now that I try out these settings on more scores, I'd say maybe you went a bit too far with thinning out the slurs & ties. I'd go with 0.25 for the line thickness at middle (I have no real strong feelings on the end point thickness).

Reply

• Oct 25, 2016 - 00:21

So, I'm in the process of creating the new MuseJazzText font and merging the old text font by the same name into it for a comprehensive music text font. Most glyphs should transfer painlessly. However, I've noticed that some of the music/chord glyphs in the current MuseJazzText font are set at codepoints that are set aside for other glyphs in SMuFL:

custom-musejazztext-glyphs.png

The glyphs in highlighted in YELLOW are not in SMuFL at all. The glyphs highlighted in CYAN are in SMuFL, but are at the wrong codepoint (which I can correct).

I can place the yellow ones at any other codepoint, if there are no objections. I assume some other chord definitions file will need to be updated with the new codepoints if that's what we do.

SMuFL doesn't support chord "words" like "maj", etc., just some of the basic chord symbols.

What think ye?

And what's the difference between the glyphs at E187 and E18E? They both look like the "diminished" symbol, but E187 is like a super-script version.

@Werner (or whoever else knows about it): What would it take to use the grand staff braces "{" that are embedded these SMuFL fonts? Would sure be great to have them available and then fall back to the current one if the current font didn't have them.

Reply

• Oct 25, 2016 - 19:23

I will need to get back to you a bit later about the codepoint issues, when I have time to look in more detail. But what I remember is that the original version of the font was hard-coded to have *only* superscripted versions of many glyphs - including numbers and the degree sign used for diminished chords. I guess the idea was so even a "dumb" program could create decent looking chord symbols just by assembling the glyphs in the right order, no fancy sizing or positioning needed. But this made the font useless for ordinary text, and also more limited than I would have preferred even for chord symbols. So some glyphs were duplicated with adjustments needed to make them more suitable for ordinary text for using as a basis for further adjustment within our code. Also, some were duplicated to provide the proper Unicode codepoints.

Ideally we'd keep all the old glyphs where they are - perhaps just as references (or is that just a FontForge thing?) so a change to one version automatically updates the others. We will indeed need to make sure we have a compatibility plan for existing scores. Also, any change to the "true" codepoints for these glyphs will need a corresponding change in chords_jazz.xml to make sure scores use them.

Reply

• Oct 25, 2016 - 20:00

Thanks for that explanation, Marc. I assumed that was the case, but just wanted to be sure.

At this point, I'm seeing two things that I feel need to be discussed:

  1. The design of the current MuseJazz text font is much more blobby/inky than the design of the new MuseJazz music font. So, I'm starting to wonder if merging them is the right choice. Perhaps it should just be renamed (e.g., MuseJazz-Book) and stay separate?
  2. If merging the two is still desired, I see two logical approaches:
    1. Create the music text font and then copy over the current MuseJazz glyphs into their same code points, replacing the music text font glyph (if one is there). This makes compatibility a non-issue, but with the potential of losing some glyphs from the music font.
    2. Create the music text font and add the MuseJazz glyphs, but offset the code points in the case that a glyph is already present from the music text font. This makes ALL glyphs available, but requires updating other files/code to ensure compatibility.

Thoughts? Other ideas?

Reply

• Oct 25, 2016 - 20:55

If we don't merge them, what do you propose? Creating a new text font?

As for how to best do the merge, I think for me we'd need to decide case by case which glyphs to use. We could start by assuming newer = better, but maybe there are cases where the old does happen to please more people. The tricky part is getting unbiased opinion - many of us will naturally tend to prefer what we are accustomed to.

Reply

• Oct 25, 2016 - 23:32

If not merge, then keep the old font as it is, just with a new name. Nothing else would need to change.

For now, I've gone ahead and sent Nicolas the first beta release of the complete MuseJazz font family, which includes a first pass at MuseJazzText.

I decided to just import the old MuseJazz glyphs directly to their current code points, replacing any glyph that may have been present already from the conversion from MuseJazz->MuseJazzText. You are welcome to go through and tell me which glyphs should be there and which ones shouldn't (or any other changes that are needed).

I assume Nicolas will post a link to the Github PR so we can assess the latest changes.

Reply

• Oct 26, 2016 - 20:49

I'll check it out when I have time, hopefully in next couple of days. But my first guess is that it has to do with the scaling of the glyphs themselves. As I recall, some fonts are set to 1000 "dots" per em, others to 2048 or some other value. If a glyph that was designed for 2048 dots per em is inserted into a font that expects 1000, then I assume it would be rendered too big, which appears to be what is happening.

Reply

• Nov 3, 2016 - 16:07

So, what are the in-app font sizes for the music and the [chord] text? This could be part of the problem. I tried to make the text font glyphs an appropriate size to the music glyphs in MuseJazzText.

Another test you can do is take a look to see if the music glyphs in the text font show up the same size as the real music glyphs. In other words, insert a G-clef into the text and see if the size is different than a G-clef in the music itself. They should be the exact same size, otherwise all we're probably seeing is a font setting discrepancy. I can account for that in MuseJazzText, I just need to know what the correct ratio is (e.g., 20pt staff/28pt text).

Reply

• Nov 14, 2016 - 18:16

Kerning is still kind of a mystery to me. The actual mechanics of it, not so much, and the kerning info *is* there in the font, but it seems almost random as to whether it will be honored when you go to save the font after editing it. There are different magic combinations of the various options that work with different OS's and different versions of Qt. I spent a while trying to sort it all out at one point, then it seemed everything was different when I came back to it a year later.

Reply

• Dec 2, 2016 - 23:29

Without going into technical details, I'll just say, unfortunately it's not that well-implemented of a font. The old text characters, I mean - the new stuff is great. But the way the letters from the old MuseJazz are defined, it's glitchy as it resizes, and is particularly poor at smaller sizes.

That's the main reason I was saying a while back I'd love to see a better handwritten text font. But it would have to be actually designed for readabilty and to work well in chord symbols. This particular font *is* well designed from that perspective, being based on the handwriting used in some well-respected jazz publications. So actually, maybe just a better implementation of that same design. But I lack the skills myself.

Reply

• Dec 3, 2016 - 02:40

I can't speak for Werner, but I've been the one dealing with this font mostly for the past several years, and I know *I* would certainly appreciate any help you can offer!

My sense is, most of the glyphs are just over-specified - too many control points, not enough taking advantage of the natural splines. Maybe I'm wrong about that. There were some obvious errors in a few of the glyphs that was able to correct long ago - places where there were a whole slew of control points practically on top of each, places where the curve appeared to reverse itself, etc. But a lot of them are still pretty ugly.

Reply

• Nov 3, 2018 - 01:27

Hmm, if the new MuseJazz Text font is, in parts, a derivative of the old MuseJazz font, why does it not carry Werner’s 2009 copyright in addition to your new one, as required by the OFL?

(I’m assuming that reusing the same Reserved Font Name for the old and the two new fonts is deliberate and agreed upon, otherwise there’s another issue there.)

Reply

• Nov 6, 2016 - 23:17

This is so great! I really love the new font!
Is there a chance that MuseJazz Text will be available in an upcoming 2.0.x release?
Or do i've to wait until 3.0 is stable?
I think at the moment it is not a good idea to start working with the nightly build. But now that i know this great font and played around with it... i want to see this style in my sheets as fast as possible ;)
Thank's for the great work so far!

Reply

• Nov 6, 2016 - 23:32

You are wise to not rely too much on the nightly builds yet.

But you might consider creating your score with 2.0.3, then just before printing, make a copy of it to load into a nightly build. You can then switch to the new font, see if anything else needs adjusting, and print it. As long as you don't overwrite the original 2.0.3 version this should be safe.

Reply

• Nov 6, 2016 - 23:39

This is very unlikely to appear in a version earlier than 3.0. One of the guidelines for adding things to the 2.0.4 branch (which may be released as 2.0.4 or 2.1) is to try to maintain file compatibility with all 2.0 updates—that is, with very few exceptions, you should be able to work on the same file while switching back and forth between 2.0.1 and 2.0.3 (for example). But no existing version of MuseScore would be capable of loading a file using this font, because it simply wasn't a part of the software.

Reply

• Nov 29, 2016 - 17:52

here is a short list of glyphs we could add and my thoughts. Any input?

Reply

• Nov 29, 2016 - 18:45

Metronome marks - here the old Musejazz already had most of these, so I'm not really noticing an issue with their not being additional new ones, or am I missing something?

Beamed groups do sound useful for that swing marking. The irony is, that marking isn't really used by the jazz musicians who would be the biggest users of this font - the word "swing" is already well understood in the jazz without the need for the graphic (which is inaccurate anyhow). It's more for non-jazz musicians that the swing marking is used. But sure, there is probably non-zero intersection where some folks who want the jazz font would also want the swing marking.

Individual notes - not clear what these would be used for, just applying via the Symbols palette?

Noteheads - the more the better, no doubt. Jazz probably uses more alternate notehead styles on a regular basis than any other form of music except maybe 20th/21st century classical percussion music. Although even so, it's probably a relatively small set in common enough usage that people would notice.

The brass techniques glyphs would be nice indeed - many people prefer these stylized versions over the simple primitives we draw. Although simply drawing the primitives with thicker lines would go a long ways toward looking handwritten. That was actually the one thing I did notice but neglected to mention.

Reply

• Dec 23, 2016 - 00:34

I really like this font!!!

I have quite a few arangements that I would like to print using this font by loading them into a nightly build, loading a style change, and then saving to PDF for printing. I notice that in the nightly build I can not switch the stem direction using the X key. I can do it in the Inspector, but that can be laborious at best.

Is there something that I am missing in the nightly build about the way to switch stem direction?

Reply

• Dec 23, 2016 - 01:56

Apparently there is a bug in currently nightlies involving beamed notes where X doesn't work. But I wouldn't be trying to edit music in a nightly just to print it - do that in a stable built, then load into a nightly to try to print (but expect things to maybe not go too well, because they are *not* stable builds).

Reply

• Jan 14, 2017 - 19:07

Great font, great development for MuseScore!
Unfortunately the font used for the font symbols does not really match the Jazz music font.
Attached find a font I have been tinkering with for the last few years - its glyphs are taken from the same font as used in the music font and adjusted to work like the (still) standard Jazz Chord font. Feel free to do with it whatever you want... ideally you will include it in version 3 ;-)
And here a little screenie to illustrate what it looks like:
screenie.png
And here the font (please change file the extension back to ttf - would not upload as a font file...)
MuseJazz.txt

Reply

• Jan 14, 2017 - 21:59

Your example looks good, but I'm not sure what it is demonstrating. Are you saying you have designed your own version of the font used for the *text* - eg, the title "Just Friends" - that is not based on the copyrighted "Jazz" font from Sigler and could thus be distributed for free with MuseScore?

Or are you saying that picture is actually using the copyrighted Jazz font for the text, but you have designed your own font for the clefs, notes, accidentals, and other music symbols, and you have made it SMuFL compliant and compiled your own custom version of MuseScore to use your font?

It's also not clear how you did the chord symbols - did you create a custom XML file so that MuseScore's own chord parsing scheme can use your custom font?

Reply

• Jan 15, 2017 - 13:13

Your example looks good, but I'm not sure what it is demonstrating.

Sorry, obviously I did not express myself properly. I will try to clarify:

The font attached is a font that in my sample was used as a replacement font of the current MuseJazz font. It contains all the symbols/glyphs used in the original MuseJazz font, so that it can be used with the built in jazz chord style sheet (chords_jazz.xml) and displays the chords the way they are defined there without any further customization.
And the glyphs are taken from LilyJazz, thus could be distributed for free with MuseScore.
Hope this clarifies the matter ;-)

PS: The screen shot was taken using MuseScore 2.0.1, which allows me to replace the original fonts with my own (OS X) - hence the screen shot uses my own customised music notation font (this one is taken from a copyrighted font, whereas MuseScore's new font is based on LilyJazz) in combination with the chord symbol font attached in my previous post, based on LilyJazz (as a replacement for the built in MuseJazz font.)
Unfortunately, newer versions of MuseScore don't allow me to do that anymore; I take it that some code has been changed - would be nice if that could be done again...

To clarify further, as pictures speak louder than words:
This is what the score looks like with the current standard MuseJazz font:
Just_Friends-Real_Book-standard-1.png
And this is what it looks like with my modified version of the MuseJazz font:
Just_Friends-Real_Book-1.png
Hope this helps ;-)

Reply

• Jan 15, 2017 - 22:42

That helps somewhat, but it's still a little unclear. As far as I know you can't use chords_jazz.xml with any other font unless you modify the XML file - it is hardcoded to use MuseJazz for most glyphs regardless of the chord symbol text style or the musical text font or any other setting. Also, it isn't totally clear what you mean about "all the symbols/glyphs used in the original MuseJazz font" - do you literally mean all of them, including the special combined glyphs for
"ma", "mi", "sus" et al, the pre-superscripted numbers, etc?

I'm also not clear on what you mean about changes in font handling in "the newer version" compared to 2.0.1 - I'm not aware of any relevant changes between 2.0.1 and 2.0.3.1. Unless by "newer version" you mean the experimental nightly builds of what will, at some point in the future, eventually become 3.0. That's still a work in progress. But if you mean 2.0.3.1, could you be more specific about what has changed for you? I'm still not clear on what you mean about replacing fonts.

Reply

• Jan 16, 2017 - 07:02

Yes, I "literally mean all of them, including the special combined glyphs for
"ma", "mi", "sus" et al, the pre-superscripted numbers, etc"!
I started off by replacing every single glyph with the equivalent of the new font - a rather tedious job in Fontforge, I can assure you... Hence we can use the existing chords_xml files with this font, too. Have a look at the font file attached to my first post - after downloading, you will have to rename it from MuseJazz.txt to MuseJazz.ttf, you can open it with any font viewer.

In the MacOS version of MuseScore the fonts are located in /Applications/MuseScore 2/Contents/Resources/fonts/. There I usually overwrite the original MuseJazz.ttf font with my customised version - for MuseScore files based on the jazz leadsheet tempate I then get the result illustrated in my last screen shot above.
After further trials it seems that this procedure still works for my MuseJazz.ttf font in version 2.0.3, but no longer for the Gooteville.otf font that I customised as well using glyphs from a non-free font (however, this is no longer relevant as the new jazz music font will be included in version 3).

Reply

• Jan 16, 2017 - 12:50

It could be me, but I still don't get it...
We are talking about the text font only here. Right?
Then you created a text font following the same codepoint layout than the original MuseJazz font (now called MuseJazzText in the development version). Still right?

Now, you created these new font from scratch or you took the glyphs from another font? If you did take them from another font, which one? And what's the license of this font?

Reply

• Jan 16, 2017 - 15:33

i don't know is my guess right or wrong :
possible: from LilyJazzText font to current MuseJazz(Text) font.
.
lilyjazztext.png

from: https://github.com/lyp-packages/lilyjazz/blob/master/LICENSE

"The MIT License (MIT)

Copyright (c) 2016 noteflakes

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."

Reply

• Jan 16, 2017 - 16:26

It could be me, but I still don't get it...
We are talking about the text font only here. Right?
Exactly.
Then you created a text font following the same codepoint layout than the original MuseJazz font (now called MuseJazzText in the development version). Still right?
Yes, by replacing the original glyphs in MuseJazz with my glyphs, c.f. below.
Now, you created these new font from scratch or you took the glyphs from another font? If you did take them from another font, which one? And what's the license of this font?
- I took the glyphs from LilyJAZZ, changed the size of some of them, or made some new glyphs out of them if they were missing.
- As for the license, see here: https://github.com/openlilylib/snippets/commit/005e08a5e943ae4dc6f2956e8b2c094cd1bf22cf
Alternatively, there seems to be another license, c.f. post by Ziya Mete Demircan

Reply

• Jan 16, 2017 - 20:03

OK, this is becoming more clear. I think one reason I was having trouble getting it is, what you did must have been a lot of work, and wasn't expecting that you had actually done all that, especially without additional help on our part! So thank you for that. Hopefully we'll be able to find a way to use this.

I do think it would be good to offer two different text fonts - one with the "Real Book" look you have made happen, one with the "New Real Book" look that MuseScore has used up until now. Each has its advantages and disadvantages, and different people have different preferences here.

I'm not familiar with the details of how private application fonts are handled on MacOS. On other OS's, the fonts MuseScore relies on are simpyl compiled in to the application itself, but I guess Mac does things differently. On others systems, one *can* override the compiled-in font by installing a another version in the usual way for the OS. But this isn't recommended as there is no guarantee they will be compatible versions - code points, metrics, or other details may have changed. So its unlikely we will ever "support" the ability for the user to shoot himself in the foot in the manner. But we don't go out of our way to prevent it, either. Not sure what's up with Gonville, but one possibility is a simple naming conflict - there are at least two different names this font goes by and the file name isn't necessarily the same as the font name. Be sure to get the names correct if you want your version to override MuseScore's.

Reply

• Jan 17, 2017 - 16:40

I am glad this is becoming clear now.
I really like your idea of offering the MuseScore user two different text fonts, so we could have the best of both worlds.
By the way, still trying to solve the problem with Gonville - no luck so far, I even tried to change some glyphs in the included version of Gonville, but they don't show up. Will keep you posted if I make any progress... could have to do with the fact that Gonville is *.otf format, whereas the (still) working MuseJazz font is a *.ttf file...

Reply

• Oct 12, 2018 - 22:04

The licence is SIL Open Font License, Version 1.1 - as it says in the font properties...
If there is a chance of getting it included in a future version of MuseScore, I will happily rename it; just let me know!
PS: As I understand it this thread seems to be about both ;-)

Reply

• Jun 5, 2018 - 21:38

Most likely anyone with the ability to compile from sources could pull it off with a little work. But if you mean, would anyone on the development team be willing to do that and share the results, I'm going to guess the answer is no as a matter of general policy, because it becomes a support nightmare when there are different custom versions of the program floating around out there, especially if scores created with one person's custom version don't load properly in the the standard version (which is what would happen here).

I'm speaking only as someone broadly familiar with the processes, though, not in any official capacity whatsoever.

FWIW, we are working on a 2.3 release that would include a few other changes that are not entirely compatible. I for one would support seeing this font added to 2.3, along with a few other changes that would similarly not be totally backwards compatible but would be easy and I think worthwhile. But the line has to be drawn somewhere, and again, I'm not in charge of that.

Reply

• Jun 6, 2018 - 14:38

Right, but given this is already going to be the case with some of the percussion changes for 2.3, it seems we're already establishing this is OK in principle, it's just a matter of deciding which changes are OK and which are not. If 2.2 was able to load the 2.3 score but fall back to Bravura or whatever, I could live with that.

Reply

• Jun 6, 2018 - 15:48

I really don't understand why there is a backward compatibility between older 2.x versions. It maybe makes sense between 2.0.2 and 2.0 or 2.1.x to 2.1 but between 2.3 to 2.2? really? Why? Not even Sibilius or Finale deals with stuff like that. If you receive a newer file you need to update your software. In the case of MuseScore this doesn't matter because the software is open source and you don't have to buy something new.
Thx allot that you put so much work into those things... but i think backward compatibility is just important for the upcoming versions. f.e. open an 2.0 score in 2.3 or 3.0 without getting trouble. Am I wrong? :)

Reply

• Jun 6, 2018 - 16:37

Some people are willing to upgrade to handle newer files, but not everyone is - some are indeed not able to for various reasons. So we do take backwards compatibility seriously. And so do most other software developers. That is, in msot programs out there, a file created with version 2.3 can be opened in 2.2. The usual convention is that only "major" releases will break this - a 3.0 file won't open in 2.0.

Still, I personally can live with 2.3 files crashing 2.0.2 as long as they do something reasonable in 2.2 or 2.1. Doesn't have to be perfect. That's just my opinion though.

Reply

• Nov 4, 2018 - 10:10

Hi,
Thanks very much! I was looking for this equivalent to Finale's jazzfont, it's a great improvement!
If I may, I would like to suggest some improvements:
1. the double measure bars are more looking at solid bar than double bar (cf. PDF here-attached).
2. same for repeat bars: the thick bar, the thin bar and the double dots are all merged
3. truplets ("3") should be written in jazz font also
5. measure numbering should be writtent in jazz font also
4. some note bars are not close enough to their note, thus leaving a thin disgraceful space between them (cf. first truplet on measure 5 for instance, or notes in measure 9 in PDF here-attached)

Thanks again for the great work devs are making there!

Attachment Size
Killing_in_the_name_v2-Bb.pdf 55.35 KB

Reply

• Nov 4, 2018 - 10:23

Ad 1. and 2.: I don't see that in a score created from scratch, can you attach the score? Note that the current templates in 3.0 Alpha have not yet been adjusted to 3.0, but are unchanged from 2.x.
Ad 3. and 5.: Setting text style for measure numbers and tuplet number to MuseJazz (Text) is possible already (or rather should, setting this in the style settings doesn't seem to stick). The latter seem to be set to that in your PDF.

Reply

• Feb 1, 2023 - 21:51

Is there a way to do that in MuseScore4 too? I haven't been able to make the whole document jazz font, just part names and other text besides the metronome symbol.

Reply

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