[MEI-L] Annotations visible on the music and arbitrary segmentation

Mon Mar 6 15:59:13 CET 2017

If temporal alignment is the objective, then @corresp is not specific enough.  Better to use @synch.  The fact that these attributes are missing from <lg> and <l> is remediable. :-)  @startid/@endid can also be added to <l>, as Daniel suggested, or to another still more specific element, to indicate starting and ending points for a text string.

--
p.

> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
> Andrew Hankinson
> Sent: Monday, March 06, 2017 6:51 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary
> segmentation
> 
> If you’re talking about *visually* spacing the lyrics given an unknown
> association with the notes, then this is not an MEI problem, as far as I can see.
> This would need to be down to a particularly clever renderer, or some other
> means of computationally deriving syllable-note relationships.
> 
> It really comes down to whether or not you are asserting or estimating. If you
> are asserting a relationship, you would put it in MEI. If you are estimating a
> relationship, based on informed guesses, it’s probably best to leave that to an
> interpretive layer that sits above the encoding, and only assert the things that
> you know.
> 
> Just a quick glance through the elements lyrics, lg, and l, it seems that the
> `@corresp` attribute might be the best solution. This is already available on
> lyrics, but not on lg or l.
> 
> I could imagine something like:
> 
> <lyrics>
>   <lg corresp=“#measure 5” OR corresp=“#n1 #n2 #nn…”>
>      <l corresp=“#nX”> … </l>
>   </lg>
> </lyrics>
> 
> -Andrew
> 
> > On 6 Mar 2017, at 07:57, Daniel Alles <DanielAlles at stud.uni-frankfurt.de>
> wrote:
> >
> > Dear all,
> >
> > I think one of the problems (at least one of my problems while encoding MN)
> is the spacing of the lyrics. It is not always clear, which syllable belongs where,
> so a connection of syllables to notes is not always given. The possibility to
> encode the lyrics separately and then attach them to a staff seems unlikely too,
> as the syllables would be spaced according to the rhythm off the staff (the
> lyrics would only appear at the beginning of the staff, as there normally are
> more notes then syllables).
> >
> > A possibility to connect not only syllables but also whole phrases of text to
> phrases of notes would be really nice; something like "this text starts on that
> note and ends on that note". As it is not clear in all the cases how the
> underlayed text is to be sung and therefore a spacing of the lyrics would be an
> editorial intervention, a solution like @startid and @endid (or something else)
> would at least represent the source material the best.
> >
> > Best,
> > Daniel
> >
> >
> >
> >
> > Zitat von Andrew Hankinson <andrew.hankinson at mail.mcgill.ca>:
> >
> >> Could someone boil down the decisions that need to be made, even just in
> point form, for those of us who haven't been part of the discussion?
> >>
> >> I'm afraid I don't quite understand what we're supposed to be commenting
> on.
> >>
> >> -Andrew
> >>
> >>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> Text underlay doesn't have anything to do with <dir> or <annot>.
> >>>
> >>> I apologize for the confusion created by the definition of <verse> -- it was
> too short and too cryptic.  In the version of MEI currently under development,
> verse is defined as "Division of a poem or song lyrics; a stanza."
> >>>
> >>> The verse/syl construct is only applicable at the note level.  For musical
> material which is repeated, but with different words/lyrics/sung text, <verse>
> provides a method of recording which words belong with each repetition.
> >>>
> >>> <note>
> >>>  <verse n="1">
> >>>    <syl>Ooh</syl>
> >>>  </verse>
> >>>  <verse n="2">
> >>>    <syl>Ah</syl>
> >>>  </verse>
> >>> </note>
> >>>
> >>> For text not directly associated with individual notes, lyrics/lg should be
> used instead.  <lyrics> occurs outside the stream of notated events; that is,
> inside <measure> and <syllable>, although not within <staff> or <layer> as
> might be required for mensural notation.  I'll correct this oversight soon.  The
> <lg> element is, of course, borrowed from TEI.
> >>>
> >>> For those situations where the sung text is visually separate from
> >>> the musical material, one can use --
> >>>
> >>> <lyrics>
> >>>  <lg>
> >>>    <l>Oh, say can you see</l>
> >>>  </lg>
> >>> </lyrics>
> >>>
> >>> To associate each syllable of these words with the notes, one can
> >>> add <syl> elements --
> >>>
> >>> <lyrics>
> >>>  <lg>
> >>>    <l>
> >>>      <syl synch="#n1">Oh,</syl>
> >>>      <syl synch="#n2">say</syl>
> >>>      <syl synch="#n3">can</syl>
> >>>      <syl synch="#n4">>you</syl>
> >>>      <syl synch="#n5">see</syl>
> >>>  </lg>
> >>> </lyrics>
> >>>
> >>> One may object to calling the text of a 15th century motet "lyrics", but the
> same markup applies.
> >>>
> >>> --
> >>> p.
> >>>
> >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf
> >>> Of Giuliano Di Bacco
> >>> Sent: Saturday, March 04, 2017 6:28 AM
> >>> To: Byrd, Donald A.; Music Encoding Initiative
> >>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary
> >>> segmentation
> >>>
> >>> Thanks, Don:
> >>>
> >>> I swear that I am not trying to complicate the issue further, but I should
> recall that it was another moving part of the mechanism that originated this
> discussions on MEI-Mens, that is, <verse>. That is, also arbitrary
> segmentation/alignment of... non-arbitrary text (!) deserves attention:
> >>>
> >>> 1 - about its use, as regard to the issue described by Don: how best to
> record arbitrary (I prefer: "non standard") placement of text underlay
> (alignment of chunks of text in <verse> with <note>s), when not possible/easy
> to do it with <syl>.
> >>>
> >>> 2- about its definition. This may be slightly off-topic, but important:
> discussion on MEI-Mens reveals that there may be some confusion about what
> <verse> is supposed to be used for. The specifications say that this is for "lyric
> verse". Period. First, I am not sure whether "verse" has to be intended as "a
> body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single
> line of a metrical writing" -- definitions in major Brit+American dictionaries (and
> people's opinions) fluctuate between these poles.  Second, I am not sure
> whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic,
> didactic poetry) or generically for "the words of a song". Admittedly, in
> romance languages both terms are less ambiguous than in English, so I suppose
> that we just need to clarify, through a more generous description, if <verse> is
> "whatever poetic text underlay" (my best guess) or what. It would be very
> useful to clarify this point while we talk about "text". The next step would be
> to decide if we need/want to represent poetical structures of lower (or higher)
> order (it would seem logical to me if we borrowed stuff from TEI), and how to
> distinguish text underlay proper from text-that-goes-with-these-notes but not-
> laid-under-the-notes, that is, written/printed somewhere else in the page
> (introducing some tag/att like "underlay" and "displaced" perhaps). But this is
> really off-topic (premature) for now.
> >>>
> >>> As usual, please don't hesitate to correct me if I
> misunderstood/misrepresented anything -- it would be helpful.
> >>>
> >>> Best,
> >>>
> >>> Giuliano
> >>>
> >>>
> >>>
> >>> Byrd, Donald A. wrote on 04/03/2017 01:36:
> >>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig,
> >>> Perry and I, plus other members of the mensural IG -- have been
> >>> discussing the need for annotations with arbitrary text that are
> >>> displayed on the music. Unfortunately, the discussion so far has
> >>> been scattered among several places, including the mensural IG
> >>> mailing list and Verovio GitHub issues #248 ("Directives in mensural
> >>> notation aren't drawn"), 388 ("@n for <harm>"), and especially 389
> >>> ("implement <annot> display"). You can read #389 at
> >>>
> >>>   https://github.com/rism-ch/verovio/issues/389
> >>> <https://github.com/rism-ch/verovio/issues/389>
> >>>
> >>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the
> issues here.
> >>>
> >>> We've talked about using one of two existing tags for these annotations,
> namely <dir> and <annot>. It seems clear that <dir> is not what we want
> because it's specifically intended for performance directions. As for <annot>s,
> of course they are currently only for annotating the encoding, not the music,
> and they're not displayed in the SVG. We could add a @visible attribute to
> <annot>, but the problem then is _where_ on the music should they appear?
> But it seems to me this is only a serious problem if you expect the notation
> engine to position everything automatically, and that's something that I think
> is completely unrealistic for complex music regardless of annotation. I suggest
> visible <annot>s should have a crudely-calculated default position, and it'd be
> up to the user to specify a different position if they want.
> >>>
> >>> Giuliano has raised a related concern. He wrote yesterday that
> >>>
> >>> "[N]ot only something like <dir> for arbitrary non-lyric text is needed, but
> also some arbitrary segmentation, to encapsulate portions of music and/or
> lyric/non-lyric text where things happen (such as, lyric text loosely connected
> with a portion of music, or passages where the mensuration is uncertain...).
> >>>
> >>> "If I understand correctly, most of the problem with <dir>  originates from
> the missing <measure> level in the hierarchy (at least this creates problems
> with Verovio), so I was wondering whether the introduction of a tag
> <segment> at that level could be useful. The latter, contrary to <measure>
> would be totally optional, and contrary to <measure> or <section> would be
> used without any structural meaning.
> >>>
> >>> "This is the point where we felt the need that the discussion escalates on
> MEI-L.  Non-structural segmentation is something that TEI introduced lately in
> their schema (they call it <seg> when the portion of text is shorter than a
> paragraph, and <ab> when an 'anonymous block' of text is found that escapes
> from the paragraph structure). In my experience this is one of the most useful
> features when dealing with complex documents, and in past projects I used it
> also to provide annotations. I wonder whether there are any reasons for not
> having a <seg>-like tag available at any level."
> >>>
> >>> Giuliano's ideas make sense to me, but I don't feel very well qualified to
> evaluate them.
> >>>
> >>> I'm looking forward to hearing people's thoughts on all of this!
> >>>
> >>> --Don
> >>>
> >>>
> >>> ---
> >>> Donald Byrd
> >>> Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor
> >>> of Informatics Visiting Scientist, Research Technologies Indiana
> >>> University Bloomington
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> mei-l mailing list
> >>> mei-l at lists.uni-paderborn.de
> >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> >
> >
> >
> <lyrics_confusion.PNG>_____________________________________________
> __
> > 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