[MEI-L] Combining alternate lyrics with digital scores in the field [was: Re: Annotations visible on the music and arbitrary segmentation]

Jim DeLaHunt from.mei-l at jdlh.com
Mon Mar 6 18:28:52 CET 2017 

I'm not competent to debate the details of representing lyrics in MEI, 
but I would like to highlight this use case Andrew mentions:

On 2017-03-06 07:09, Andrew Hankinson wrote:
 > The specific case I was imagining was where a tune and lyrics were 
given separately...

I have a similar use case, and I would love for MEI to be able to handle 
it. It goes like this:

  * Verdi writes an opera, with a libretto in Italian, and specifies
    which words go with which notes.
  * An engraver from Ricordi expresses Verdi's notes and words and
    alignment as printed notation.
  * Over a century later, one person ("Alice") transcribes the printed
    notation, including words aligned with notes, into MEI form. She
    posts this digital score on a web page, with a free-use licence.
  * Another person ("Bob") translates the libretto of Verdi's opera into
    singable Thai, and specifies which words go with which notes. Bob
    posts this information in some MEI-related format on a web page,
    with a free-use licence.
  * A third person ("Carol", a singer), will be performing the Verdi
    opera in Thai. She downloads both Alice's digital score and Bob's
    Thai translation. She wants to make a digital score which includes
    Bob's Thai words aligned with the notes in Alice's score, and drops
    the Italian libretto.
  * A fourth person ("David") doesn't like Alice's transcription, so
    makes an MEI transcription of the same Verdi opera from a different
    printed edition. It has different staff and page breaks than does
    Alice's score. David also downloads Bob's Thai translation. David
    also wants to make a digital score which includes Bob's Thai words
    aligned with the notes in David's score.

One of my aspirations for MEI is that it have all the technical features 
needed to make this use case practical. I would like to see a way for a 
translator to make an alternate set of lyrics which is packaged separate 
from the score, and can be combined with a score. This packaging is to 
succeed regardless of the page layout the score happens to embody. In 
fact, it should be possible to revise the layout of the score, and have 
the alternate lyrics follow along. It's fine if something like a 
notation editor is required to combine alternate lyrics and digital 
score, but the operation should be automatic. It should not require 
hand-editing by the end user.

Do I understand from this conversation that this is not yet possible in 
MEI?  That is, we have not yet worked out how a separate package of 
lyrics should relate to notes in a layout-independent way?

Thank you,
        --Jim DeLaHunt, Keyboard Philharmonic project, 
http://KeyboardPhilharmonic.org

On 2017-03-06 07:09, Andrew Hankinson wrote:
> 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

-- 
     --Jim DeLaHunt, jdlh at jdlh.com     http://blog.jdlh.com/ (http://jdlh.com/)
       multilingual websites consultant

       157-2906 West Broadway, Vancouver BC V6K 2G8, Canada
          Canada mobile +1-604-376-8953

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170306/6eda8868/attachment.html>

More information about the mei-l mailing list