[MEI-L] Annotations visible on the music and arbitrary segmentation
Eleanor Selfridge-Field
esfield at stanford.edu
Tue Mar 7 02:08:58 CET 2017
Hi, All,
Sorry: this message flew away mid-sentence. Here is the complete version:
This topic has so many ramifications that I think it might be worth an ad hoc meeting in Tours to catalog its known aspects. It would be a reasonable goal to try to accommodate any arrangement that is currently supported by existing digital approaches. Otherwise we lose the possibility of interchange with them.
To mention a few examples:
(1) CMME (cmme.org) has a toggle for "cluster" text, synchronized with the music in whatever way it is presented in the source (Attachment);
(2) The one case I know of in which EsAC (Essen associative code) hit an impasse was in arranging Polish lyrics to monophonic folksongs. EsAC assumes a note:lyrics ratio in which multiple syllables never have to be set to one note, but this need is common to other repertories including liturgical music. I workaround was devised but it was not transportable.
In the polyphonic context, we have done some typesetting here (typically with SCORE) where multilingual versions of lyrics are given in Roman and non-Roman alphabets, and also with lyrics that exist in current and earlier versions of an alphabet.
The most interesting question on encoding we have run across in this realm came from a German musicologist who wanted to recreate Turkish versions of Calvinist hymns. This brought up the problem of integrating conventional notation (left to right) with textual traditions read right-to-left. (This kind of thing was printable in the analog age but takes a lot of planning in the digital one.) This is outside the scope of MEI at present, but in a listing of situations that could occur in the future, it is worth a thought.
Best regards,
Eleanor
-----Original Message-----
From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h)
Sent: Monday, March 06, 2017 8:05 AM
To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation
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
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmme-cluster.PNG
Type: image/png
Size: 35195 bytes
Desc: cmme-cluster.PNG
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170307/0bae3554/attachment.png>
More information about the mei-l
mailing list