[MEI-L] trills within beams

[Raffaele Viglianti]

+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120306/5f13f821/attachment.html>