UK (British) style RNA

• Jan 19, 2022 - 09:20

There are various styles of RNA (Roman Numeral Analysis). In Britain the notation Xa - or just X - is used for a root position triad., where X is one of I,II,III,IV,V,Vi or VII [or possibly also I,ii,iii,IV,V,vii - VII is a special case - with lower case letters denoting minor chords].

The notation Xb denotes a first inversion triad - with the third in the bass, while Xc denotes a second inversion triad with the fifth in the bass.

The notation is also extended for seventh chords - example G7 = G B D F. Thus V7 [the 7 would probably be a superscript ..] would denote the G7 chord in the key of C, V7b would have the B in the lowest position, V7c would have the D in the lowest position, and V7d would have the F in the lowest position.

For seventh chords the 'd' suffix denotes third inversion.

RNA notation in the US is different, and similar in ways to figured bass notation.

A problem arises with the British system in MuseScore as the 'b' suffix on a chord symbol is interpreted as a flat - and RNA is treated using chord symbol rules. I think it's possible to get the notation without using the b to denote a flat - but I can't see any clear reference to this in the handbook. Some form of escape code is used before the 'b' to have it treated as a plain b, not as a flat symbol.

British style RNA is used in many books and music schools around the world.

It really would be useful to have clear guidance on this and an appropriate reference in the handbook.

Comments

• Jan 19, 2022 - 11:24

See "For a literal "b" or "#" (i.e. prevent them being turned in to flast or sharp), prefix them with a "\"."

  1. Should be "flat" not "flast".
  2. Also could be helpful to add a comment about why one would want literal 'b's. Not sure if the RNA is also used in European schools - but certainly I'm guessing about half of the RNA theorists in the world still use Ia,Ib,Ic etc rather than I, I6, 6 4 etc. Doesn't need to be a paragraph - but something to indicate why it might be important for some users.

Reply

• Jan 19, 2022 - 14:10

For the record, it's not just b, but any of the special characters in Campania that can be escaped in this fashion - eg, # to enter a literal #, \6 to enter a non-superscripted 6, etc. Backslash is the standard escape character used in most fonts and software, which is why it was chosen.

So the Handbook should reflect that. Britain represents only a small percentage of the world's population as a whole, so I rather doubt anywhere close to half the musicians using RNA would use that system. But no doubt, given the wide variety of possible variations and special pedagogical situations that come up, pretty much everyone will have a need to escape some symbol at some point for some reason. So it should be made clear this isn't just a feature for the British a, b, c system, but any character for which you wish to defeat the automatic formatting for any reason. The case of "b" in British notation would make a good example to be sure, as it will indeed come up very often for those users for whom it comes up at all.

Reply

• Jan 19, 2022 - 15:08

I agree that Britain represents a small proportion of the world population. However it was definitely dominant even into the first part of the 20th Century, and its influence on education around the world has been significant with standardised teaching and examinations which have spread world wide - in music and in other subjects. Whether the musical analysis notation was totally "home grown" or not I can't say. Many British musicians went to study in Germany in the 19th Century, so the same kind of analysis notation may have been common in German and French conservatories.

Reply

• Jan 19, 2022 - 15:54

Could be, but all it takes is a web search (e.g., try "roman numeral analysis inversion", then look at the images only) to see that only a small percentage of educational materials uses this system today. I'm not saying it isn't worth supporting or mentioning in Handbook - I'm just saying, it's even more important to cover the cases that are more likely to be encountered by more musicians. Not that there is any one single example that is likely to be as common as the need for "b" in the UK, but in general, more musicians will need to know how to escape any character than to learn specific details of the UK system, So it's good that the Handbook reflects this - covering the general case primarily for the benefit of all, with the "b" mentioned as one example specifically for benefit of British musicians.

Reply

• Jan 19, 2022 - 19:25

I don't think it is only for the benefit of British musicians. That is my point. I'm not trying to claim any sort of national points - but simply suggesting that the approach is more widespread than you may be giving credit for. If we were to look at world wide influences based on the sort of web searches and data you're suggesting we'd all be speaking and writing Chinese, and studying Chinese opera - completely different traditions - and different styles of music, notation and culture.

Reply

• Jan 19, 2022 - 20:03

I'm certainly open to additional data. Right now the best I have is the web search I recommended, which suggests that the British system is used by somewhere around 5% of all resources. Of course, that's biased as it's just resources on sites that appear in searches on my system, and this favors English-language websites. I kind of doubt you'd find a higher percentage of a specifically British system on sites in other languages, but again I'm open to additional data on this.

Anyhow, it mostly doesn't matter, because again, I absolutely 100% agree it should be supported (as it is) and documented (as it is). But being able to see the big picture is important in being sure that going forward, we optimize both the actual behavior and the documentation for the most common use cases. This is a standard and beneficial principle in design.

Reply

• Jan 20, 2022 - 10:49

This is just such an almost miniscule part of activity it's perhaps hardly worth worrying about. Few people want to analyse music in detail, and few use RNA. I do know that what was previously the system used in the UK would have spread round significant parts of the English speaking world, and to places which are quite remote - maybe because of the use of the English (British?) examination system. [Example: Hong Kong] I'd have to check with the current exam syllabuses to know whether there has been any change in recent years. I do know people who have acted as examiners for such exams - though they may now have what could be considered "old fashioned" views.

I agree that syntactically the backslash can work before any character which would otherwise have a special interpretation.. However in the context of RNA - there is a design decision to make - whether b should be used to represent a flat, or a type of inversion. There could be a perfectly good case for making a decision in favour of the b used to represent a flat being escaped instead. We are not just considering arbitary characters, but characters in a form of notation which has specific meaning - at least in some traditions and in the context of music scores.

I can't see any real harm in allowing both forms {UK and US or other] of RNA notation - except that oddly I still find it much easier to think in terms of first, second and third inversions with a,b and c suffices. Note I would not normally bother with the 'a' suffix. Regarding Musescore, the only RNA symbol which causes a problem with the chord labelling themselves is the 'b', which needs to be escaped with a '\'. This then leads to further confusion as if the backslash is always put in, then one ends up with notation like "I\c" and "V7\d" - but at least it is possible to obtain the "desired" result if one additionally remembers to only put in the backslash before the 'b'. It's just extra mental effort - and it's hard enough trying to do the musical analysis without having also to think about typesetting.

There is another problem - which so far I've not found a solution to. One use of RNA makes use of overlapping keys - for example the chord C E G in the key of G would be IV but in the key of C it is I. There are times - for example when modulating - where is it convenient - particularly if using pivot chords - to notate sections indicating the key in which the RNA is supposed to operate. As far as I can see this is difficult to do with the RNA feature in MuseScore - though by ignoring the "special" RNA character sequences one can get the desired results by using CTRL (CMD) T for plain stave text instead. The intention is to have notation such as:

C: I V
G: IV I etc

Trying to use letters such as G, C etc and colons ':' when trying to type RNA just causes MS to go off in completely unwanted directions.

This does rather suggest that more thought could be given to implementing RNA features in MS.

Reply

• Jan 21, 2022 - 03:46

Again , absent actual hard data to suggest the British system is more common than the other, I will still say, having "b" do flat by default and require a simple override to get the literal b makes more sense than the alternative. But luckily, since this is all implemented via a font, you can easily get the behavior if you want if you can find a font designer willing to customize Campania in this way - like MuseScore, it's open source. Then you could install that custom version of Campania and have the "b" work in that way if you like. It might even be possible to figure out a rule for the exact cases where it should display as flat versus literal, and tweak the rules used in the font to do the right thing depending on context. That would require finding someone with both font design expertise and British RNA expertise.

As for the colon, I'm assuming you are on a keyboard where it is located above the semicolon. So, it's Shift+semicolon. Unfortunately, for many years that has been established as the shortcut in MuseScore for navigating backwards one beat - semicolon is forwards on beat, Shift+semicolon is backwards (just as Tab is forward one measure and Shift+Tab is backwards, etc). So while Campania itself is more than happy to render the colon, it never gets the chance, because Shift+semicolon has the effect it has on navigation. While we could have elected to change the default shortcut for navigation, after careful thought, and collecting input from users, the consensus was it was best to leave the shortcut alone to avoid inconveniencing those accustomed to that.

Meanwhile, it's simple enough to force the colon - use Ctrl+colon (presumably Cmd on macOS although I can't prove) that. It's the same as the way to force a space or hyphen within a lyric - Ctrl is the shortcut MuseScore uses in all such cases to force a character into text that would otherwise be treated as a special command. You can also, if you prefer, simply redefine the "Previous beat" command to be something else.

Anyhow, it's not a matter of not having given this thought - on the contrary, quite a bit of design work went into this, But we were working within an existing framework with existing behaviors and we had to come up with the best compromise that provide the most benefit for the greatest number of users. Just as with the decision that "b" should generate a flat sign by default.

Reply

• Jan 21, 2022 - 08:20

Actually I'm not sure that I agree at all that the choice of the 'b' character to represent a flat makes more sense. It should actually be possible to have the "meaning" of the 'b' keypress determined by a switch - so could be context dependent, or decided by the end user. Of course someone has already decided that in chord symbols b is going to mean a flat symbol, but I suspect that the code was just carried over to RNA where flat symbols might be used, but are needed less (IMO).

MuseScore's approach to RNA needs an overhaul - in my opinion - of course.

I'm sure that thought was given to this previously, but it should be revisited. These things don't have to be set in immutable stone.

Reply

• Jan 21, 2022 - 08:29

I see b (the normal letter) mentioned in https://en.wikipedia.org/wiki/Roman_numeral_analysis#Inversions
And b (flat) in https://en.wikipedia.org/wiki/Roman_numeral_analysis#Minor_scale and https://en.wikipedia.org/wiki/Roman_numeral_analysis#Modes, in both cases as a leading flat sign and also sort of in https://en.wikipedia.org/wiki/Roman_numeral_analysis#Jazz_and_pop_numer…, in the alternative spellings (VIIm7b5, VII-7b5), there in the middle (not rendered as a flat, but that seems a mistake in that page?)

Reply

• Jan 21, 2022 - 14:03

The navigation code for RNA is shared with that for chord symbols - which is why Shift+semicolon is “previous beat”. But the rendering is unique to RNA. As mentioned several times, that rendering is performed by the Campania font itself, not by MuseScore. So the same font works in your favorite text editor as well. Character sequences were carefully chosen so that the ordinary way people might type RNA specifically would come out as intended without the need to learn special rules. For example, “bVI64” is rendered with the b as a flat, the 6 superscripted, and the 4 subscripted directly beneath the 6. Meaning, with no work at all and no special knowledge required, 95% of users find everything works perfectly out of the box as far as the font is concerned.

So again, if someone who is expert in both font design and in RNA wants to help refine the rules that are used to control when the b is rendered as a flat and when it is not so that it stays b exactly when a British user would expect but changes to flat when other users expect (including use cases like chord alterations), I would welcome that input. Feel free to make a pull request to the Campania repository on GitHub.

Reply

• Jan 21, 2022 - 14:53

By way of analogy, consider - you need Ctrl to enter a space or hyphen or underscore into lyrics, because those are the special reserved keys that means something else. That doesn't mean we require Ctrl to enter each and every charactetr, nor does it mean Ctrl+B, Ctrl+C, Ctrl+S, or other shortcuts involving Ctrl stop having their standard meanings. That would beterrible design. It's OK to treat space, hyphen, and underscore specially for lyrics, and to use Ctrl in this design, without messing up how everything else works. And the same for treating b specially, and to use \ in this design, without that needing to mess up how everything else works. Complete consistency for the sake of consistency is not the goal - ease of use is. It's OK for some things to be special-cased if it makes for a better user experience.

Reply

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