Roman Numeral Analysis font deadlock

• Jul 20, 2019 - 13:43

I find it supremely vexing that the people in Kgrad, who are not responsible for the development of the desktop application, tell those who are, "You shouldn't install this font, but instead, engineer a more elaborate feature" when they are not in a position to schedule or mount such development. If you put the font in the next release, what are they going to do, refuse to install it?

Comments

• Jul 20, 2019 - 13:48

No problem, if that font is then getting embedded into MuseScore, which AFAIK is @Marc Sabatella's mid-term plan? Having that font on the musescore.com site, was/is meant as a short time workaround IIRC.
And those people in Kgrad are paying Anatoly's and Dmitri's wages ;-)

Reply

• Jul 20, 2019 - 14:30

I think it's reasonable not to embed a font into MuseScore before the development of the feature that will take advantage of it. The danger is the font ends up needing to change in some incompatible way based on issues we can't foresee until the development happens. We don't want to introduce incompatible changes into MuseScore twice if we can time it so it happens only once.

For the record, the work on chord symbol playback for GSoC is progressing very nicely, and my assumption is that it will be merged into an upcoming release this fall, and my hope is to get the RNA feature in simultaneously, because the code changes will overlap with the chord symbol playback work.

Once the RNA feature is in MuseScore, the font would be included within the program just like other fonts we provide are, and musescore.com won't need to provide special support for it, nor will people who download scores be required to install the font in order to use the score - everything will just work.

Reply

• Jul 20, 2019 - 15:16

The quotes on the word "scheduled" are completely appropriate :-), but yes, it's my personal goal and plan of record. It really does make more sense than embedded a font into musescore.com prematurely. Also consider, given that RNA support will presumably be coming to MsueScore as a new element type, we'd really rather people don't create too many scores "faking" it as staff text or lyrics or what not. I mean, that's what we've always done so far of course, but if we're creating something for posterity - as I know you are! - better to use the real thing.

My vision for how the feature would work is that it would be just like chord symbols with regard to the navigation features - space to move to next note or beat, tab to next measure, the other shortcuts as well - but would otherwise be plain text that just happens to render using Campania by default. So it won't take long to implement at all, but it would not be backwards-compatible: if someone downloads using the feature and tries to open it in versions that don't support it (eg, 3.2.3) the analysis won't show at all. This is why I think it's important to do it once and do it right.

It is possible we could instead to reuse an existing type like staff text but just introduce a new text style. Then the analysis would still show in older versions, just not using Campania. It would be a bit more work to get the navigation working if I used that approach.

Feedback on these ideas welcome!

Reply

• Jul 29, 2019 - 03:52

So, I'm working on this now, and think I have something fairly reasonable going. Internally, it's implemented as a special type of chord symbol, and thus uses the same navigation commanfs (Space, Tab, semicolon, Ctrl+duration) as other chord symbols, but using its own style settings so it's as if it were a new element type, Also a new command to add RNA. This approach seems best for MusicXML compatibility, although it's actually quite unclear to me how MusicXML is really supposed to work with RNA.

At this point, I'm not seeing any reason not to just use Campania to do the "heavy lifting" of rendering. So really, the main point of my current working code is to disable anything else special about how chord symbols are treated, if they are marked as being RNA. So no transposing, no special parsing in the code above and beyond what the font does already.

The question then is, are people finding Campania sufficient for their needs, and if not, what additional features would the font need?

I'm trying to decide if a similar approach makes sense for the Nashville number system, BTW.

Reply

• Jul 29, 2019 - 18:44

I'm finding Campania almost perfect for my RNA needs.

The only extra features I can think of would be to include some additional chord type symbols, like the circle for diminished and the triangle for Maj7, etc, and perhaps the X that some people like to use for a secondary dominant. Otherwise I can't think of anything it's missing.

Many thanks for making the font available, and even more so if the RNA ability can be incorporated in Musescore itself.

Reply

• Jul 30, 2019 - 02:46

I think it must be a very old-fashioned style of symbol. The only examples I can find are in books by John Mehegan, like the image below which comes from his "Jazz Improvisation - Tonal and Rhythmic Principles".

It's not something I use myself, but I thought it might be of some use to someone, if anyone other than him still uses it.

Attachment Size
Image1.png 30.01 KB

Reply

• Jul 31, 2019 - 11:54

Not too old-fashioned.
I'm used to it.

(I don't think this sign is going to be confused with double sharps. Sharps and flats are on the left.)

It is less encrypted than writing V7/V.
you just add an "x" to the right of the roman number, and that is a secondary dominant and the following chord becomes supertonic. eg: IIx V

Reply

• Jul 31, 2019 - 16:10

It's not clear why Mehegna proposes using "x" at all, but it's clear from the example he doesn't limit its usage to secondary dominant (bII7 would essentially never occur as a secondary dominant, only as a tritone substitution). Also, it seems quite unlikely to me Mehegan would use 6 to indicate an inversion; that's taboo in the jazz world. So really, nothing about this usage of "x" is clear to me. If someone can produce a fuller explanation of the special circumstances in which this symbol is used, that would be helpful.

In any case, glyph substitution in fonts can be context-aware, but only to a limited extent. Devising an appropriate set of GSUB rules to make "x" render literally in just the right cases, while still fully supporting the more common use of the "x" to mean double-sharp everywhere else, would likely be tricky. But I can't really begin without a really full explanation of this unique usage of "x".

Reply

• Jul 31, 2019 - 17:28

OK, that's most unfortunate then - looks like this usage has the "x" (with no 7) to mean "non-diatonic dominant seventh", and inversions are marked with the classical 65 etc. I wonder if (and how if so) Mehegan and his followers (who apparently include the author of that book) indicate sixth chords?

Anyhow, I don't see a way to reconcile that with the more traditional use of double sharp, so is probably no way to have to "x" automatically produce the "right" thing depending on context. Meaning, something will have to give. The use of "x" to mean non-diatonic seventh still strikes me as extremely non-standard, but on the other hand, double sharps on interval indications after the root will be extremely uncommon (unlike double-flats, which of course would occur in a literal spelling of a diminished seventh chord). So maybe the compromise is is, make "##" be the primary method of entering double sharp in any context but allow "x" as an alias only before a root, which is probably the only time it will come up in practice.

Reply

• Jul 31, 2019 - 19:05

Yes, but while the note has a double sharp, that wouldn't reflect in the Roman numeral analysis. It would still be just viio. And even if you did have a case of a chord built on a double-sharped scale degree, that goes before the numeral, so the idea of just substituting for "x" in that context (eg, xiio) would still work. The only case that fails is if an interval after the root requires a double sharp, like "V x6". And while that might extremely rarely happen in figured bass, I am having a hard time imagining a case where it would in RNA.

Reply

• Jul 31, 2019 - 17:50

...or use X (capital x) as the alternate double sharp symbol. I realize this is a deviation from all of the other chord modes, but it removes ambiguity. You could make the parsing program default to x if the position is ambiguous when x is entered, but when X (or ##) is entered always treat it as a double sharp.

Reply

• Jul 31, 2019 - 19:22

Interesting idea, but I hesitate on this for a few reasons:

  • It's not particularly intuitive, no one is likely to stumble on "X" to mean double-sharp before figuring out "##" works.

  • As mentioned above, font GPOS rules just aren't as smart as what can be done in code. I guess I need to reiterate - my RNA support involves no special parsing in the code whatsoever (on the contrary, I disable all parsing for RNA). All the fancy formatting is handled by the Campania font itself (https://github.com/MarcSabatella/Campania). The advantage is, you get a font that is equally well usable in plain text (so it can be used within a text frame, or in a word processor, or another notation program). The downside is, one is a little more limited in how the parsing can work. Yet it has proven surprisingly powerful and useful.

I have already made a tentative change to the font that disables the x-to-double-sharp conversion except before a root, and to enable "##" to always convert, right now I'm feeling comfortable with this.

Reply

• Apr 1, 2020 - 20:35

Hello Marc, I didn't know where to post this, but I am working in Campania doing RNA in MuseScore. I am trying to label Augmented 6th Chords that resolve to other scale degrees than 5 (dominant). However, I cannot figure out how to make a caret or hat over a number so that it represents the scale degree. Ex. Fr+6/^1. but I want the caret to be over the number. Like the example attached. Screen Shot 2020-04-01 at 3.33.39 PM.png

Reply

• Apr 1, 2020 - 20:49

I didn't program in an automatic way to do that, as I'm not familiar with that particular notation. I mean, I have seen carets used to indicate scale degrees, but only in a melodic context, not a harmonic one, In RNA I'm not sure why you wouldn't just use I (capital Roman numeral). Is this a notation used in some textbooks?

Anyhow, you should be able to add that symbol from the Special Characters dialog (press F2 while editing to display). assuming you can figure out the appropriate Unicode sequences to get that. Either there is a precomposed glyph already defined or you'd need to enter the number and caret separately.

BTW, I don't suppose you're looking at the Chopin E minor Prelude? There's something kind of like that there...

Reply

• Apr 3, 2020 - 17:09

By-the-way, something like the Chopin in E minor Prelude would make sense for use of this kind of thing. I'm not currently working on that piece with my students, but the potential is there. This kind of resolution happens "quite often" (but is still rare), in music from the Romantic Era. You nailed it (the context) on the head!

Jim

Reply

• Jul 31, 2019 - 22:30

FWIW, I have submitted a PR for the changes, although it still doesn't include embedding the font itself, so if anyone wants to build and test the PR, you'll need to download and install the font separately.

Here's the PR:
https://github.com/musescore/MuseScore/pull/5246

And here's Campania (including the changes discussed for triangle, x, and double sharp):
https://github.com/MarcSabatella/Campania

Users on Windows can take advantage of the AppVeyor build that can be "installed" like a nightly build:
https://ci.appveyor.com/api/buildjobs/3vm84bj1t8hx44p8/artifacts/MuseSc…

To use the RNA feature, see Add / Text / Roman Numeral Analysis (you can also define a shortcut for this).

Reply

• Aug 2, 2019 - 01:11

Add / Text / Roman Numeral Analysis. And you can define a keyboard shortcut in the usual way, Edit / Preferences / Shortcuts.

The command works pretty much the same way as the lyrics, figured bass, or chord symbol commands in terms of adding an element, then using Space, tab etc to navigate. Internally it's a chord symbol so it uses the exact same shortcuts, including supporting ";" for next beat, Ctrl+(duration) etc.

There is a new text style for RNA, it has its own style setting for default placement, etc.

Reply

• Aug 2, 2019 - 01:39

Excellent, glad things are working!

Sounds like you've figured it out, but the intent of Campania is you just type a notation naturally and the positioning rules in the font handle the rest. So, type "V642" and it automatically stacks the digits. It knows not to stack 13, it knows to start the stack for 642 higher than 64, etc, it converts "b", "#" to proper accidentals, etc.

See the README at https://github.com/MarcSabatella/Campania for some additional info & examples.

Reply

• Aug 2, 2019 - 02:33

Weird, here's how that looks for me:

vrna.png

I suppose there could be a bug in how the font rendering library is working on macOS. Not sure if that's Qt, freetype, or within macOS. Does it work if you do go back and install Campania normally? Be sure to grab the current recent version from that same link. Ideally try both the TTF and OTF if you mind (OTF is what I embedded in MuseScore). If the OTF fails but the TTF works, I could just make that change. If both work when installed outside MuseScore but fail inside, that's tougher.

And thanks so much for your feedback - I had a feeling this sort of cross-platform testing would prove especially important!

Reply

• Aug 2, 2019 - 03:06

Same link as I posted a bit ago with more info on the font - https://github.com/MarcSabatella/Campania

To attach a file to a post, see the "File Attachments" link right below where you type your comment. I used the Image Capture tool within MuseScore to save the image. After attaching the file, you can use the "Insert" link that then appears, to make it appear inline at the cursor location.

Reply

• Aug 2, 2019 - 15:10

Huh, that's really interesting. What I'm concluding from this is that the GPOS rule I have in the font to position that first 6 is somehow not firing correctly, but only with the library that renders the font for us. Probably something about the expression I am trying match in order to detect this. I don't think it's related to total height of the string, as it is not cutting anything off, it's just not positioning the 6 at all. Unless maybe there is some setting in the font I don't know about and that other libraries ignore, that sets an upper bound on high high things are allowed to be positioned, and rules are disqualified if they would result in that being exceeded.

Reply

• Aug 2, 2019 - 16:58

Here's another simple test to perform, then: try "[I64]", and compare against the correct result:

I64-bracket.png

There are only two places in the font where I perform explicit vertical adjustments: one is handling those three-high stacks of numbers (two-high stacks are done using pre-superscripted and pre-subscripted characters), and the other is to make the brackets align a little better with the Roman numerals.

It could be the case that for whatever reason, no vertical adjustments are working with FreeType on macOS. If that's the case, I'd expect to see the brackets a little too low, with the top of bracket aligning with the top of the "I" and the "6" thus sticking out above, and the bracket extended well below the bottom of the "I" and "4". If the rule is functioning correctly, the bracket will be raised a bit to encompass the 6 & 4 better, as shown above.

If the bracket works correctly within MuseScore but the 642 does not, this tells me the issue is with the three-high stacks specifically, either the syntax of my rule or something above exceeding the nominal height. But if the bracket doesn't get adjusted correctly, that tells me vertical GPOS rules are not working at all, so either tat's a limitation in FreeType for macOS or some setting I've missed that somehow doesn't matter on other platforms.

Reply

• Aug 2, 2019 - 17:43

Yep, that seals it - vertical GPOS adjustments are simply not happening. If you enter another I64 on the next beat but without brackets, you should presumably see the letters and numbers line up. Which is to say, it's not that the inside is higher, it's that the outside is lower - the brackets were supposed to be moved up. But the same thing that prevented the "6" in 642 from being moved up is preventing the brackets from being moved up, and that's an incompatibility between how GPOS tables work in OpenType vs how FreeType handles them on Windows and macOS.

So, I know the terms to throw around and have a vague sense of what they mean, and I also believe it's possible we can solve this with trial and error, as I recall doing during the MuseScore 2.0 beta period as I worked on the kerning of the MuseJazz font. Then, I had access to a Mac to test with, but now I don't. So if you can spare the time to work with me on this, I'll follow up with you via email.

One way or another we'll solve this, though. Worst case, I can define "ligatures" (pre-composed combinations of glyphs) just for the sequences actually likely to be used - eg, 753, 653, 643, 642 - and automatically substitute those rather than trying to position the top number above the rest with GPOS rules. And I can always just modify the bracket itself to sit higher rather than use fancy positioning rules. But I'd rather not need to do either of those if I can get the GPOS rules to work correctly.

Reply

• Aug 2, 2019 - 15:02

Understood, no hurry. BTW, I assume the problematic V642 is displaying above the staff because you moved it there explicitly, not because you actually entered it as a chord symbol? Not that this should change anything, it works for me even if I enter it as a chord symbol (only thing that goes wrong is that a leading "b" for flat gets misinterpreted as the root of the chord).

Reply

• Aug 2, 2019 - 19:22

Your mention of the availability of both TTF and OTF versions reminds me of something I meant to report a little while ago but forgot to, so I'll report it now.

When I was experimenting with a previous version of Campania I found that it all seemed to work fine inside Musescore, but when I came to print any score including it the Campania font would not appear. After a bit of head scratching I eventually tried removing the OTF version I had originally installed and installing the TTF version instead, and then all was fine - Campania appeared on screen and on the printed page as well.

This might be specific to my setup, which is admittedly a bit odd - I'm running Musescore 2.3.2 on WindowsXP, and printing to a HP OfficeJet Pro 7720, but it would be good to have confirmation that printing works correctly on other people's more modern systems with both the OTF and TTF versions.

(The new features available in Musescore 3 have finally persuaded me to order a new machine running Windows 10, but it isn't here yet so I can't do these tests myself yet, I'm afraid.)

Reply

• Aug 2, 2019 - 21:20

Interesting! That could indeed be something relating to XP. But also, if the earlier version was the one I originally posted, that one was actually totally different "under the hood" even though it looks about the same - it was based on FreeSerif where the current one is based on Doulos (less restrictive license agreement). This difference could be directly relevant to one working better as TTF but the other working better as OTF, as a font kind of needs to choose which one to optimize for even if it supports both.

Anyhow, I'll try a print tonight and let you know.

Reply

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