[MEI-L] "Cancelling" key signatures; non-standard key sigs

Roland, Perry D. (pdr4h) pdr4h at eservices.virginia.edu
Fri Sep 5 23:55:59 CEST 2014 

Thank you, Christopher, for expressing what I was trying to say in a much more succinct and logical manner.

> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
> Christopher Antila
> Sent: Friday, September 05, 2014 4:28 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] "Cancelling" key signatures; non-standard key sigs
> 
> 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).

Agreed, "key" and "key signature" aren't the same thing. 

> 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.

I agree that @key.sig captures conventional key signatures very well.  I also agree that naturals aren't part of the logical key signature.

I see your reasoning for moving @key.sig to the visual domain, but doing so makes it a kind of second-class citizen.  Because a better definition is so elusive, the working definition for the logical domain is "the minimum features necessary for MEI to reasonably function".  Or said another way, the stuff that's left when the other domains are turned off.  Since @key.sig is so useful as a short hand to specify conventional key signatures, I believe it belongs in the logical domain.  Instead of moving it to the visual domain, what if it were left in the logical domain but its name were changed from "key.sig" to "key.fifths"?  It would still have the same function, but that function would be more accurately described.

> 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."

Agreed. Attributes like this already exist --

<keySig pname="c" mode="minor"/>
<scoreDef key.pname="c" key.mode="minor"/>
<staffDef key.pname="c" key.mode="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".

Precisely.

> 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.

<scoreDef> and <staffDef> allow these kinds of attributes for capturing "key-ness" --

<scoreDef key.pname="e" key.accid="f" key.mode="major">

The intended purpose of @key.sig was to provide an alternate way of expressing the same info in terms of movement around the circle of fifths, i.e., @key.sig="3f".  @key.sig is a short-hand equivalent to @key.pname + @key.accid + @key.mode.  In this sense, it's saying something about the key.  But I now believe its name doesn't communicate this function very well.  On the other hand, as you say below, for *conventional key signatures* @key.sig is also saying something about the signature in that it can be used to "help determine the pitch class of following notes".  That's why it ended up being called "key.sig" even though its datatype is related to the circle of fifths.  (BTW, "sharp" and "flat" in data.KEYSIGNATURE are just other ways of saying "clock-wise" and "counter-clockwise".  "+" and "-" would work just as well.  Maybe better, if they made the attribute's purpose clearer.)

> 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. 

Neither Read nor Gould explicitly address the possibility of key signatures requiring double flats or sharps.  Gould (p. 94) writes, "[a]ny *sharp or flat* may be selected as a key signature to alter all octaves of the selected pitches".  Her list doesn't include double flats or sharps. Read (p. 140) says double flats and sharps must be written wherever they're needed, implying that they are not to be included in the key signature.  Likewise, Stone's Music Notation in the Twentieth Century doesn't include any examples of double flats or sharps in key signatures.  The examples provide by Don (http://www.informatics.indiana.edu/donbyrd/CMNExtremesBody.htm#pitch) may be the only ones, I don't know.  In any case, as evidenced by Gould and Read's statements, such key signatures stretch the limits of what a "logical" key signature is to the breaking point.  Currently, they can be encoded using keySig/keyAccid, but not @key.sig -- we may just have to live with this limitation for a while.

> I'm sure there's something else I'm missing too!

We must be missing the same thing.  :-)

--
p.

> 
> 
> 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