<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Thanks Johannes! <div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>One of the musicologists in our lab found a couple helpful pages for this discussion:</div><div><br></div><div><span class="Apple-style-span" style="font-family: monospace; "><a href="http://www.music.vt.edu/musicdictionary/appendix/ornaments/ornaments.html">http://www.music.vt.edu/musicdictionary/appendix/ornaments/ornaments.html</a></span></div><div><br></div><div>Couperin's Ornaments:</div><div><a href="http://books.google.ca/books?id=CecBsvk7Oz0C&lpg=PA34&ots=VQ2uwRSt_n&dq=ornaments%20couperin&pg=PA34#v=onepage&q=ornaments%20couperin&f=false">http://books.google.ca/books?id=CecBsvk7Oz0C&lpg=PA34&ots=VQ2uwRSt_n&dq=ornaments%20couperin&pg=PA34#v=onepage&q=ornaments%20couperin&f=false</a></div><div><br></div><div>-Andrew</div><div><br></div><div><div><div>On 2012-03-06, at 7:11 AM, Johannes Kepper wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Andrew, <br><br>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). <br><br>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!!!!). <br><br>Best,<br>Johannes<br><br><br><br><br>Am 06.03.2012 um 01:57 schrieb Andrew Hankinson, Mr:<br><br><blockquote type="cite">Hi Eleanor,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The way I understand the problem is a choice between the following options:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><trill><br></blockquote><blockquote type="cite"><note /><br></blockquote><blockquote type="cite"></trill><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">or:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><note><br></blockquote><blockquote type="cite"><trill /><br></blockquote><blockquote type="cite"></note><br></blockquote><blockquote type="cite"><br></blockquote><br><blockquote type="cite">or:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><note id="123" /><br></blockquote><blockquote type="cite"><trill startid="123" /><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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):<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><measure><br></blockquote><blockquote type="cite"><layer><br></blockquote><blockquote type="cite"> <beam><br></blockquote><blockquote type="cite"> <note id="1" /><br></blockquote><blockquote type="cite"> <note id="2" /><br></blockquote><blockquote type="cite"> <note id="3" /><br></blockquote><blockquote type="cite"> </beam><br></blockquote><blockquote type="cite"></layer><br></blockquote><blockquote type="cite"><layer><br></blockquote><blockquote type="cite"> <beam><br></blockquote><blockquote type="cite"> <chord><br></blockquote><blockquote type="cite"> <note /><br></blockquote><blockquote type="cite"> <note /><br></blockquote><blockquote type="cite"> </chord><br></blockquote><blockquote type="cite"> <chord><br></blockquote><blockquote type="cite"> <note /><br></blockquote><blockquote type="cite"> <note /><br></blockquote><blockquote type="cite"> </chord><br></blockquote><blockquote type="cite"> <chord><br></blockquote><blockquote type="cite"> <note /><br></blockquote><blockquote type="cite"> <note /><br></blockquote><blockquote type="cite"> </chord><br></blockquote><blockquote type="cite"> </beam><br></blockquote><blockquote type="cite"></layer><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><trill startid="2" /><br></blockquote><blockquote type="cite"><turn startid="2" /><br></blockquote><blockquote type="cite"><accid accid="n" startid="2" /><br></blockquote><blockquote type="cite"><slur startid="1" endid="3" /><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"></measure><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Andrew<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 2012-03-05, at 6:03 PM, Eleanor Selfridge-Field wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi, Kristina, Perry, et al.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What is unsettling in the responses is that we are putting hierarchy above music and the needs of encoders.<br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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:<br></blockquote><blockquote type="cite"><image003.jpg><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We used it in our “desk-top publishing IEEE tutorial of 1994. [For all the examples go to <a href="http://www.ccarh.org/publications/reprints/ieee/">http://www.ccarh.org/publications/reprints/ieee/</a> --Category 2, Type 1]<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">How would MEI handle it?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Eleanor<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Eleanor Selfridge-Field<br></blockquote><blockquote type="cite">Consulting Professor, Music<br></blockquote><blockquote type="cite">Braun Music Center #129<br></blockquote><blockquote type="cite">Stanford University<br></blockquote><blockquote type="cite">Stanford, CA 94305-3076, USA<br></blockquote><blockquote type="cite"><a href="http://www.stanford.edu/~esfield/">http://www.stanford.edu/~esfield/</a><br></blockquote><blockquote type="cite"><a href="http://www.ccarh.org">http://www.ccarh.org</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">From: <a href="mailto:mei-l-bounces+esfield=stanford.edu@lists.uni-paderborn.de">mei-l-bounces+esfield=stanford.edu@lists.uni-paderborn.de</a><<a href="mailto:mei-l-bounces+esfield=stanford.edu@lists.uni-paderborn.de">mailto:mei-l-bounces+esfield=stanford.edu@lists.uni-paderborn.de</a>> [mailto:mei-l-bounces+esfield=<a href="mailto:stanford.edu@lists.uni-paderborn.de">stanford.edu@lists.uni-paderborn.de</a><<a href="mailto:stanford.edu@lists.uni-paderborn.de">mailto:stanford.edu@lists.uni-paderborn.de</a>>] On Behalf Of Roland, Perry (pdr4h)<br></blockquote><blockquote type="cite">Sent: Monday, March 05, 2012 5:50 AM<br></blockquote><blockquote type="cite">To: Music Encoding Initiative<br></blockquote><blockquote type="cite">Subject: Re: [MEI-L] trills within beams<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi, Kristina,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">From snowy (yes, snowy!) Charlottesville,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--<br></blockquote><blockquote type="cite">p.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">__________________________<br></blockquote><blockquote type="cite">Perry Roland<br></blockquote><blockquote type="cite">Music Library<br></blockquote><blockquote type="cite">University of Virginia<br></blockquote><blockquote type="cite">P. O. Box 400175<br></blockquote><blockquote type="cite">Charlottesville, VA 22904<br></blockquote><blockquote type="cite">434-982-2702 (w)<br></blockquote><blockquote type="cite">pdr4h (at) virginia (dot) edu<br></blockquote><blockquote type="cite">________________________________<br></blockquote><blockquote type="cite">From: <a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a><<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mailto:mei-l-bounces@lists.uni-paderborn.de</a>> [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a><<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mailto:mei-l-bounces@lists.uni-paderborn.de</a>>] on behalf of Kristina Richts [<a href="mailto:kristina.richts@gmx.de">kristina.richts@gmx.de</a><<a href="mailto:kristina.richts@gmx.de">mailto:kristina.richts@gmx.de</a>>]<br></blockquote><blockquote type="cite">Sent: Monday, March 05, 2012 4:26 AM<br></blockquote><blockquote type="cite">To: Music Encoding Initiative<br></blockquote><blockquote type="cite">Subject: [MEI-L] trills within beams<br></blockquote><blockquote type="cite">Hi all,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> <image001.png><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Why isn't it possible to provide notes within a beam with a <trill> element, as could be done with single notes, like this:<br></blockquote><blockquote type="cite"><trill><note xml:id="m167_s1_e6_A3" pname="b" oct="5" dur="4" stem.dir="down"/></trill>?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Did I miss anything?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Best,<br></blockquote><blockquote type="cite">Kristina<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">mei-l mailing list<br></blockquote><blockquote type="cite"><a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><<a href="mailto:mei-l@lists.uni-paderborn.de">mailto:mei-l@lists.uni-paderborn.de</a>><br></blockquote><blockquote type="cite"><a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">mei-l mailing list<br></blockquote><blockquote type="cite"><a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br></blockquote><blockquote type="cite"><a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br></blockquote><br><br>_______________________________________________<br>mei-l mailing list<br><a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>https://lists.uni-paderborn.de/mailman/listinfo/mei-l<br></div></blockquote></div><br></div></body></html>