[MEI-L] "Cancelling" key signatures; non-standard key sigs
Andrew Hankinson
andrew.hankinson at mail.mcgill.ca
Fri Sep 5 18:54:08 CEST 2014
I agree that key can be ambiguous (even in the simple case of major/minor), and often the “true” key is not reflected in the key signature. As far as I understand it, a key signature is a convenience device (to avoid writing accidentals on every note) and makes no declaration of the actual key.
However, I believe the name “@key.sig” is correct and necessary because it makes an assertion about the signature, not about the key itself. If we were to record anything about the actual key, it should be reflected in the analytical attributes since key determination requires an understanding of the written music itself, not just what’s in the key signature. Since the @key.sig and @key.sig.mixed attributes are currently in the logical group, however, I would understand them to be a structural component and therefore make no assertion about key.
So, thinking through this:
<scoreDef>
<keySig>
<keyAccid pname=“f” accid=“n” />
<keyAccid pname=“c” accid=“n” />
<keyAccid pname=“g” accid=“n” />
</keySig>
</scoreDef>
Can also be imagined as:
<scoreDef key.sig=“3n” />
However, this might be confused with:
<scoreDef>
<keySig>
<keyAccid pname=“b” accid=“n” />
<keyAccid pname=“e” accid=“n” />
<keyAccid pname=“a” accid=“n” />
</keySig>
</scoreDef>
So I can see the problem with doing it the “shorthand” way in @key.sig. Yet, @key.sig.mixed is designed to accept multiple accidentals, and a natural is arguably an accidental.
So, while I’m willing to admit that perhaps “n” in @key.sig is not necessary, I’d think that it should be added in @key.sig.mixed.
-Andrew
On Sep 5, 2014, at 11:53 AM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu> wrote:
>
> Hi everyone,
>
> Sorry for joining the party late. There's a lot of stuff going on here, let me address each piece in turn --
>
> Often they're the same, but sometimes there's a difference between capturing the *key* and capturing the *key signature*. data.KEYSIGNATURE is intended to capture the key signature's placement in the circle of fifths, not the accidentals that appear. That's the purpose of the keySig element, which makes it possible to record the rendered accidentals, their placement, etc.
>
> One can choose one from the following options:
> a) use @key.sig and @key.sig.showchange on <scoreDef> or <staffDef> to record changes of key and key signature,
> b) use <keySig> sub-elements of <scoreDef> and <staffDef> to capture the visual rendition of the key signature only,
> c) use @key.sig to record key and <keySig> sub-elements to capture the key signature.
>
> This may seem rather complicated at first sight, but it is necessary for those cases where the effective key is *not* reflected in the key signature. For example, a piece may have a key signature of 2 flats but be *in the key of Eb* due to the occurrence of Ab accidentals throughout. In this case, the markup can reflect this contradiction --
>
> <scoreDef @key.sig="3f">
> <keySig>
> <keyAccid pname="b" accid="f" />
> <keyAccid pname="e" accid="f" />
> </keySig>
> </scoreDef>
>
> Changes of key signatures requiring cancelling accidentals can be indicated explicitly --
>
> <scoreDef @key.sig="3f">
> <keySig>
> <keyAccid pname="b" accid="f" />
> <keyAccid pname="e" accid="f" />
> </keySig>
> </scoreDef>
> ...
> <scoreDef @key.sig="1f">
> <keySig>
> <keyAccid pname="b" accid="f" />
> </keySig>
> </scoreDef>
>
> Or, as Laurent suggested, they can be left to downstream rendering --
>
> <scoreDef @key.sig="3f" key.sig.showchange="true">
> ...
> <scoreDef @key.sig="1f">
>
> in which case 2 natural signs should be rendered at the key change. But, as Eleanor points out, this is dependent on house style.
>
> Looking back over this explanation, it's clear that key.sig is a poor name for this attribute. Maybe key.fifths (and data.KEYFIFTHS) would be better choices. These names reflect a point in the development of MEI before the existence of the <keySig> element.
>
> Likewise, the key.sig.mixed attribute can be used to capture a non-standard *key*. Again, despite its name, it permits only sharps and flats because those are indications of *key*. (I don't have a better name for this attribute. All suggestions gratefully accepted.) <keySig> should be used to record the accidentals and their placement for the *key signature*.
>
> Hope this helps,
>
> --
> p.
>
>
>> -----Original Message-----
>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
>> Andrew Hankinson
>> Sent: Friday, September 05, 2014 10:17 AM
>> To: Music Encoding Initiative
>> Subject: Re: [MEI-L] "Cancelling" key signatures; non-standard key sigs
>>
>> Well, there's a @key.sig.mixed, but that only validates s/f:
>>
>> "[a-g][0-9](\- {1,3}|f{1,3}|#{1,3}|s{1,3}|x)" }+
>>
>> "It is intended that key.sig.mixed contain a series of tokens with each token
>> containing pitch name, accidental, and octave, such as 'A4 Cs5 Ef5' that
>> indicate what key accidentals should be rendered and where they should be
>> placed."
>>
>>
>> On Sep 5, 2014, at 9:46 AM, Byrd, Donald A. <donbyrd at indiana.edu> wrote:
>>
>>> I assume MEI can represent non-standard key signatures? E.g., Bartok's
>> Mikrokosmos has key sigs with accidentals in nonstandard positions and
>> with mixed sharps and flats.
>>>
>>> --DAB
>>>
>>>
>>> On Fri, 5 Sep 2014 08:40:39 +0200, Laurent Pugin
>> <laurent at music.mcgill.ca> wrote:
>>>
>>>>> It?s really only the absence of any key signature (Cmaj/Amin) where an
>>>>> explicit change with naturals would be needed to clarify that the key
>>>>> signature has changed.
>>>>
>>>> In that case I think what you want to encode is the key change (and
>>>> not the key signature). What about a /scoreDef with a @key.mode and
>>>> @key.pname ?
>>>>
>>>> Laurent
>>>>
>>>>>
>>>>> -Andrew
>>>>>
>>>>> On Sep 4, 2014, at 5:21 PM, Laurent Pugin <lxpugin at gmail.com> wrote:
>>>>>
>>>>> Hi Andrew,
>>>>>
>>>>> I would expect this to be done at the rendering. For example, naturals
>> would
>>>>> be added when changing from 4s to 1s. But maybe I am overlooking
>> something.
>>>>>
>>>>> In any case, I am not sure your regexp would do the job since you would
>>>>> probably need to have both s or f together with n. For example 3n1s for
>> the
>>>>> aforementioned case.
>>>>>
>>>>> Laurent
>>>>>
>>>>> On Sep 4, 2014 10:29 PM, "Andrew Hankinson"
>> <andrew.hankinson at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> The data.KEYSIGNATURE regex specifies the following valid values:
>>>>>> "mixed|0|[1-7][f|s]?.
>>>>>>
>>>>>> However, naturals may also appear in a key signature to clarify
>> cancelling
>>>>>> a key signature; for example, if you were to go from Gmaj to Cmaj, you
>> may
>>>>>> wish to write a natural in the key signature to indicate the new key.
>>>>>>
>>>>>> Perhaps the regex should be amended to: "mixed|0|[1-7][f|s|n]??
>>>>>>
>>>>>> Or is there another suggestion?
>>>>>>
>>>>>> Cheers,
>>>>>> -Andrew
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>>
>>>>> _______________________________________________
>>>>> mei-l mailing list
>>>>> mei-l at lists.uni-paderborn.de
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Donald Byrd
>>> Woodrow Wilson Indiana Teaching Fellow
>>> Adjunct Associate Professor of Informatics
>>> Visiting Scientist, Research Technologies
>>> Indiana University Bloomington
>>>
>>>
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list