Re: [musicxml] Separate Roman numeral analysis and chord symbols (#295)

I think that it's worth thinking a little bit more about the connections among Roman Numerals, Chord Symbols, and Figured Bass.  (in music21 we use a Harmony object to represent all three with subclasses for each of these kinds; in musicxml, `<harmony>` represents the first two only).

Some of the things to consider:
1. `<function>` unfortunately is poorly named -- if there are no active implementations I would rename, but most likely it'll need to stay and have a note on the documentation that it does not represent the function of the chord but the roman-numeral part of the roman numeral.  There are many common roman numerals whose "function" is different than its display.  For instance in cadences I64 functions as V  (and is written by some theorists as V64 for that reason; some theorists write Cad64 instead).
2. There does not currently seem to be a place for alterations to the main roman numeral to be stored.  bII6 is a very common chord (Neapolitan).
3.  I think that an explicit "applied" or "secondary" attribute is better than having two `<function>` tags in a row. -- in part because people often want to write "V/V   V" as "[V] -> V"  and these sorts of display transformations shouldn't need to rewrite the harmony object's contents.  Secondary roman numerals can have their own secondary chords ("V7/V/V")
4. I don't think that `<kind>major-sixth</kind>` is the right place to specify inversions (for one thing, we don't have `major-six-four` or `minor-six-five-three` as options).  I think that `<inversion>` should be set AND a degree element should be set.
5. attribute of kind "stack-degrees" should be changed to "yes-no-inherit=default" from "yes-no=default" or something like that, so that if a `<function>` is specified, then stack-degrees defaults to yes, and if `<root>` is specified, stack-degrees defaults to no.
6. an important point that as far as I know there is no support for is that iv6 or V7 etc. only has a clear meaning given the key that the analyst is using.  This key is often different than the key specified in the key signature.  So the key might be Bb major, but at this point we're using "g: i" -- the RomanText specification (to be published formally at ISMIR) specifies both analytic keys and optional analytic keys for alternative interpretation (i.e., "g: i (Bb: vi)") and also pivot keys:  "g: i iv V=D: I"

Thanks for getting the ball rolling on this!  Having good support for Roman Numerals would be something I could use to argue with my colleagues in favor of using MusicXML over MEI for encoding projects.  (I could not find any support for Roman Numerals in MEI)

-- 
GitHub Notification of comment by mscuthbert
Please view or discuss this issue at https://github.com/w3c/musicxml/issues/295#issuecomment-544992399 using your GitHub account

Received on Tuesday, 22 October 2019 14:33:14 UTC