Custom Chord Symbol Editor

• Apr 25, 2019 - 19:18

A graphical chord symbol editor (a la Finale) would make writing lead sheets unbelievably easier and more accessible to those who are not-so-xml-savvy. I love the superscription in the stock musejazz chord symbols, but I use a sans-serif font for all my text. I've spent hours trying to figure out the xml—to no avail.
When writing any scores involving chord symbols, I'm forced to use finale, despite wholly preferring MuseScore otherwise.

In the meantime, can anyone direct me to step-by-step directions for roughly recreating the following chord symbol I created in Finale? The C and 11 are a standard sans-serif font, and the ∆ and # are a y and # in Maestro font, respectively.
C∆7.png

PS, this is my first forum post; do let me know if there's anything I can improve.


Comments

In reply to by Gus Bogdanow

Looks like you are using a font that lacks a proper flat and sharp sign. With a font that includes these characters (and includes proper left/right bearing), the defaults should be just fine.

Meanwhile, if you attach your best attempt at customizing your XML file, I'm sure we'll be able to help you get the rest of the way there.

In reply to by Marc Sabatella

That is correct. I choose to use that font globally for my scores, ideally including chord symbols. Clearly, the font is limited by the fact that it does not include musical symbols, hence my request for a graphical chord symbol editor in which one can edit various parameters (e.g. font, size, x/y position) for individual chords character-by-character. I see in the xml that there are font declarations, so I assume one could make different characters use different fonts. Is that accurate?

For the record, I fully understand how default font/musejazz chord symbols appear. Below is an example in the default font. In my opinion, the lack of superscription makes it take fractions of a second longer to read—and take up more space than is needed—than the symbol in my previous post which I created in finale, and efficiency is of the essence in music notation.

Bb∆7.png

My request is that a feature is implemented to make it so this and MuseJazz aren't the only usable fonts in chord symbols, so as to give more unity to scores. A graphical chord editor would allow users to use a font of their choice for the root and extension numbers, while also using a musical symbol font for ∆, ♭, ♯, Ø, o, etc., and to position and size these elements to make their meaning more clear.

I also understand that something like this would be quite the undertaking, and I am in no place to make demands as a user of this open-source software. I'd just like for it to be considered by the team. :)

I'll work on the xml a little bit more, and shoot you an example to get your input. Thanks again for the replies!

In reply to by Gus Bogdanow

Actually, it's been on my mind recently that putting together an XML that does basic superscription and other formatting similar to the "Jazz" style but allowing you to use whatever font you like, would be a worthwhile addition, and not that hard to create. It's mostly just a matter of finding the time to do it, but I do think something reasonable could knocked out in a day or so. The flat and sharp signs are the wild cards, most fonts don't include these, so any XML we created for general use would probably substitute our flat and sharp. But it would then be easy enough to customize the file to use the ones built in to your font.

And yes, some day, a chord symbol editor would be nice. There is code that provided something of a start for this. but it would take quite a bit of effort to get it working well enough to include.

I for one would love to find a "best of both worlds" setting, that uses the superscript and formatting of the "Jazz" style but without the MuseJazz font (eg. the FreeSerif default font used in the "Standard" style).

I understand I could set this up myself through custom XML but that is very difficult and time-consuming to get right (I've tried a few times and given up)...

In reply to by Marc Sabatella

So that's what "extensions" and "modifiers" are. The XML file itself has next to no documentation inside it, nor was I able to find any reference for it. Nevertheless, I got tired of badly-formatted chord symbols, and built myself a new chords.xml file to provide the superscripted formatting that most music I see uses.

In reply to by snarke

Do you mind sharing what you did? What I'm really trying to achieve is to just make the "o" on a diminished chord and the "0" on a half-diminished chord turn into superscript. The new 3.3 settings don't seem to consider those as either "modifiers" or "extensions". Again, all I want is the Jazz behavior but with a standard serif font so I can replicate what other software can do.

In reply to by Alex Burr

Technically, the diminished and half-diminished symbols are not extensions or modifiers - they are quality indicators, like major or minor. But even so, they should respond to the offset if not the scaling for extensions, not because they were specifically designed to, but it happened to work out that way.

So you should already be able to get that behavior using extension offset. Or you can use the actual diminished symbol, from the Special Characters dialog (press F2 while editing to display).

In reply to by Marc Sabatella

So I guess what I would expect is that the diminished/half-diminished symbols and the extensions would have separate offsets so that the following is the default. (I believe this is the way the "Jazz" setting works now, so clearly someone agreed at some point.) Using special characters is a workaround but not really practical (and error-prone) when inputting long progressions of chords via keyboard.

Attachment Size
example.gif 20.88 KB

In reply to by Alex Burr

Personally, I'm inclined to agree that it should be that way, and frankly I'd rather see it happen without the need for us to implement, or the user to mess with, yet more style settings.

I could add the superscripting directly within the XML file, but I'm a little reluctant because it's been this way for years and hardly anyone ever complains, and I don't want to have to quibble over exactly how much superscripting it should be.

But maybe a slightly different approach makes sense. Right now, we use Unicode symbols 0x03bf for diminished and 0x00f8 for the half-diminished. These are just Latin/Greek letters that I guess we chose because they are likely to be present in most fonts. But we could simply switch over to the actual Unicode diminished and half-diminished symbols automatically. Downside is they aren't necessarily present in all or even most fonts, but I think we do successfully fallback on the builtin fonts so hopefully you don't get the "empty box" when using a font that doesn't provide it. And then if someone doesn't like the degree of superscripting, we can advise to choose a different font.

BTW, there are actually two different codepoints for these symbols - Unicode and SMuFL. Not totally sure which makes sense to pick.

In reply to by Marc Sabatella

Then there is the issue of chord symbols expressed with superscripting on two lines, for example a G6add9 chord which is often notated with superscript 6 and a superscript 9 right below it.

I for one would love to have that option as well, mainly for space saving reasons instead of writing G6add9 or G6(add9) when using the Free Serif font which I have chosen as my standard, and of course having the chords transpose without tweaking the text.

In reply to by HuffNPuff

G69 should already be notated that way in both Standard and Jazz styles, because the is special-casing in the XML files for that. But it would indeed be nice to be able to have any combination of extensions/alterations stacked, and that would require some new design and code, and then I suspect people will still want additional customization. So I'm more inclined to see us do the chord symbol editor first.

In reply to by Marc Sabatella

Hmm. I don't know if my opinions' all that well informed, but I would vote for switching over, and using Unicode code points. "Not well informed" reflects I don't know what SMuFL is, but I think the more everything uses Unicode for encoding, the simpler life gets, except where Unicode results in a notably poorer final result. (A more complicated implementation, I'm okay with that, because, it being Unicode, said complicated implementation may already have been made for a different application as is thus off-the-shelf, or will become a module for somebody else's problem later).

In a related comment, which I don't remember if I'd mentioned elsewhere or not, when I implemented my superscript chord extensions, I didn't shrink-and-raise the numerals, I used the actual superscript numerals, and to my eye, there's a visible improvement in appearance. The superscripted numerals are stroke-width-balanced to harmonize with the full-size letterforms, where the 'synthetic' superscripts look spindly and anemic. Ideally, all the superscripted glyphs would be customized to the appropriate weight, but my font-file design skills predate Unicode, so I have no idea how I'd construct a font file so the appropriate symbols could be invoked, even if I had the time to make the glyphs. {sigh}

In reply to by snarke

SMuFL is the extension to Unicode specifically intended to encompass music symbols, it's the standard used by MuseScore and at this point most (?) other notation programs. Unicode itself is much more limited in the number of musical symbols it supports or the way it defines how they should behave.

I suppose we could add a checkbox to the chord symbol style dialog to control superscripting of these two symbols, in case someone really wants them not superscripted.

As for the implementation of superscripting, true enough, there are subtle differences in how glyphs are rendered in some font between superscript versus ordinary font at a smaller point size. I tried to use that to advantage in the Campania font for Roman numeral analysis. The downside of using them for chord symbols is that the actual amount of superscripting is not configurable most fonts would yield superscripted numerals that are too small and/or too high to work well for chord extensions, and then there would not be a way to differentiate them from modifiers.

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