[MEI-L] Debussy La Danse de Puck clef

[Craig Sapp]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: puck.pdf
Type: application/pdf
Size: 131819 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110609/4a02104d/attachment.pdf>