[MEI-L] Debussy La Danse de Puck clef

[Roland, Perry (pdr4h)]

Craig,

Your **kern encoding is similar to how I think of encoding this in MEI --

<staff n="2">
  <layer n="1">
  <!-- This layer "inherits" the clef set for this staff earlier. -->
    <chord dur="32">
      <note pname="b" oct="3"/>
      <note pname="e" oct="4"/>
      <note pname="g" oct="4" accid="n"/>
    </chord>
    <chord dur="8" dots="2">
      <note pname="e" oct="4"/>
      <note pname="g" oct="4"/>
      <note pname="b" oct="4"/>
    </chord>
    <chord dur="2">
      <note pname="e" oct="4"/>
      <note pname="g" oct="4"/>
      <note pname="b" oct="4"/>
    </chord>
  </layer>
  <layer n="2">
    <!-- This layer gets a "local" clef definition. -->
    <space dur="4"/>
    <clefChange shape="F" line="4"/>
    <note pname="e" oct="1" dur="4" tie="i"/>
    <note dur="8" tie="t"/>
    <rest dur="8"/>
  </layer>
</staff>

As you say, in the next measure it is assumed that the clef for this staff reverts to the clef.shape and clef.line values set by a preceding <staffDef>.  Or, more precisely, that the clef for layer 1 never actually changed, only the one in layer 2.  And, yes, there should be more attributes on <clefChange> and <clef> to better indicate the clef's relative size and position.  In MEI "geek-speak", it's a matter of making <clef> and <clefChange> members of existing attribute classes (att.relativesize, for example) or adding new attribute classes, if existing classes don't have the desired attributes.

I agree that, if you want to perform transposition or other operations on an encoding, then the encoding must represent the "logical" qualities of the notation first and make the visual qualities secondary.  That's the intention of MEI.  The SCORE "work around" you describe is only necessary because it appears that SCORE can't handle multiple clefs (potentially one for each voice) on a staff. MEI can deal with this multiple clef situation, so I don't see any reason to enshrine the SCORE methodology in MEI.

Adding a "staff-clef" attribute to every note seems like overkill to me.  Isn't this just a different version of what's already going on with <staffDef> and <clefChange>?  In other words, if you want to know what clef a note should be displayed with, you can look backwards to find the last <staffDef> or <clefChange> involving the staff the current note is on.  @staff-clef would be a way to put that information directly on the note without having to scan backwards, which could be helpful, I suppose, but the additional attribute might just add more confusion.  But I could be wrong.  It's happened before. :)  I also haven't looked at the Ravel example in detail.  Please enlighten me, if I've missed something important.

Eventually someone always gets around to mentioning Bach's canons as examples of "strange" notational practice.  My basic answer is that it's possible to encode the notation as presented, for example, in the Canones diversi super thema regium no. 1 on page 8 of a certain edition, or a solution (as given at http://www.youtube.com/watch?v=36ykl2tJwZM).  [I hesitate to say "THE" solution because there can often be more than one solution to a "riddle".]  BUT, I don't think you can encoded both simultaneously in a single encoding.  So, if we choose the first path, the question is how much notational "weirdness" can MEI tolerate before I devolves into chaos?  The visual quirks of the backwards clef and key signature can be represented well enough by adding attributes to elements that represent these things, I suppose, but the "crab-ness" of the performance process can't be encoded without making it explicit; in other words, without providing a "realization".

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________________
From: mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com]
Sent: Thursday, June 09, 2011 10:19 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Debussy La Danse de Puck clef

Hi Perry,

Of course the Debussy/Ravel clef examples are outside of common music
notation syntax, so they should probably be ignored in that sense,
since graphical music notation is an open-ended representation and you
will never be able to fully subdue it :-)  Or in other words,
graphical escape mechanisms would be legitimate to apply in these
cases.

> but for me it's still a clef that's been shifted downward in order to relieve some of the visual "clutter".

In some sense that is how it is functioning, but it is not following
the proper clef syntax, and so it would be difficult to display
properly.  In other words, there is no cancellation of the bass clef
when the treble-clef notes in the next measure occur (yet there is a
repeat of the bass-clef sign in the next measure for the low E's).

In Humdrum, I would encoded the measure along the lines of what you
are thinking, with local layer/voice clefs which conflict with the
primary clef:

**kern
*staff2
*clefG2
32B- 32e- 32gn
8..e- 8..g 8..b-
*^
*                     *clefF4
2e- 2g 2b-        [4EE
.                       8EE]
.                       8r
*v                     *v
=
*-

With *^ being a spine split, and the secondary spine given a different
clef.  When the sub-spines merge again with *v, then presumably the
left-most subspine's clef state would be preserved.  If notation were
to be generated, then there would also need to be some command (as a
comment) in the data for the F-clef to move it down and make it cue
sized.

A useful encoding for this example (and the degenerate Ravel example)
is to have a sub-element (or attribute) for notes which can be used to
indicate with what contrary clef the note is to be displayed on the
staff with:
    clef = treble
    ...
    note
       ---> pitch = E1
       ---> staff-clef = bass
If a note contains such an internal clef, then that would be used to
reinterpret what line on the staff to place the note, since clefs are
coordinate systems for musical pitch placement on the staff.  The
printing of the clef should probably be decoupled from the indication
that the note has a internal clef specification, or there would need
to be an additional indication to suppress printing of the clefs as in
the Ravel Scarbo example.  If the staff-clef is printed, then
vertical, horizontal, and size parameters are needed.

Has the Musikalisches Opfer, BWV 1079 (Bach) been mentioned in the
clef thread?  How would things like table/mirror/crab canons be
encoded in MEI?
    http://www.youtube.com/watch?v=36ykl2tJwZM
Or more traditionally typeset:
    http://imslp.org/wiki/Musikalisches_Opfer,_BWV_1079_%28Bach,_Johann_Sebastian%29
    http://216.129.110.22/files/imglnks/usimg/5/55/IMSLP10042-BWV1079-b.pdf
(see page 8, Canones diversi super thema regium, No. 1).
Number 4 is an interesting one on page 9...

> Of course, the problem with this approach is that a non-human reader of the notation (otherwise known as an
> OMR app) can't know that this is a standard clef with a strange visual placement.  It even takes expert human
> readers a little while to figure it out.

OMR programs have a lot of other things to get right before they can
tackle this example :-)

In SCORE, I would just encode the visual display literally as seen and
not care about non-visual interpretations of the data.  But if I
wanted the SCORE program to understand the pitches, I would encode as
shown in the attached PDF.  There would be three staves, with the
bottom staff using the bass clef (set to be very tiny, since there are
no invisible clefs in SCORE), and then the two offset bass-clef signs
would be encoded as "misc. objects" (code-9 objects) with offsets
based on the note following it (similar treatment to dynamic markings
in SCORE).  Then the bottom staff and the middle staff would be
superimposed as shown at the bottom of the attached PDF.  Encoding in
this way would allow for SCORE to correctly transpose the example.

-=+Craig