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

[Roland, Perry D. (pdr4h)]

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 5:08 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] "Cancelling" key signatures; non-standard key sigs
> 
> 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).

Precisely.

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

I'm coming to the conclusion that I may not be a fan of that anymore.   :-)  Hence, the suggestion to change the name of this attribute to "key.fifths" or even "keysig.fifths".

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

Agreed.  It's not just for visual appearance.  It's for any case beyond the conventional.

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

Ding!  Ding!  Ding!  We have a winner!  :-)

> -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
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l