[MEI-L] trills within beams

Roland, Perry (pdr4h) pdr4h at eservices.virginia.edu
Tue Mar 6 17:48:44 CET 2012 

Slow down, take it easy, remain calm.  I said I could imagine a future without them, but I didn't mean in the next 5 minutes.  :)

These features are very convenient for hand-encoders.  They have been frequently requested in the past and, in fact, this thread started with a request for just such a feature.

These features also make it somewhat easier to more-directly capture data from other systems that allow/encourage this kind of thing.

So, I would urge caution at this point.  Anyone who doesn't want to use these "conveniences" shouldn't feel compelled to do so.  But I don't think that I want to rush to remove them.  I think we should be thinking about canonicalization instead.

--
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 TW [zupftom at googlemail.com]
Sent: Tuesday, March 06, 2012 11:36 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] trills within beams

I'm also in favor of deprecating [i|m|t][1-6].

Thomas


2012/3/6 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> +1 to deprecation
>
> Raffaele
>
>
> On Tue, Mar 6, 2012 at 4:22 PM, Johannes Kepper <kepper at edirom.de> wrote:
>>
>> if this turns out to be a way to get rid of the [i|m|t][1-6] datatype, I'm
>> more than happy :-)
>>
>> (do we need to cover that in the guidelines, or can't we just deprecate it
>> now?) (that's also a rhetorical question)
>>
>>
>> Am 06.03.2012 um 17:18 schrieb Roland, Perry (pdr4h):
>>
>> >
>> > @tie, @slur, and such, were put in as conveniences for the hand encoder.
>> >  The question is: When does a plethora of conveniences become inconvenient?
>> >  Where the line gets drawn may be arbitrary, but a line needs to be drawn
>> > nonetheless.
>> >
>> > I can certainly imagine the attributes you cite being deprecated over
>> > time. Or at least ignored when encoding software (like a GUI editor) is
>> > used.  I can also imagine them being converted to the element form by a
>> > canonizer, like MEIron.
>> >
>> > If attributes such as these are conveniences that will probably be
>> > ignored or deprecated in the future, why add more like them now?  (That's a
>> > rhetorical question.)
>> >
>> > --
>> > 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 Johannes Kepper
>> > [kepper at edirom.de]
>> > Sent: Tuesday, March 06, 2012 11:06 AM
>> > To: Music Encoding Initiative
>> > Subject: Re: [MEI-L] trills within beams
>> >
>> > I see the point, but in this case, shouldn't we consider to deprecate
>> > @tie, @slur and similar constructs? The arguments you provide below apply to
>> > them as well…
>> >
>> > devil's advocate Johannes
>> >
>> >
>> > Am 06.03.2012 um 16:57 schrieb Roland, Perry (pdr4h):
>> >
>> >> 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
>> >> _______________________________________________
>> >> 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
>> > _______________________________________________
>> > 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
>
>
>
> _______________________________________________
> 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

More information about the mei-l mailing list