[MEI-L] "Cancelling" key signatures; non-standard key sigs
Roland, Perry D. (pdr4h)
pdr4h at eservices.virginia.edu
Fri Sep 5 20:49:51 CEST 2014
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
More information about the mei-l
mailing list