[MEI-L] "Cancelling" key signatures; non-standard key sigs
Christopher Antila
christopher at antila.ca
Fri Sep 5 22:27:40 CEST 2014
Hi:
I'd like to suggest a strategy that allows both indicating a logical key
signature (with @key.sig and @key.sig.mixed) and its visual appearance
(with <keySig>). This solution doesn't involve changing the MEI
specification, though it would require revisions to the Guidelines document.
In my experience, a key says something about musical perception, but a
key signature is a simple, observable fact. When faced with a task like
naming scale degrees, uneducated people (meaning "my first-year
students") sometimes ask "what key signature is this in?", to which I
respond along the lines of "three flats." Of course they meant to ask
"what key is this in?" (For determining this, the key signature is
certainly a big help).
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.
At first, this suggests that @key.sig.pname and @key.sig.mode are
improper ways to specify a key signature, but I don't think so. When
used to specify a key signature, @key.sig.pname and @key.sig.mode
represent a different way to specify the same information. In other
words, the response to "what's the key signature?" changes from "three
flats" to "the same as C minor."
So I'm not a fan of a change that would allow one of Andrew's examples:
> <scoreDef key.sig="3n"/>
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".
By extension, even a non-standard (logical) key signature specified with
@key.sig.mixed shouldn't include natural symbols. Whenever natural
symbols are used with a key signature, they're cautionary rather than
essential to the meaning. If you're moving from a section with two
sharps to a section with one sharp, the meaning is unequivocal whether
or not the C is cancelled. For accidentals, the situation may be
different, but I'm pretty darn sure that key signatures always start
with everything being natural. Therefore, key signatures specified with
@key.sig.mixed shouldn't encode any natural symbols, which (if present)
are an aspect of the key signature's visual appearance, and do not
change the logical meaning.
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.
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.
Notably, this solution doesn't account for logical key signatures with
double accidentals. I'm sure there's something else I'm missing too!
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
>
More information about the mei-l
mailing list