[MEI-L] trills within beams

[Andrew Hankinson, Mr]

Hi Eleanor,

The way I understand the problem is a choice between the following options:

<trill>
 <note />
</trill>

or:

<note>
 <trill />
</note>

or:

<note id="123" />
<trill startid="123" />

In the first example, note becomes a "child" element of trill; the second example inverts that so that trill becomes a child of note. If we were to wish to express this in "pure" XML, it would need to be a choice between either of these, since XML imposes a very hierarchical structure if used naively. Sometimes this hierarchy makes sense (note as a child of chord), but in this case it doesn't really make musical sense for trill to be a parent or a child of note.

If we were to want to expand trill so that it covers more than one note, we would have to choose option 1 OR we would have to try and figure out some other way of grouping notes. Perry's concern was that if we allow all things that can be trilled, or that can hold children that can also be trilled, then we pretty much have to allow most things as children of trills. This makes the encoding task much more difficult, since it can be very easy to get into trouble and do nonsensical things.

MEI and TEI have a fairly elegant solution to this which is still valid XML but allows us to break out of this rigid hierarchy.

In the third example, we remove the hierarchy and assign the trill to the note by reference; that is, the <trill> element is not hierarchically related to note, but the @startid attribute points to the element where the trill starts. This is much easier to handle, since you can put many other elements between them. For example, you could do this (a highly simplified version of the first measure of the example you attached):

<measure>
 <layer>
   <beam>
    <note id="1" />
    <note id="2" />
    <note id="3" />
   </beam>
 </layer>
 <layer>
   <beam>
     <chord>
       <note />
       <note />
     </chord>
     <chord>
       <note />
       <note />
     </chord>
     <chord>
       <note />
       <note />
     </chord>
   </beam>
 </layer>

 <trill startid="2" />
 <turn startid="2" />
 <accid accid="n" startid="2" />
 <slur startid="1" endid="3" />

</measure>

This allows much more flexibility in the encoding, since it means you do not have to decide whether the trill is hierarchically higher or lower than the note; you can simply list all the "spanning" elements at the end of the measure, and then give @startid/@endid or @tstamp references (as Raffaele mentioned).

I can't speak directly for Perry, but I think that's what he meant by "one pass" vs. "two pass". It's not that you can't do all the encoding in the same sitting, it's just that sometimes you'll want to identify and encode elements that don't strictly fall into the hierarchy later in the measure. So you would, in effect, do two passes through the measure: one to encode the notes, and the other to encode the other events.

The complexity of keeping all this straight when encoding is certainly not trivial, but I don't think that's an MEI issue. My own feeling is that it should be the job of the notation encoding software to help you manage all of the bits and pieces

I think this addresses your concern directly. You don't have to put all elements in an arbitrary hierarchy since things can be referenced after they have "happened" in the score, without needing to decide if it makes musical sense to have it as a hierarchical relationship. This, in my opinion, is more musical than other attempts at encoding music notation in XML since you don't have to make seemingly arbitrary decisions over which musical structure is a child of another.

-Andrew

On 2012-03-05, at 6:03 PM, Eleanor Selfridge-Field wrote:

Hi, Kristina, Perry, et al.

>From my perspective Kristina is prompting a really important question, and one  response (“more than one pass....”) seems to be the inevitable place where all encoders end up when confronted with real music. It may be unavoidable, but it is not ideal.

What is unsettling  in the responses is that we are putting hierarchy above music and the needs of encoders.
When working with MSS, there are dozens of potential distractions, and making a second pass to capture left-over details requires finding the exact spot on the folio, checking to see which features were encoded on the first pass, and, over time, a lot of secondary bookkeeping about what is finished and what has yet to be done. (I know; I did that kind of housework for my Marcello catalogue in the 1980s---3000 bitty music files, each one in need of its own particular notes.)  The  risks of eventual inaccuracy, incomplete information, and duplication are very real.

Granted we want MEI to work, but if it is optimized for programming efficiency at the cost of usability, we may need to step back and look for other solutions. The low level of generalizability of music features across repertories is widely acknowledged, and we are simply encountering one instance here. For another example from the same category, consider  this CPE Bach incipit:
<image003.jpg>

We used it in our “desk-top publishing IEEE tutorial of 1994. [For all the examples go to http://www.ccarh.org/publications/reprints/ieee/ --Category 2, Type 1]

How would MEI handle it?

Eleanor


Eleanor Selfridge-Field
Consulting Professor, Music
Braun Music Center #129
Stanford University
Stanford, CA 94305-3076, USA
http://www.stanford.edu/~esfield/
http://www.ccarh.org



From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de<mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de> [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de<mailto:stanford.edu at lists.uni-paderborn.de>] On Behalf Of Roland, Perry (pdr4h)
Sent: Monday, March 05, 2012 5:50 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] trills within beams

Hi, Kristina,

MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes.

It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies.  It also means that your proposed <trill> element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things.

>From snowy (yes, snowy!) Charlottesville,

--
p.


__________________________
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 at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Kristina Richts [kristina.richts at gmx.de<mailto:kristina.richts at gmx.de>]
Sent: Monday, March 05, 2012 4:26 AM
To: Music Encoding Initiative
Subject: [MEI-L] trills within beams
Hi all,

while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure.

  <image001.png>

Why isn't it possible to provide notes within a beam with a <trill> element, as could be done with single notes, like this:
<trill><note xml:id="m167_s1_e6_A3" pname="b" oct="5" dur="4" stem.dir="down"/></trill>?

Did I miss anything?

Best,
Kristina




_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l