Enhancement of key element and/or clarification of keySig@pname

[craigsapp]

The key element:

https://music-encoding.org/guidelines/v4/elements/key.html

Is currently allowed to be contained in these element:

It was originally designed to be a header-specific description of the key for the work. However, it would be useful to allow in <staffDef> in particular in a similar manner to <keySig>. Alternatively or in addition, it might be nice to allow as a subelement of <keySig>.

A motivation is to allow transposition by key in addition interval, as discussed in this issue: rism-digital/verovio#1189

Here is some example music in the key of A major:

Here is how the staffDef for the music could be formulated to represent A major (I presume):

  <staffDef  n="1" key.pname="a" key.mode="major">
        <clef shape="G" line="2" />
        <keySig  sig="3s" />
        <meterSig  count="4" unit="4" />
   </staffDef>

One question is: is the above equivalent to the following:

  <staffDef  n="1">
        <clef shape="G" line="2" />
        <keySig  sig="3s" pname="a" mode="major" />
        <meterSig  count="4" unit="4" />
   </staffDef>

Technically that looks like it should be equivalent to <staffDef @keysig.pname="a" @keysig.mode="major">...

In other words, is keySig@pname+keySig@mode independent or dependent on keySig@sig? Or in other words, what if these two descriptors are in conflict with each other? Or what happens if keySig@sig is missing but the other two attributes are present?

A related question would be how to encode the key independent of the key signature, particularly in the case of 16th-century music where the last accidental in the key signature is dropped as compared to modern conventions, such as displaying two flats when the music is in E-flat major?

A related problem is that the musical key can change due to modulation, and there is no key change at the point where the key changes. How should such a case be encoded (for analytic purposes)?

---

One possibility would be to promote <key> to have a function similar to <keySig> within the music:

  <staffDef  n="1">
        <clef shape="G" line="2" />
        <key pname="a" mode="major" />
        <keySig  sig="3s" />
        <meterSig  count="4" unit="4" />
   </staffDef>

This would then be equivalent to:

  <staffDef  n="1" key.pname="a" key.mode="major">
        <clef shape="G" line="2" />
        <keySig  sig="3s" />
        <meterSig  count="4" unit="4" />
   </staffDef>

[rettinghaus]

As you can see from the Guidelines @key.mode @key.accid @key.pname are part of MEI.analytical and thus independent from @key.sig. There are multiple examples where the written key signature and the logical key signature doesn't seem to match (e.g. pieces by Mattheson and Mendelssohn):

  <staffDef  n="1" key.pname="e" key.mode="major">
        <clef shape="G" line="2" />
        <keySig  sig="3s" />
        <meterSig  count="4" unit="4" />
   </staffDef>

[craigsapp]

Thanks.

Is [email protected] equivalent to keySig@pname (and same for mode)?

In other words, are these two equivalent in meaning:

  <staffDef  n="1" key.pname="e" key.mode="major">
        <clef shape="G" line="2" />
        <keySig  sig="3s" />
        <meterSig  count="4" unit="4" />
   </staffDef>

  <staffDef  n="1">
        <clef shape="G" line="2" />
        <keySig  sig="3s" pname="e" mode="major" />
        <meterSig  count="4" unit="4" />
   </staffDef>

In other words, when I look for the key, then I will have to look in both places to find it?

[rettinghaus]

I would say yes, they're equivalent.

[craigsapp]

Thanks!

[bwbohl]

probably we should add some schematron rules pointing to the relation if both exist in an encoding or even contradict each other