[MEI-L] "Cancelling" key signatures; non-standard key sigs
Andrew Hankinson
andrew.hankinson at mail.mcgill.ca
Fri Sep 5 23:08:26 CEST 2014
Thanks Christopher;
> Thus to me it's clear that conventional key signatures can be
> represented with the @key.sig attribute quite naturally. However,
> naturals aren't part of the logical key signature (in that "what key
> signature is this in?" would never receive a response like "two naturals
> and three flats"), so @key.sig needn't account for natural symbols. If
> you want to include the naturals, that's an aspect of visual appearance,
> so as an attribute it seems to belong in the "visual" domain.
Well, if you’re changing from Gmaj to Cmaj, you could only do this by a) placing a “cancelling” natural as a key signature, or b) placing a natural accidental on every F.
Likewise, if you were to want to shift from Amaj to Amin, you would probably want to include three naturals as a key signature, rather than writing naturals on all F, C, and Gs.
This seems to indicate that a naturals in a key signature aren't just visual; they can actually be structural.
> So I'm not a fan of a change that would allow one of Andrew's examples:
>
>> <scoreDef key.sig="3n”/>
Yeah, I’m not a fan of that anymore either. :)
>
> Not only is this ambiguous, but it's not even a key signature. At least,
> not with my definition, which is reflected in (if not necessarily shared
> by) the current MEI Guidelines. In the context of cancelling a
> three-accidental key signature, the proper @key.sig value is probably
> @key.sig="0s" or @key.sig="0f”.
In MEI, it’s actually just “0”.
> Yet I can't quite wrap my head around this situation proposed by Perry,
> where "the effective key is not reflected in the key signature." The
> music following this <scoreDef> is in E-flat major, though the written
> key signature has two flats.
>
>> <scoreDef @key.sig="3f">
>> <keySig>
>> <keyAccid pname="b" accid="f" />
>> <keyAccid pname="e" accid="f" />
>> </keySig>
>> </scoreDef>
>
> I wouldn't have guessed the meaning Perry intended---this just looks
> like conflicting information. With all of these @key.sig,
> @key.sig.mixed, and <keySig> strategies, the term "key signature" is
> impossible to escape, so I would never expect any of these to hold
> information about the perceived key. Anything that indicates key
> requires a pitch class and mode, and probably belongs in the analytic
> domain. The sharps/flats-based datatype of @key.sig is therefore
> unsuitable for indicating the key.
I think Perry was attempting to demonstrate that @key.sig was meant to indicate that the *key* was E-flat, but that the key *signature* only contained two (i.e., all written “a’s” had a flat accidental).
I agree with you that any indication of key requires an analysis of the musical content, so I still don’t buy @key.sig as an indicator of key. Sorry Perry!
>
> Since <keyAccid> allows encoding any of the accidentals in
> data.ACCIDENTALS.EXPLICIT, it seems we can already strike a nice balance
> between ease and properness by understanding <keySig> as an indication
> of visual appearance. In this situation, @key.sig and @key.sig.mixed
> would help determine the pitch class of following notes, and <keySig>
> would determine the written appearance of the key signature.
>
I wouldn’t want to see <keySig /> be used *only* for visual appearances of the key signature. That seems like it’s curtailing it’s usefulness as a more expressive representation for just these kinds of corner cases.
There are many places in MEI where an attribute is used as a simplified way of expressing common things, while elements are used for more advanced encoding. For example:
<note pname=“b” accid=“ff”>
Would be a quick and easy way of indicating an B-double flat, but should you require a double-flat with a cautionary natural (for whatever reason) you could write:
<note pname=“b">
<accid accid=“n” func=“caution” />
<accid accid=“ff” />
</note>
I’m going to assume the same for @key.sig; If you need advanced key signature functionality, use <keySig />, but for most purposes @key.sig should be fine.
-Andrew
>
> Christopher
>
> On 09/05/2014 02:49 PM, Roland, Perry D. (pdr4h) wrote:
>>
>> Comments below--
>>
>> --
>> 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 12:54 PM
>>> To: Music Encoding Initiative
>>> Subject: Re: [MEI-L] "Cancelling" key signatures; non-standard key sigs
>>>
>>> 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.
>>
>> Well, it does unless/until it doesn't. :-) I think most people think of a key signature
>> as just that, a "signature" left by the logical key of the piece. In other words, it's usually
>> an indication of the key, but not always.
>>
>>> 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.
>>
>> I think you're assigning more intelligence/meaning to the location of attributes in logical and
>> analytical groupings than it deserves, but I'll go along -- @key.sig can/often does say something
>> about the key signature, but only in the usual/simple cases. It can only provide information
>> relating to the circle of fifths, not to all the possible forms of presentation of key signatures.
>>
>>> 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.
>>
>> I see @key.sig.mixed as a variant form of @key.sig. If @key.sig only captures the
>> info in the displayed key signature that relates to the circle of fifths; i.e., sharps
>> and flats, then the same holds true for @key.sig.mixed; i.e., since @key.sig doesn't
>> contain "n", neither should @key.sig.mixed. Another way of saying it is,
>> @key.sig.mixed provides the same kind of "shorthand" for mixed key signatures
>> that @key.sig provides for standard ones. By design, both lack any facility for handling
>> so-called "complex" key signatures -- those having a combination of sharps, flats,
>> and naturals, including cancelling accidentals.
>>
>> Since it's not clear how its value relates to the circle of fifths, perhaps @key.sig.mixed
>> is unnecessary. Removing it would clear up any confusion with @key.sig and would
>> force the use of <keySig> for "complex" key signatures in all cases.
>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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