<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I'm not competent to debate the details of representing lyrics in
MEI, but I would like to highlight this use case Andrew mentions:</p>
<div class="moz-cite-prefix">On 2017-03-06 07:09, Andrew Hankinson
wrote:<br>
> The specific case I was imagining was where a tune and lyrics
were given separately...</div>
<p>I have a similar use case, and I would love for MEI to be able to
handle it. It goes like this:</p>
<ul>
<li>Verdi writes an opera, with a libretto in Italian, and
specifies which words go with which notes.</li>
<li>An engraver from Ricordi expresses Verdi's notes and words and
alignment as printed notation.</li>
<li>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.<br>
</li>
<li>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.</li>
<li>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. <br>
</li>
<li>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. </li>
</ul>
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.<br>
<p>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?<br>
</p>
Thank you,<br>
--Jim DeLaHunt, Keyboard Philharmonic project, <a
href="http://KeyboardPhilharmonic.org">http://KeyboardPhilharmonic.org</a><br>
<br>
<div class="moz-cite-prefix">On 2017-03-06 07:09, Andrew Hankinson
wrote:<br>
</div>
<blockquote
cite="mid:728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca"
type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">On 6 Mar 2017, at 14:59, Roland, Perry D. (pdr4h) <a class="moz-txt-link-rfc2396E" href="mailto:pdr4h@eservices.virginia.edu"><pdr4h@eservices.virginia.edu></a> 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.
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: mei-l [<a class="moz-txt-link-freetext" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mailto:mei-l-bounces@lists.uni-paderborn.de</a>] 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
</pre>
<blockquote type="cite">
<pre wrap="">On 6 Mar 2017, at 07:57, Daniel Alles <a class="moz-txt-link-rfc2396E" href="mailto:DanielAlles@stud.uni-frankfurt.de"><DanielAlles@stud.uni-frankfurt.de></a>
</pre>
</blockquote>
<pre wrap="">wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Dear all,
I think one of the problems (at least one of my problems while encoding MN)
</pre>
</blockquote>
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">
A possibility to connect not only syllables but also whole phrases of text to
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">
Best,
Daniel
Zitat von Andrew Hankinson <a class="moz-txt-link-rfc2396E" href="mailto:andrew.hankinson@mail.mcgill.ca"><andrew.hankinson@mail.mcgill.ca></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Could someone boil down the decisions that need to be made, even just in
</pre>
</blockquote>
</blockquote>
<pre wrap="">point form, for those of us who haven't been part of the discussion?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
I'm afraid I don't quite understand what we're supposed to be commenting
</pre>
</blockquote>
</blockquote>
<pre wrap="">on.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
-Andrew
</pre>
<blockquote type="cite">
<pre wrap="">On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h)
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:pdr4h@eservices.virginia.edu"><pdr4h@eservices.virginia.edu></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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."
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
The verse/syl construct is only applicable at the note level. For musical
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">material which is repeated, but with different words/lyrics/sung text, <verse>
provides a method of recording which words belong with each repetition.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
<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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">same markup applies.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
--
p.
From: mei-l [<a class="moz-txt-link-freetext" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mailto:mei-l-bounces@lists.uni-paderborn.de</a>] 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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
1 - about its use, as regard to the issue described by Don: how best to
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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>.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
2- about its definition. This may be slightly off-topic, but important:
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
As usual, please don't hesitate to correct me if I
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">misunderstood/misrepresented anything -- it would be helpful.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
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
<a class="moz-txt-link-freetext" href="https://github.com/rism-ch/verovio/issues/389">https://github.com/rism-ch/verovio/issues/389</a>
<a class="moz-txt-link-rfc2396E" href="https://github.com/rism-ch/verovio/issues/389"><https://github.com/rism-ch/verovio/issues/389></a>
and similarly for the other Verovio issues. Anyway, I'll try to summarize the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">issues here.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
We've talked about using one of two existing tags for these annotations,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
Giuliano has raised a related concern. He wrote yesterday that
"[N]ot only something like <dir> for arbitrary non-lyric text is needed, but
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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...).
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
"If I understand correctly, most of the problem with <dir> originates from
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
"This is the point where we felt the need that the discussion escalates on
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">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."
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
Giuliano's ideas make sense to me, but I don't feel very well qualified to
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">evaluate them.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><lyrics_confusion.PNG>_____________________________________________
__
</pre>
<blockquote type="cite">
<pre wrap="">mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
--Jim DeLaHunt, <a class="moz-txt-link-abbreviated" href="mailto:jdlh@jdlh.com">jdlh@jdlh.com</a> <a class="moz-txt-link-freetext" href="http://blog.jdlh.com/">http://blog.jdlh.com/</a> (<a class="moz-txt-link-freetext" href="http://jdlh.com/">http://jdlh.com/</a>)
multilingual websites consultant
157-2906 West Broadway, Vancouver BC V6K 2G8, Canada
Canada mobile +1-604-376-8953
</pre>
</body>
</html>