[MEI-L] trills within beams

Tue Mar 6 16:57:55 CET 2012

If single-note trills are treated differently, then why not any other single-note / instantaneous "control event", such as arpeg, breath, pedal, reh, dynam, etc.?  Once you start down that road, Pandora's box is opened.  A proliferation of attributes wouldn't be helpful.

If attributes were added, @ornam for example, they would only be useful part of the time; that is, in the case of @ornam/ @trill, for a single-note trill and when complete control of the rendering of the trill is to be handled by the rendering engine.  There's no opportunity to add visual information to that trill without resorting to attributes about attributes (and that way certainly lies madness!) 

If an <ornam> child of <note> were added or <trill> allowed to be a child of <note> in order to accommodate visual info., then we're back into the hierarchy problems Andrew so eloquently described yesterday.  In addition, if we allow both possibilities (attribute and child), then user confusion is increased and interchange / interoperability diminished.

When these other things are considered, I believe recording trills and such after the notes they're attached to is still the best of the alternatives.

--
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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
Sent: Tuesday, March 06, 2012 10:05 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] trills within beams

Thanks Johannes!  

I gave a couple examples to show how trill *could* be done in XML (and is done in some other XML-based music encoding schemes), since I was responding to Eleanor's question. But I don't think that it *should* be done that way, since, like I said, it creates a situation where you're forced into creating these artificial and non-musical hierarchies. I didn't mean to suggest that I felt any changes to <trill /> should be made, I just wanted to address Eleanor's question directly by showing how MEI does it differently.

But to address Kristina's question: I did some asking around our lab yesterday. We came to the agreement that a trill is an ornament, not an articulation. If <note /> doesn't have @ornament or something along those lines, I think this is a great argument for it.

One of the musicologists in our lab found a couple helpful pages for this discussion:

http://www.music.vt.edu/musicdictionary/appendix/ornaments/ornaments.html

Couperin's Ornaments:
http://books.google.ca/books?id=CecBsvk7Oz0C&lpg=PA34&ots=VQ2uwRSt_n&dq=ornaments%20couperin&pg=PA34#v=onepage&q=ornaments%20couperin&f=false

-Andrew

On 2012-03-06, at 7:11 AM, Johannes Kepper wrote:

Hi Andrew, 

I absolutely agree with what you say about hierarchy issues etc. I think this discussion is very helpful for identifying what MEI is and what it is not, and, even more beneficial, how people understand it. But still, I think it misses Kristina's initial question. Sometimes, a trill stretches no longer than the note it's written above. In these cases, it seems to be no spanning element on its own, but rather a playing instruction for this particular note. The question then is not whether we want to redefine the model of <trill> to allow it within a note or as a container of notes, but instead if "tr" should be an allowed value of @artic (or any other attribute on <note>). By no means this would argue against the existence of the current standoff <trill>, it would just be a shortcut for describing trill that do not stretch beyond their initial note. Currently, the <trill> would have to duplicate the @tstamp and @dur of this note (@tstamp on notes is normally omitted, I know). 

It is fine to decide that we don't want to offer this limited-power shortcut for a certain kind of trills, but we have several such constructs for other things in MEI already. I don't see that anyone asked for remodelling the trill element (but please correct me!!!!). 

Best,
Johannes

Am 06.03.2012 um 01:57 schrieb 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

_______________________________________________

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