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

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.

In reply to by Marc Sabatella

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.

In reply to by smartalec

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.

In reply to by Marc Sabatella

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?

In reply to by smartalec

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.

In reply to by Marc Sabatella

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

In reply to by smartalec

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

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