search

w3c / musicxml

MusicXML specification
512 stars 57 forks source link

Support for Roman numeral analysis #295

Closed ecstrema closed 3 years ago

ecstrema commented 5 years ago

There is currently a huge vague concerning support for roman numeral analysis. It looks like they are under the same tag as the Chord symbols, which I believe is very unpractical. Is there any work being done in an separating chord symbols and roman numeral analysis into 2 different elements? Since the chord symbols already use the syntax from David Huron, roman numeral analysis could use it too.

what leads here:

ecstrema commented 5 years ago

A more detailed documentation about chord symbols vs roman numeral analysis would solve the problem, though...

MarcSabatella commented 5 years ago

I don't think it's just about the detail of the documentation, I think something is incorrect. When I tried actually creating a MusicXML file using the exact example provided already:

`

IV 
  </harmony>

`

It fails validation (missing child element). Adding a "kind" element helps, but it's not at all clear how we are supposed to handle, for example, IV6. or V/IV, etc.

mdgood commented 4 years ago

Thank you @Marr11317 and @MarcSabatella for raising this issue. I don't think we have a lot of implementations of Roman numeral analysis in MusicXML, so it is likely the documentation could be improved. I would like to explore this some more to see if this is mainly a documentation issue, or if there is indeed a need to separate out Roman numeral analysis.

It has been a long time since my school days with Roman numeral analysis, but I believe that the examples mentioned would be done as follows.

IV would be:

<harmony>
  <function>IV</function>
  <kind>major</kind>
</harmony>

IV6 (superscript 6) would be:

<harmony>
  <function>IV</function>
  <kind>major-sixth</kind>
</harmony>

V/IV would be:

<harmony>
  <function>V</function>
  <kind>major</kind>
  <function>IV</function>
  <kind>major</kind>
</harmony>

I would appreciate suggestions as to how to clarify the documentation to make this more obvious. If you think I have something wrong because of my inexperience with Roman numeral analysis, please reply with a correction.

Please list other questions here so that we can be sure to clarify the documentation for 3.2. By exploring this are some more we may also find that some additional functionality is needed, either in the current elements or by separating things out.

mscuthbert commented 4 years ago

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, while <kind> should remain "major".
  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)

MarcSabatella commented 4 years ago

I agree with the points Michael Cuthbert raises above. In particular, regarding 4), a fundamental problem with sharing code and representions between RNA and chord symbols is that "6" means something entirely different. For RNA, it means first inversion, not a major sixth chord. So software that handles RNA needs to know this, and needs to be able to represent it meaningfully in the MusicXML (and same on importing the MusicXML). 6) is also an important thing to consider if one is trying to write software to, say, convert betwene chord symbols and RNA. Not sure it matters if it's up to the user to enter the RNA.

Side note: some of you may be aware I have developed a font for RNA. It's free / open source and should work in any application/OS that supports OpenType features for fonts. The idea is you type something very straightforward like vii065/IV and it automatically renders reasonably with no special application support needed:

fontforge_5vKZLBZ1kf

See https://github.com/MarcSabatella/Campania

I figure this font may be interesting to people interesting in this topic, but its use also raises some interesting questions relevant to the topic. We have implemented RNA support in MuseScore with no parsing at all - we just rely on Campania to render the text for us. That made the implementation in MuseScore very simple, but it does mean we don't have an internal representation to work from in exporting MusicXML (whereas for chord symbols, we do our own parsing.

I expect I'll end up writing a parser to RNA in MuseScore eventually, mostly to support MusicXML once this is finalized, but then I'll have the problem of making sure the MsueScore parser is consistent with what Campania is rendering.

What this all suggests is that it might be nice to actually try to standardize on a "grammar" for RNA.

mscuthbert commented 4 years ago

(Apologies if this goes to email to the list -- it's just a little too long to lose the comment so I don't want to cancel the post.)

Everything that @MarcSabatella said about using kind (in fact, IV6 has as its interval from bass to the 6th of a minor-sixth, and iv6 has a major-sixth).

One of the most controversial decisions I needed to make in music21 was deciding what do "VI" and "vio" and "vi" mean in minor? (similar problems arise for ^7) Let's say we're in A minor -- the most common sixth-scale degree chords are going to be F major and f#diminished. I believe that the majority of theorists would call these chords "VI" and "vio" respectively -- this is music21's default. But this means that the root of the chord is determined by the quality of the roman numeral. That's easy for humans to understand but makes parsing a lot harder. Or you can say that the flat-6 is the norm so you'll need to specify "VI" vs "#vio". Or you can say that sharp-6 is the norm, so they'd be "bVI" vs "vio". Or some other theorists say that you always need the sharps and flats, so "bVI" vs "#vio" -- but then what does a strange chord like "#VI" mean? (F# major?) And "vi" (minor chord on 6) is ambiguous in any of these cases -- is it F minor or f# minor?

I suggest that musicxml should choose an option that would be the "right" answer (I'd hope to choose the music21 default, but any specification is better than none). But that the display of the symbol can be different from its specification. (Also for V64/I64/Cad64, etc.)

mdgood commented 4 years ago

Thanks for all the great discussion! My decades away from roman numeral notation are showing: the IV6 example should be:

<harmony>
  <function>IV</function>
  <kind>major</kind>
  <inversion>1</inversion>
</harmony>

There are a lot of great ideas here that I think we can integrate into the existing harmony element rather than requiring a new element. I will come back with more detailed questions once we fix up the mailing list setup - we have a pull request submitted at the appropriate W3C repo. However I wanted to fix my earlier mistake as soon as possible since it was causing confusion.

kepper commented 4 years ago

(I could not find any support for Roman Numerals in MEI)

MEI is perfectly capable of handling Roman Numerals of all kinds, it's just not using specific markup for this very set of theoretical approaches. In essence, there are generic ways to capture the visual appearance in a score, and there are (different) generic ways to capture the semantic meaning of that, as sometimes the relationship between these two is more complicated or dependent om context than one may expect. It's quite similar to the question of written pitch vs. sounding pitch encoding – in reality, you need both at the same time, but independent from each other. A good starting point into that is the following chapter from the MEI Guidelines, even though it's currently under revision: https://music-encoding.org/guidelines/v4/content/analysisharm.html#harmonyDetails

tldr: there very well is good support for Roman Numeral in MEI, and people are using it for that purpose…

mdgood commented 4 years ago

Now that our GitHub mailing list integration is back to normal, I would like to come back to some of @mscuthbert's suggestions with several follow-up questions and comments.

1) Is there some higher-level way of describing "the roman-numeral part of the roman numeral"? That is what the <function> element was trying to do, if incompletely. I think the term "function" may have multiple meanings in this context. We could use something like <numeral>, but I think it would be better if the name were more descriptive and less literal.

2) It sounds like the <function> element or its successor should have a pair of <function-step> and <function-alter> elements, similar to how the <root> element works. If we had a new single-word name for "function", we could deprecate the existing <function> element and recommend the new element instead. Otherwise it seems the only way to add this would be confusingly different from how the <root> element works.

3) I am not quite understanding the issue here. I think we could address the different displays by adding additional attributes as needed, similar to what MusicXML does for chord symbols. Do you have a more specific example of where that approach would fall short?

4) Corrected above as you suggested.

5) I am not sure I agree with having a default value for "stack-degrees" for the <kind> element, at least with chord symbols. The implementation-specific defaults translate nicely to user-specific layout settings, which seems like a good thing. I do see that there may be less variability in choices for roman numerals than for chord symbols though.

6) Proposals for capturing this in MusicXML are most welcome!

One other feature came to mind, which is to add similar formatting attributes to the <function> element (or its successor) similar to what the <root> element's children have, and the same for <inversion> compared to the <bass> element.

MarcSabatella commented 4 years ago

Somewhat naively speaking, "root" is more accurate description for what "function" is doing in the simple cases. I mean, ii and IV may have the same "predomnant" function, and I and iii may both serve 'tonic" function, but the roots all differ. But neither term cleanly covers V/V. Here the "function" is best described as "secondary dominant", or perhaps "function" of dominant but "secondary tonic" of "V".

Then there are "Roman numerals" like N (for Neapolitan), as well as It, Ger, and Fr (for the various augmented sixth chords).

Given also that the key center may change rapidly - independent of the actual key signature - I think trying to capture this is a really rigorous way is likely to be more difficult than it's worth. So I'd focus instead on at least capturing the syntax if not the semantics. For example, we could say an RNA element is:

[R2/] [R1] [IL1] [-IL2] [other]*

or something like that (according to my rough approximation of what the regular expression syntax might look like). So for example I64 would be R1 = I, IL1 = 64. V/ii would be R1 = ii, R2 = V. V4-3 would be R1 = V, IL1=4, IL2=3. But even stripping away some of the complications this way, it would still need to handle much more than this to be truly useful. Frankly, I'd settle for just a plain text string for the whole thing rather than come up with some super-sophisticated representation system that is hard to understand and implement and still is full of holes.

Marc

On Tue, Oct 29, 2019 at 6:17 PM Michael Good notifications@github.com wrote:

Now that our GitHub mailing list integration is back to normal, I would like to come back to some of @mscuthbert https://github.com/mscuthbert's suggestions with several follow-up questions and comments.

1.

Is there some higher-level way of describing "the roman-numeral part of the roman numeral"? That is what the element was trying to do, if incompletely. I think the term "function" may have multiple meanings in this context. We could use something like , but I think it would be better if the name were more descriptive and less literal. 2.

It sounds like the element or its successor should have a pair of and elements, similar to how the element works. If we had a new single-word name for "function", we could deprecate the existing element and recommend the new element instead. Otherwise it seems the only way to add this would be confusingly different from how the element works. 3.

I am not quite understanding the issue here. I think we could address the different displays by adding additional attributes as needed, similar to what MusicXML does for chord symbols. Do you have a more specific example of where that approach would fall short? 4.

Corrected above as you suggested. 5.

I am not sure I agree with having a default value for "stack-degrees" for the element, at least with chord symbols. The implementation-specific defaults translate nicely to user-specific layout settings, which seems like a good thing. I do see that there may be less variability in choices for roman numerals than for chord symbols though. 6.

Proposals for capturing this in MusicXML are most welcome!

One other feature came to mind, which is to add similar formatting attributes to the element (or its successor) similar to what the element's children have, and the same for compared to the element.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/musicxml/issues/295?email_source=notifications&email_token=AANXOADCHAACE5IENMO5VVTQRDHBXA5CNFSM4I52ELFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECSQD2Y#issuecomment-547684843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANXOAFNMZEWQT3RWIXKFV3QRDHBXANCNFSM4I52ELFA .

-- Marc Sabatella marc@outsideshore.com

jsawruk commented 4 years ago

@mscuthbert: I agree, I think <function> should be renamed. I have read over this issue several times, and I keep getting confused because function could mean a lot of things.

Perhaps we should instead have one or multiple <analysis> or <roman-analysis> elements? This seems to capture the subjective aspect of this data. Harmonic analysis is frequently subjective, and I think there needs to be a way to separate the semantics of "present this to the performer so they can perform it (figured bass, chord symbols)" vs. "this is an analysis created by a music theorist". The <harmony> type seems to capture both of these semantics, which I think is your point regarding this issue.

I also agree that <kind> should not include major-sixth etc. and should just use numbers instead. I'm not sure what an appropriate name would be yet, so I am just calling this figured-bass in the example. This would be an attribute that would contain a string of numbers representing the inversion information. I initially thought separate elements would be good encoding, but right now I am leaning towards attributes so that they live in close proximity to the Roman numerals that they are associated with.

I realize there is a lot that needs to be discussed here; I'm just trying to wrap my head around some of these issues using by creating concrete examples that we can discuss further.

Here's a proposal of encoding bII6/V (Neapolitan of five):

<harmony>
  <analysis>
    <numeral type="primary" figured-bass="6">bII</numeral>
    <numeral type="secondary">V</numeral>
    <analysis-name>Neapolitan of five</analysis-name>
  </analysis>
  <inversion>1</inversion>
</harmony>
kianwilcox commented 4 years ago

@mdgood Sorry if I'm misunderstanding here, but is it possible to simultaneously print a chord symbol and multiple functional analyses at the same time? For example, if I am modulating between two tonal centers with a pivot chord, and wish to annotate the pivot with the before and after interpretation. If so, what is an example of doing so? I cannot seem to get the grouping element to help in this situation, but I may be placing it at the wrong level - does it go within or around the harmony element?

mdgood commented 4 years ago

@kianwilcox Sorry for the delay in replying. I believe you should be able to do this using multiple <harmony> elements. However, application support for functional analysis is pretty limited at present, which is one of the reasons this topic has been raised.

mscuthbert commented 4 years ago

(will be moving on this!)

mdgood commented 4 years ago

Thanks @mscuthbert! Feel free to split this into multiple new issues if you like, or keep it all here, whichever seems more appropriate.

hstanekovic commented 3 years ago

I think that harmony element in MusicXML, in situation when it describes roman numeral, should include musical key info (unlike situation in which harmony element describes musical chord). In fact, roman numeral like V tells complete story only when we also know "current musical key" i.e. D:V is major triad chord on fifth degree of D major key. When we label roman numerals in harmony analysis, we can omit current key if it was not changed since last time we specified it (that is, at the beginning of the musical score or at last modulation). However, it is still implied. Without musical key, information is not complete and cannot be translated to musical chord! So we really need a way to specify "current musical key" in harmony element. Also, "Current musical key" in harmony analysis can be different than current key signature in musical score.

napulen commented 3 years ago

I just noticed this thread. I feel that I want to jump in here, as I have been using roman numerals a lot recently. It seems somewhat long and complicated to address everything you all have said. I will just point out a few things:

This turned out to be a longer comment that I intended.

hstanekovic commented 3 years ago

I would like to add the following, if it can be helpful. The reason is, I would really like to see a good standard for roman numerals together with positive impacts it might have on music software.

@napulen reminded me that I also developed a similar library used in an online tool for harmony analysis. The tool is here

It can find, for any given musical notes on the onscreen piano keyboard, not only chords, but also harmonies (including all possible secondary chords and others from theory) and shows the proper way to annotate them. The instructions for usage are here

@napulen explanation about secondary chords, that slash implies a key and not a chord is very important.

mdgood commented 3 years ago

There has been lots of great discussion here! In order to make progress and get this into MusicXML 4.0, I would like to propose that the people with more experience in this area make the initial schema proposals. This could be in written comments here or in pull requests. I would like to see the specific elements and attributes being proposed with a description of how they work.

Feel free in these proposals to deprecate the <function> and/or <inversion> elements if needed and replace them with new elements. I suspect this will be needed for <function>, but am not sure about <inversion>.

When we have something that looks workable, I can review for consistency with MusicXML style if needed. For now I am most concerned with getting the semantics where they need to be. I am inclined to still want to use the <harmony> element for this, but if that is not practical we need not do so.

I look forward to seeing what @Marr11317, @mscuthbert, @MarcSabatella, @jsawruk, @hstanekovic, @napulen, and anyone else can contribute. Please be sure that you are a member of the W3C Music Notation Community Group. Many of the participants in this discussion are already members, but I am not sure about @Marr11317, @hstanekovic, and @napulen. You can join by going to our home page and clicking the JOIN OR LEAVE THIS GROUP button.

We want to have MusicXML 4.0 completed by the end of March. This seems one of the more open-ended issues remaining on our list, so it would be good to make concrete progress on it soon. If anyone is able to prototype their solution in their own MusicXML software, that would be ideal. Thanks!

hstanekovic commented 3 years ago

As a humble starting point, perhaps something like the following can be proposed.

The new elements "chord" and "roman-numeral" can be used to make the distinction between annotating a chord and annotating a harmony using roman numerals. The element "key" should be used with roman numerals to specify the current key.

For instance, the C dominant seventh chord with the bass tone G (second inversion):

<harmony>
  <chord />
  <root>
    <root-step>C</root-step>
  </root>
  <kind>dominant</kind>
  <bass>
    <bass-step>G</bass-step>
  </bass>
</harmony>

This is the same as the dominant seventh chord on the fifth scale degree in the F major key:

<harmony>
  <roman-numeral />
  <key>
    <fifths>-1</fifths>
    <mode>major</mode>
  </key>
  <function>V</function>
  <kind>dominant</kind>
  <inversion>2</inversion>
</harmony>

Secondary chords also should be included in the specification. For instance C:V7/IV, that is, the dominant seventh chord on the fifth scale degree of the closely related key on the fourth scale degree of the C major key (the closely related key on the fourth scale degree of the C major key is the F major key and V7 in the F major key is C dominant seventh chord).

<harmony>
  <roman-numeral />
  <key>
    <fifths>0</fifths>
    <mode>major</mode>
  </key>
  <function>V</function>
  <kind>dominant</kind>
  <inversion>0</inversion>
  <secondary-functions>
    <secondary-function>IV</secondary-function>
  <secondary-functions>
</harmony>

Sometimes, secondary chords can be even nested C:V7/v/ii (ii of the C major key is the D minor key, v of the D minor key is the A minor key and V7 in the A minor key is E dominant seventh chord).

<harmony>
  <roman-numeral />
  <key>
    <fifths>0</fifths>
    <mode>major</mode>
  </key>
  <function>V</function>
  <kind>dominant</kind>
  <inversion>0</inversion>
  <secondary-functions>
    <secondary-function>v</secondary-function>
    <secondary-function>ii</secondary-function>
  <secondary-functions>
</harmony>
MarcSabatella commented 3 years ago

I would say that while I became aware of problems in the current spec when I went to implement Roman numeral analysis in MuseScore, I don't have a ton of insight into the best way of representing things semantically.

Actually, unlike the case with chord symbols, MuseScore does no semantic processing of Roman numeral analysis at all. Everything we do to produce nice formatting is done through OpenType processing in the font itself - Campania, a free / open source font I designed specifically for this purpose. And that is something other readers of this might be interested in - it allows any OpenType-aware application to produced great-looking Roman numeral analysis just by typing normally. See https://github.com/MarcSabatella/Campania for more info, and you're welcome :-)

What this means in practice is, for import into MuseScore, all I personally would need or want is a plain text string - eg, "bVII43" which Campania would render nicely with the b changed to a flat sign and the 4 & 3 stacked vertically. I realize that is a selfish and short-sighted viewpoint, of course. MusicXMl should certainly be in the business of coming up with a semantic representation. It's just not something I have given much thought to, and I'd mostly just be pushing to make sure there is a clear way to map it to plain text in the end.

BTW, regarding the proposal by hstanekovic, that does look like the sort of thing that makes sense semantically, but it's a lot of work to get from there back to the simple text string. Harmony objects normally take optional text attributes on the various tags within the object, but it ends up being quite complex to combine them appropriately, as sometimes it is hard to separate out the kind from the degrees, etc. I would hope to somehow avoid similar complexities for Roman numeral analysis. So, again putting my MuseScore / Campania hat on, I might suggest a single text attribute on the object that specifies the whole string at once.

Also, regarding the "chord" and "roman-numeral" tags to differentiate the types of harmony objects - that's OK, but do you really mean to just have the closing , or did you maybe mean ? I'm not up on all the details of XML but somehow a plain looks wrong to me without a matching .

Marc

On Fri, Jan 8, 2021 at 2:01 PM hstanekovic notifications@github.com wrote:

As a humble starting point, perhaps something like the following can be proposed.

The new elements "chord" and "roman-numeral" can be used to make the distinction between annotating a chord and annotating a harmony using roman numerals. The element "key" should be used with roman numerals to specify the current key.

For instance, the C dominant seventh chord with the bass tone G (second inversion):

<\chord> C dominant G

This is the same as the dominant seventh chord on the fifth scale degree in the F major key:

<\roman-numeral> -1 major V dominant 2

Secondary chords also should be included in the specification. For instance C:V7/IV, that is, the dominant seventh chord on the fifth scale degree of the closely related key on the fourth scale degree of the C major key (the closely related key on the fourth scale degree of the C major key is the F major key and V7 in the F major key is C dominant seventh chord).

<\roman-numeral> 0 major V dominant 0 IV

Sometimes, secondary chords can be even nested C:V7/v/ii (ii of the C major key is the D minor key, v of the D minor key is the A minor key and V7 in the A minor key is E dominant seventh chord).

<\roman-numeral> 0 major V dominant 0 v ii

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/musicxml/issues/295#issuecomment-756995818, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANXOAGBAW4ZKB73HYOGERLSY5XBXANCNFSM4I52ELFA .

-- Marc Sabatella marc@outsideshore.com

hstanekovic commented 3 years ago

@MarcSabatella Sorry, <chord /> is the correct form. I edited the post. It seems that using IntelliSense tools made me stupid :)

mdgood commented 3 years ago

We would like to wrap up our feature development work on MusicXML 4.0 in the next few weeks to allow enough time for documentation work in March. It would be a good time to starting finalizing a proposal here.

Thanks to @hstanekovic for making a very helpful initial proposal. I would like to adjust it a bit to make it more compatible with earlier MusicXML versions. Here is one possibility:

I think the presence of the <function> vs <root> elements make it unnecessary to add empty <roman-numeral/> and <chord-symbol/> elements. Similarly, secondary functions can be handled by using multiple harmony-chord entities as in current MusicXML 3.1.

Is this enough to make MusicXML's roman numeral capability more useful? If not, what else is also needed?

Thanks again for all the discussion and insight on this.

mdgood commented 3 years ago

Pull request #385 adds the changes that I proposed in the previous comment. Could the participants in this discussion please review it to see if it makes things better for roman numeral analysis? Suggestions for changes and additions are most welcome. This is not my area of expertise so your continued help is greatly appreciated!

mdgood commented 3 years ago

Wait, #385 as it currently stands does not address @mscuthbert's point above about needing a place for alterations to the main roman numeral. I am now thinking that we deprecate the <function> element and add a new <numeral> element with child elements of <numeral-value>, <numeral-alter>, and <numeral-key>. The latter two would be optional.

It seems we want to support at least two styles of numerals - Roman numerals as well as the Arabic numerals used in Nashville notation. This could be an attribute for the <numeral> element, and <numeral-value> could be defined as an integer rather than a string with Roman numerals as text values. Or we could add a text attribute to the <numeral-value> element. That is likely more consistent with the rest of the MusicXML <harmony> child elements, and provides more flexibility.

Perhaps the mode part of the <numeral-key> element needs melodic, harmonic, and natural minor options to cover the issues about sixth and seventh scale degrees in minor keys. Do the other modes besides major serve a useful purpose in this context?

hstanekovic commented 3 years ago

@mdgood Certainly, it's good to have a separate numeric and text numeral value that can be used together. Text would be human-readable and numeric would be machine-readable.

Regarding modes: Musical harmony cares about musical keys. Musical key can be only major key or minor key. Musical scale can be almost anything (including different modes like harmonic minor mode or diatonic modes Dorian, Phrygian ...). This is from the modern musical theory point of view.

From a practical point of view, the question is how to analyse harmony in modal music. I never did harmony analysis of modal music, so I can only tell what I think might be appropriate approach. For instance, beautiful Bach's chorale prelude BWV 721 is written in the Phrygian mode. The key signature is D major (2 sharps), but it ends on F#, not on D (and not with F# minor chord but F# major chord - Picardy third, I suppose). I think, we would analyse it as written in the F# minor, but with consistently lowering the second degree (G# to G) which then gives us different chords than diatonic chords of the F# minor.

mdgood commented 3 years ago

Thanks @hstanekovic. This is very helpful.

The idea behind the different minor mode options is to clarify what 6 and 7 mean in a minor key. This is the issue that @mscuthbert raised above. I think we would specific that natural minor is used if a key is not specified.

This isn't the default "quality" option from music21 and RomanText, but I think it fits better into MusicXML's overall design. As long as we provide appropriate formatting control, like allowing the alteration to be hidden, I think we will be able to do full conversions back and forth between RomanText and MusicXML's representation.

hstanekovic commented 3 years ago

@mdgood My apologies, I did not read @mscuthbert post before. Yes, this issue is present and controversial!

In a minor key, I use roman seven for the raised and non-raised seventh scale degree (for instance viio and VII harmonies) and vi only for the non-raised sixth degree (for instance, vi#o and VI harmonies).

I had a lot of internal struggles to accept this notation because to my brain it was non consistent and illogical. In the end, I accepted the argument that the notation tends to use shorter symbols for harmonies that occur more often. In a minor key, the chord root is more often on the raised seventh scale degree than on the raised sixth scale degree. Because of this, it is common to use the Roman numeral seven without the sharp accidental even when the chord root is on the raised seventh scale degree.

For instance, you can see this notation in chapter Diatonic triads in Minor, in the book Stefan Kostka, Dorothy Payne, Byron Almén: TONAL HARMONY WITH AN INTRODUCTION TO POST-TONAL MUSIC, which is a popular and very good book. However, it just gives the notation without any explanation, which caused some grind teeth from my side :)

MarcSabatella commented 3 years ago

FWIW, my personal preference - which seems fairly common in the jazz world anyhow - is to have all scale degrees relative to major, even when in minor keys. Thus, in the key of C minor, Eb is bIII, Ab is bVI, A is VI (or vi), Bb is bVII, and B is VII (or, more likely, viio). Not trying to sell anyone on this, but just know, it is a thing. Probably makes more sense if you consider that in this world, A major in the key of C minor is almost always notated as simply VI, not V/ii. So having VI and vi mean different roots really does not work here.

Marc

On Thu, Feb 25, 2021 at 12:38 PM hstanekovic notifications@github.com wrote:

@mdgood https://github.com/mdgood My apologies, I did not read @mscuthbert https://github.com/mscuthbert post before. Yes, this issue is present and controversial!

In a minor key, I use roman seven for the raised and non-raised seventh scale degree (for instance viio and VII harmonies) and vi only for the non-raised sixth degree (for instance, vi#o and VI harmonies).

I had a lot of internal struggles to accept this notation because to my brain it was non consistent and illogical. In the end, I accepted the argument that the notation tends to use shorter symbols for harmonies that occur more often. In a minor key, the chord root is more often on the raised seventh scale degree than on the raised sixth scale degree. Because of this, it is common to use the Roman numeral seven without the sharp accidental even when the chord root is on the raised seventh scale degree.

For instance, you can see this notation in chapter Diatonic triads in Minor, in the book Stefan Kostka, Dorothy Payne, Byron Almén TONAL HARMONY WITH AN INTRODUCTION TO POST-TONAL MUSIC, which is a popular and very good book.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/musicxml/issues/295#issuecomment-786150894, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANXOAAXHEZB72T346O73TDTA2RGPANCNFSM4I52ELFA .

-- Marc Sabatella marc@outsideshore.com

mdgood commented 3 years ago

@MarcSabatella Thanks for this feedback. What I am proposing for MusicXML is that the different minor modes would affect the root for all 6 and 7 chords, not just minor and diminished chords as in default music21 / RomanText settings. I believe the default of using natural minor in minor keys would give the results you are looking for. I think you will still be able to do a round-trip from RomanText to MusicXML back to RomanText and maintain the same appearance.

MarcSabatella commented 3 years ago

By my understanding, natural minor is the opposite of what I want. I want VI in the key of C minor to mean A, not Ab. And I want Eb to be bIII, not III. I can't say I understand what I see in the PR, I don't actually see any specific text that addresses this, but I don't know what I'm looking for. The word "natural" doesn't seem to occur within the changes though.

hstanekovic commented 3 years ago

What about classical music where, in any minor key, both raised and non raised seventh scale degree are annotated in the same way? For instance, viio and VII chords.

numeral-key=natural minor numeral-value=7 numeral-alter=raised kind=diminished

is viio chord but you can not see that it should be annotated as viio, it looks that it should be annotated as vii#o

mdgood commented 3 years ago

@MarcSabatella Ah, thanks for the rewording. It was clear before, I just misread it somehow. I think you will be able to do this by specifying the key for the numeral as C major even though the key signature for the music is in C minor.

The way the proposal is currently being written, you would need to specify this on each <harmony> symbol. Trying to save state for harmony context vs key signature context seems like it could be confusing and error-prone. It's more verbose to write it out each time, but I think it will exchange better that way.

The proposal I am talking about is not yet in the pull request, as I am still working on it. The pull request currently contains a much older and insufficient version. I will notify people here when it is updated and ready for review, which should be soon.

@hstanekovic I am planning that the <numeral-alter> element will have a print-object attribute so you can hide the alteration. Something like that seems to be a requirement given all the different ways of notating these symbols in minor keys. It will also have a location attribute with values of left and right for placing the accidental before or after the numeral.

mdgood commented 3 years ago

Pull request #385 has now been updated to provide a much more comprehensive fix for the issues raised here. It deprecates the <function> element and replaces it with a new <numeral> element containing <numeral-root>, <numeral-alter>, and <numeral-key> child elements. The last two elements are optional.

This should address the issues of:

This also keeps the new text attribute for the <inversion> element from the previous version of the pull request.

I think this covers nearly all the gaps of things that MusicXML 3.1 could not do with Roman numerals (and Nashville numbers) that were mentioned here.

Comments at all levels are welcome. This includes any missing features, suggested new element or attribute names, and documentation improvements. Thanks again for all the great discussion so far.

mdgood commented 3 years ago

This work was greatly helped by the RomanText article that @mscuthbert and @napulen referenced above. Might @MarkGotham or others have a chance to review this to check that MusicXML could now fully interoperate with RomanText? Thanks again for any further input to get this working better in MusicXML 4.0!

mscuthbert commented 3 years ago

How is "V/V" represented?

mdgood commented 3 years ago

I believe that would be:

<harmony arrangement="horizontal">
    <numeral>
        <numeral-root text="V">5</numeral-root>
    </numeral>
    <kind>major</kind>
    <numeral>
        <numeral-root text="V">5</numeral-root>
    </numeral>
    <kind>major</kind>
</harmony>

If it looks like I am misunderstanding something please let me know!

mscuthbert commented 3 years ago

Ah, is there an implied slash between adjacent numerals? I need to read the spec more carefully -- sorry I haven't had too much time for that.

mdgood commented 3 years ago

There's a slash if arrangement is horizontal or diagonal, and a horizontal line if it is vertical. I don't know if this is clearly stated in the current documentation; let me check.

mdgood commented 3 years ago

@mscuthbert It was specified for the <bass> element but not for the <harmony> element. This should be fixed now.

hstanekovic commented 3 years ago

@mdgood Thanks for the explanation. It looks to me that an option for hiding alterations is a clever way to support both viio and VII.