chords_jazz.xml

• Sep 17, 2020 - 16:21

Hi all. I've created my own font for jazz chord notation, and I've subsequently been playing around with chords_jazz.xml for a couple of days now. I've gotten my font to work with Musescore, but I'm finding the XML file to be pretty inscrutable. I've looked around for some documentation on this, but it seems like the only documentation are the comments in the XML file. Am I missing something? Is there someone who's expert in this who'd be willing to document things? I'd volunteer, but my understanding of the XML file is still pretty minimal. If someone wants to tutor me, I'd be happy to write things up.

Thanks. And thanks to everyone who's made this lovely piece of software! I really appreciate it!

Comments

• Sep 17, 2020 - 20:06

You're not missing anything - the comments in the XML are indeed what there is. Is there a particular question we can help with?

If you're designed your own font, I would recommend using the same codepoints that MuseJazz does - in other words, put the flat, sharps, diminished, half-diminished, and triangle signs in the same place, etc. Then you won't need to alter much.

Reply

• Sep 18, 2020 - 02:26

Thanks Marc. Yup, I pasted my glyphs into the same codepoints in my font, so that's all good.

I don't have any specific questions, I'm just a bit baffled by how exactly the XML file works; and playing around with it (tweaking values) is very slow going and often yields counterintuitive results. It'd be great to have a point by point analysis of how it all works, along with a bunch of examples, all fastidiously explained. If I manage to figure it all out, I'd be happy to put something like that together. But I despair a bit at the moment.

Reply

• Sep 18, 2020 - 17:17

The big picture is best seen by looking at the bottom of the file. Basically, chord symbols are build by assembling a step of "render" instructions for each element - in a chord symbol like Cm7b5, a rule for how to render the root, for how to render the "m", a rule for how to render the "7", a rule for how to render the "b", and a rule for how to render the "5". That's what the top of the file is all about - the rules for each of those components. If your font has built into it all the sizing and subscription you want, the top portion can be essentially empty; it's needed only if you need to say things like "render the 7 at 80% size and superscripted 5 points."

As for examples, every single thing in the file is an example :-). So, if you say you tried something in particular and the results were different from what you expected, first step would be telling us one specific thing you tried, what you were expecting, and what happened instead. Then we can go from there.

Reply

• Sep 18, 2020 - 19:29

I appreciate that there are lots of examples; they're just not explicated. (I realize I'm not owed any explication, by the way!)

So maybe I'll make two posts, instead of one, here. This post will be some questions I have about the XML file; and then I'll post an actual practical question in a second post. If you have time/energy to address either, it'd be much appreciated!

Alrighty... Questions about the XML file:

  1. The documentation says internal chord numbers can be omitted, if you don't need compatibility with older chord description files. I'm assuming that I don't need this, as I'm not explicitly using any other chord description files. But I'm not sure if any such files are invoked implicitly by Musescore. Some clarification would be awesome.

  2. Render commands... What are spatium units?

  3. Render commands... What are :push and :pop used for?

  4. In the ENTITY tag, what are the units being used for ext, mod, and modn?

  5. What does the version # in the museScore tag mean?

  6. What are the units used in the mag tags?

  7. How does renderRoot work? (What are :n and :a in that context? Note and accidental?)

  8. What does renderBase do?

Reply

• Sep 18, 2020 - 19:52

Thanks for the questions, specifics are easier to answer :-)

1) Right, the internal chord numbers are no longer used, haven't been for years actually, but the very first versions of MuseScore relied on them (they were borrowed from Band-in-a-Box, FWIW).
2) A "spatium" is the technical term for the size of a staff space - the distance between adjacent staff lines. This is the unit of measure used throughout MuseScore (you will see it abbreviated "sp" in the Inspector, style dialog, etc) and almost universally in all notation programs. It allows you to specify a size that scales as you change the staff size.
3) push and pop are terms from the programming world, they refer to a "stack" that can be used to store things in a way where the last item you added to the stack is the first to come off. They can be used to "remember" the current position and then return to it, so for instance if you want to stack two items vertically, you push to save the current position, render the first item, pop to restore the saved position, then move down.
4) These and most other units are not exactly specified, and to be honest I don't think I could tell you what they refer to, something kind of like "points" but probably not precisely that, if nothing else because they scale with the spatium value. Frankly, I use trial and error in figuring out what values to use when fiddling with render commands.
5) I don't think that this is actually used, but I sort of think it might refer to the MuseScore file format version, which at this point is actually, so these files are actually hopelessly out of date as far as that goes. 1.24 was the file format version actually used in MuseScore 1
6) mag is just fraction of whatever the regular size is specified by the font. So if the chord symbol font is 12 points overall, a mag of 0.75 gives you 9 point font for just those symbols.
7) Yes, n and a are note and accidental. So the default is just saying, render the root followed by the accidental, but if your font benefits from superscripting or whatever, this would be the chance to add some positioning adjustment
8) "base" = misspelling for historical reasons or "bass". So you can see in chords_jazz, it's what adds the slash and the bass note, and a bit of positioning adjustment there

All the "token" definition are used to provide render rules for each symbol in different contexts. Like, you might want b and the 9 to be full size in Eb9 but smaller and superscripted in E7b9. So you see a token definition for 9 as class "extension" (which covers Eb9) but a separate rule for 9 as a "modifier" (which covers E7b9). These classes are also used in the automatic superscripting facility you can access in Format / Style / Chord Symbols (this was something I added around 3.3 or so).

A lot of the stuff in this file is actually to work around oddnesses in the original MuseJazz font design. Like, it's basic "7" is already superscripted. I'd have preferred starting from a normal 7 and then do the superscripting in the XML file - or, now, via Format / Style. But I worked with what I had.

Reply

• Sep 18, 2020 - 19:32

Second response post, with a practical question...

Why doesn't the attached XML file render all of my minor chords with a hyphen instead of an m or an mi?

I stripped away tons of stuff to make the file simpler. Sorry if I stripped something essential, but it wasn't working with the larger file either. (The larger file is just the standard XML file with this stuff added to it.)

Thanks!

Attachment Size
chords_jazz3d.xml 574 bytes

Reply

• Sep 18, 2020 - 19:58

"modifier" class is only for things that appear after the extension. The format of a chord symbol is

root quality extension modifiers

(where root is actually note + accidental, but I don't think those are actually implemented as "classes", just quality, extension, and modifier).

So in F#7b9sus, F# is the root (note F, accidental #), the b9 and the sus are modifiers. During the parsing and rendering process, we see "b9" as a single entity conceptually but we actually render the tokens "b" and "9" individually.

Anyhow, you probably want "quality" class to get Cm7 to render as C-7.

Reply

• Apr 17, 2021 - 23:56

Can you tell me what font uses the hyphen (i.e. C-7_ for a minor chord? My MuseScore3 keeps defaulting to Cmi7 when I am writing jazz charts. No pro jazz musician uses that type of notation for chord input. Its too messy and can be ambiguous depending on the handwriting of the composer.

Reply

• Apr 18, 2021 - 04:37

I'm not sure what you mean here, if you are using any version of MsueScore from the past 10 years or so, MuseScore lets you type whatever you want, no special font required, and you can also choose any font you like and "-" renders as "-" because it uses the standard ASCII characters. Unless maybe you are trying to edit charts originally created in MsueScore 1? Those would indeed convert what you type to ma & mi when using the jazz style, but that hasn't been the case for years.

If you use any of the jazz templates, or manually set the chord symbol sppearance to Jazz in Format / Style / Chord Symbols, then MuseScore uses the MuseJazz font, but again, you can still type pretty much whatever abbreviation you want for minor - "-", "mi", "m", "min", etc.

FWIW, though, "mi" is the standard abbreviation used for minor by most major publishers of jazz arrangements (Hal Leonard, Kendor, etc) as well as major fakebooks like the New Real Book series. "mi" for minor, "ma" for major. There's nothing at all ambiguous about this, but "m" by itself certainly can be and is not recommended for that reason. Not actually important here because MuseScore accepts all of the above and more. But if you do use the MuseJazz font, the "mi" and "ma" characters are specially designed to reflect the "small caps" look used in many of the publications that use these.

Reply

• Jan 26, 2024 - 11:13

I would like to echo smartalec's comments about the lovely software. The creators of this brilliant program gave it all the features of the expensive (paid) programs. You have given us a service which we can never repay! Thank you so very much!

Reply

• Aug 5, 2024 - 16:56

Leaving this here in case someone else stumbles on the same problem:

If you want to add a custom layout for a particular combination of modifications (like vertically stacking multiple modified notes) and you try to do this by defining your own named token, the name should avoid digits 1-9, parenthesis and comma, since these are handled specially during parsing.

I was trying to create a vertically stacked b5 b9 format, and my rendering instructions weren't being picked up because I had named my token b5b9 which is parsed as b,5,b,9 — once I renamed the token it was picked up fine.

Reply

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