[MEI-L] Annotations visible on the music...

[Byrd, Donald A.]

My original message mentioned two related issues: as the subject line said, "annotations visible on the music and arbitrary segmentation". But the discussion here has focused almost entirely on the latter, so let me say more about the annotations issue.

My personal interest in this has nothing to do with the "arbitrary ([or] 'non standard') placement of text underlay (alignment of chunks of text in <verse> with <note>s)" that Giuliano and Daniel have been talking about. I've attached the MEI file and corresponding SVG (from my experimental version of Verovio; you won't get this from anything public!) that brought the issue up for me in the first place. Of course, this isn't real music, just my test file. But I simply wanted to put labels on the music to say what type of mensural notation -- black, black colored, white, or white colored -- each part of the example showed, and, to my surprise, I couldn't find anything better than <syl> to do it with. NB that I ran this with the "--even-note-spacing" argument, so the wide spacing after the maximas has nothing to do with their duration; it's just because Verovio understandably thought the <syl>s were lyrics, requiring their own space before the next note.

I actually think this is a pretty simple question. As I said when I started this thread, <annot>s "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 I think expecting good results from that 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." I think Perry agreed in one of his recent messages, though I can't find it now. While the attached example is what led _me_ to think about this, it was Craig who opened Issue #389, where much of the previous discussion occurred. He suggested visible <annot> "would function in a very similar manner to the current <harm> implementation, but both should add horizontal collision avoidance between adjacent <annot> and <harm> entries (similar to the current implementation of <verse>."  But there was much more discussion on the Issue #389 page ( (https://github.com/rism-ch/verovio/issues/389), which I won't try to summarize here. I strongly recommend that anyone interested read that.

--DAB


> 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
>>> 
>>> 
>>> 
>>> 
> 
> 
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

---
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington





-------------- next part --------------
A non-text attachment was scrubbed...
Name: AllMensuralDurs.mei
Type: application/octet-stream
Size: 6080 bytes
Desc: AllMensuralDurs.mei
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170306/3eb41c04/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AllMensuralDurs.svg
Type: image/svg+xml
Size: 18561 bytes
Desc: AllMensuralDurs.svg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170306/3eb41c04/attachment.svg>