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

Mon Mar 6 17:04:30 CET 2017

You're right, @corresp can be used instead of @synch for generic "correspondence".  But, if the goal is to render the text, then it should be associated with the notes in a more specific way.

--
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 10:11 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary
> segmentation
> 
> I was thinking more semantic alignment, but maybe that’s what you were
> thinking of by ‘temporal’ alignment.
> 
> I was trying to answer Daniel’s use case where “these lyrics belong to these
> notes with no specific information on which lyric belongs to which note”
> would “correspond” but not necessarily “synchronise”. That is, there is no
> specific time information (‘chronos’ in ’synchronise') but there *is* a
> relationship between them.
> 
> The specific case I was imagining was where a tune and lyrics were given
> separately, with multiple possible realisations of the alignment. Rather than
> making the statement that a given lyric is in sync with a tune, it would be best
> to just say that these lyrics ‘belong’ to this group of notes / measure /
> whatever.
> 
> -Andrew
> 
> > On 6 Mar 2017, at 14:59, Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu> wrote:
> >
> >
> > 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
> > _______________________________________________
> > 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