<div dir="ltr">Hi Don,<div><br></div><div>I was indeed not very convinced by the use of <dir> within <layer>, but this not an issue anymore since we can have them within <staff> now (See <a href="https://github.com/music-encoding/music-encoding/issues/329">https://github.com/music-encoding/music-encoding/issues/329</a>) as Perry just suggested.</div><div><br></div><div>Laurent</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 7, 2017 at 1:25 AM, Byrd, Donald A. <span dir="ltr"><<a href="mailto:donbyrd@indiana.edu" target="_blank">donbyrd@indiana.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mar 6, 2017, at 5:50 PM, "Roland, Perry D. (pdr4h)" <<a href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>><br>
<span class=""> wrote:<br>
> Don,<br>
><br>
> There's no reason to abuse verse/syl to attach non-sung text to a note.  Abuse <dir> instead.  :-)<br>
<br>
</span>I'd be (reasonably) happy to do that, but <dir> doesn't work on mensural notation; as Laurent put it, "There is.. an issue with <dir> in mensural mode." By "mensural mode", I assume he means on staves with notation.type mensural, but I'm not sure. And he says making it work within <layer> will be really tricky.  Laurent?<br>
<span class=""><br>
> Or better yet, suggest a new element for holding such text.<br>
<br>
</span>I just suggested an old element -- <annot> -- with a new attribute -- @visible -- and I thought you thought that was a good idea! No?<br>
<br>
--DAB<br>
<div><div class="h5"><br>
<br>
> Using @tstamp on <dir> to make the association is appropriate for CMN but not for mensural notation, so use @startid.  The <dir> element doesn't have to go inside <note> or <layer>.  Since there's only one note with the xml:id of "n1", <dir> can be placed anywhere in the field, although inside <staff> is probably the best location --<br>
><br>
> <staff n="1" label="feature-example"><br>
>  <layer n="1"><br>
>    <note pname="c" dur="maxima" oct="4" xml:id="n1"> </note><br>
>    <note pname="b" dur="longa" oct="3"/><br>
>    <note pname="c" dur="brevis" oct="4"/><br>
>    <note pname="b" dur="semibrevis" oct="3"/><br>
>    <note pname="c" dur="minima" oct="4"/><br>
>    <note pname="d" dur="semiminima" oct="4"/><br>
>    <note pname="g" dur="fusa" oct="3"/><br>
>    <rest dur="semifusa"/><br>
>    <barLine/><br>
>    <note xml:id="note-67" pname="b" dur="longa" oct="3"/><br>
>    <dot form="div"/><br>
>    <note pname="b" dur="brevis" oct="3"/><br>
>    <dot form="div"/><br>
>    <note pname="b" dur="semibrevis" oct="3"/><br>
>    <dot form="div"/><br>
>    <note pname="b" dur="minima" oct="3"/><br>
>    <dot form="div"/><br>
>    <note pname="b" dur="semiminima" oct="3"/><br>
>    <barLine/><br>
>    <note pname="c" dur="maxima" oct="4" colored="true" xml:id="n2"/><br>
>    <note pname="b" dur="longa" oct="3" colored="true"/><br>
>    <note pname="c" dur="brevis" oct="4" colored="true"/><br>
>    <note pname="b" dur="semibrevis" oct="3" colored="true"/><br>
>    <note pname="c" dur="minima" oct="4" colored="true"/><br>
>    <note pname="d" dur="semiminima" oct="4" colored="true"/><br>
>    <note pname="g" dur="fusa" oct="3" colored="true"/><br>
>    <rest dur="semifusa" xml:id="r1"/><br>
>  </layer><br>
>  <dir startid="#n1" place="above">black</dir><br>
>  <dir startid="#n2" place="above">colored</dir><br>
>  <dir startid="#r1" place="above">testing</dir><br>
> </staff><br>
><br>
> --<br>
> p.<br>
><br>
>> -----Original Message-----<br>
>> From: mei-l [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.<wbr>uni-paderborn.de</a>] On Behalf Of Byrd,<br>
>> Donald A.<br>
>> Sent: Monday, March 06, 2017 4:44 PM<br>
>> To: Music Encoding Initiative<br>
>> Subject: Re: [MEI-L] Annotations visible on the music...<br>
>><br>
>> My original message mentioned two related issues: as the subject line said,<br>
>> "annotations visible on the music and arbitrary segmentation". But the<br>
>> discussion here has focused almost entirely on the latter, so let me say more<br>
>> about the annotations issue.<br>
>><br>
>> My personal interest in this has nothing to do with the "arbitrary ([or] 'non<br>
>> standard') placement of text underlay (alignment of chunks of text in <verse><br>
>> with <note>s)" that Giuliano and Daniel have been talking about. I've attached<br>
>> the MEI file and corresponding SVG (from my experimental version of Verovio;<br>
>> you won't get this from anything public!) that brought the issue up for me in<br>
>> the first place. Of course, this isn't real music, just my test file. But I simply<br>
>> wanted to put labels on the music to say what type of mensural notation --<br>
>> black, black colored, white, or white colored -- each part of the example<br>
>> showed, and, to my surprise, I couldn't find anything better than <syl> to do it<br>
>> with. NB that I ran this with the "--even-note-spacing" argument, so the wide<br>
>> spacing after the maximas has nothing to do with their duration; it's just<br>
>> because Verovio understandably thought the <syl>s were lyrics, requiring their<br>
>> own space before the next note.<br>
>><br>
>> I actually think this is a pretty simple question. As I said when I started this<br>
>> thread, <annot>s "are currently only for annotating the encoding, not the<br>
>> music, and they're not displayed in the SVG. We could add a @visible attribute<br>
>> to <annot>, but the problem then is _where_ on the music should they<br>
>> appear? But it seems to me this is only a serious problem if you expect the<br>
>> notation engine to position everything automatically, and I think expecting<br>
>> good results from that is completely unrealistic for complex music regardless of<br>
>> annotation. I suggest visible <annot>s should have a crudely-calculated default<br>
>> position, and it'd be up to the user to specify a different position if they want."<br>
>> I think Perry agreed in one of his recent messages, though I can't find it now.<br>
>> While the attached example is what led _me_ to think about this, it was Craig<br>
>> who opened Issue #389, where much of the previous discussion occurred. He<br>
>> suggested visible <annot> "would function in a very similar manner to the<br>
>> current <harm> implementation, but both should add horizontal collision<br>
>> avoidance between adjacent <annot> and <harm> entries (similar to the<br>
>> current implementation of <verse>."  But there was much more discussion on<br>
>> the Issue #389 page ( (<a href="https://github.com/rism-ch/verovio/issues/389" rel="noreferrer" target="_blank">https://github.com/rism-ch/<wbr>verovio/issues/389</a>), which I<br>
>> won't try to summarize here. I strongly recommend that anyone interested<br>
>> read that.<br>
>><br>
>> --DAB<br>
>><br>
>><br>
>>> Zitat von Andrew Hankinson <<a href="mailto:andrew.hankinson@mail.mcgill.ca">andrew.hankinson@mail.mcgill.<wbr>ca</a>>:<br>
>>><br>
>>>> Could someone boil down the decisions that need to be made, even just in<br>
>> point form, for those of us who haven't been part of the discussion?<br>
>>>><br>
>>>> I'm afraid I don't quite understand what we're supposed to be commenting<br>
>> on.<br>
>>>><br>
>>>> -Andrew<br>
>>>><br>
>>>>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h)<br>
>> <<a href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>> wrote:<br>
>>>>><br>
>>>>> Hi,<br>
>>>>><br>
>>>>> Text underlay doesn't have anything to do with <dir> or <annot>.<br>
>>>>><br>
>>>>> I apologize for the confusion created by the definition of <verse> -- it was<br>
>> too short and too cryptic.  In the version of MEI currently under development,<br>
>> verse is defined as "Division of a poem or song lyrics; a stanza."<br>
>>>>><br>
>>>>> The verse/syl construct is only applicable at the note level.  For musical<br>
>> material which is repeated, but with different words/lyrics/sung text, <verse><br>
>> provides a method of recording which words belong with each repetition.<br>
>>>>><br>
>>>>> <note><br>
>>>>> <verse n="1"><br>
>>>>>   <syl>Ooh</syl><br>
>>>>> </verse><br>
>>>>> <verse n="2"><br>
>>>>>   <syl>Ah</syl><br>
>>>>> </verse><br>
>>>>> </note><br>
>>>>><br>
>>>>> For text not directly associated with individual notes, lyrics/lg should be<br>
>> used instead.  <lyrics> occurs outside the stream of notated events; that is,<br>
>> inside <measure> and <syllable>, although not within <staff> or <layer> as<br>
>> might be required for mensural notation.  I'll correct this oversight soon.  The<br>
>> <lg> element is, of course, borrowed from TEI.<br>
>>>>><br>
>>>>> For those situations where the sung text is visually separate from<br>
>>>>> the musical material, one can use --<br>
>>>>><br>
>>>>> <lyrics><br>
>>>>> <lg><br>
>>>>>   <l>Oh, say can you see</l><br>
>>>>> </lg><br>
>>>>> </lyrics><br>
>>>>><br>
>>>>> To associate each syllable of these words with the notes, one can<br>
>>>>> add <syl> elements --<br>
>>>>><br>
>>>>> <lyrics><br>
>>>>> <lg><br>
>>>>>   <l><br>
>>>>>     <syl synch="#n1">Oh,</syl><br>
>>>>>     <syl synch="#n2">say</syl><br>
>>>>>     <syl synch="#n3">can</syl><br>
>>>>>     <syl synch="#n4">>you</syl><br>
>>>>>     <syl synch="#n5">see</syl><br>
>>>>> </lg><br>
>>>>> </lyrics><br>
>>>>><br>
>>>>> One may object to calling the text of a 15th century motet "lyrics", but the<br>
>> same markup applies.<br>
>>>>><br>
>>>>> --<br>
>>>>> p.<br>
>>>>><br>
>>>>> From: mei-l [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.<wbr>uni-paderborn.de</a>] On Behalf<br>
>>>>> Of Giuliano Di Bacco<br>
>>>>> Sent: Saturday, March 04, 2017 6:28 AM<br>
>>>>> To: Byrd, Donald A.; Music Encoding Initiative<br>
>>>>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary<br>
>>>>> segmentation<br>
>>>>><br>
>>>>> Thanks, Don:<br>
>>>>><br>
>>>>> I swear that I am not trying to complicate the issue further, but I should<br>
>> recall that it was another moving part of the mechanism that originated this<br>
>> discussions on MEI-Mens, that is, <verse>. That is, also arbitrary<br>
>> segmentation/alignment of... non-arbitrary text (!) deserves attention:<br>
>>>>><br>
>>>>> 1 - about its use, as regard to the issue described by Don: how best to<br>
>> record arbitrary (I prefer: "non standard") placement of text underlay<br>
>> (alignment of chunks of text in <verse> with <note>s), when not possible/easy<br>
>> to do it with <syl>.<br>
>>>>><br>
>>>>> 2- about its definition. This may be slightly off-topic, but important:<br>
>> discussion on MEI-Mens reveals that there may be some confusion about what<br>
>> <verse> is supposed to be used for. The specifications say that this is for "lyric<br>
>> verse". Period. First, I am not sure whether "verse" has to be intended as "a<br>
>> body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single<br>
>> line of a metrical writing" -- definitions in major Brit+American dictionaries (and<br>
>> people's opinions) fluctuate between these poles.  Second, I am not sure<br>
>> whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic,<br>
>> didactic poetry) or generically for "the words of a song". Admittedly, in<br>
>> romance languages both terms are less ambiguous than in English, so I suppose<br>
>> that we just need to clarify, through a more generous description, if <verse> is<br>
>> "whatever poetic text underlay" (my best guess) or what. It would be very<br>
>> useful to clarify this point while we talk about "text". The next step would be<br>
>> to decide if we need/want to represent poetical structures of lower (or higher)<br>
>> order (it would seem logical to me if we borrowed stuff from TEI), and how to<br>
>> distinguish text underlay proper from text-that-goes-with-these-<wbr>notes but not-<br>
>> laid-under-the-notes, that is, written/printed somewhere else in the page<br>
>> (introducing some tag/att like "underlay" and "displaced" perhaps). But this is<br>
>> really off-topic (premature) for now.<br>
>>>>><br>
>>>>> As usual, please don't hesitate to correct me if I<br>
>> misunderstood/misrepresented anything -- it would be helpful.<br>
>>>>><br>
>>>>> Best,<br>
>>>>><br>
>>>>> Giuliano<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Byrd, Donald A. wrote on 04/03/2017 01:36:<br>
>>>>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig,<br>
>>>>> Perry and I, plus other members of the mensural IG -- have been<br>
>>>>> discussing the need for annotations with arbitrary text that are<br>
>>>>> displayed on the music. Unfortunately, the discussion so far has<br>
>>>>> been scattered among several places, including the mensural IG<br>
>>>>> mailing list and Verovio GitHub issues #248 ("Directives in mensural<br>
>>>>> notation aren't drawn"), 388 ("@n for <harm>"), and especially 389<br>
>>>>> ("implement <annot> display"). You can read #389 at<br>
>>>>><br>
>>>>>  <a href="https://github.com/rism-ch/verovio/issues/389" rel="noreferrer" target="_blank">https://github.com/rism-ch/<wbr>verovio/issues/389</a><br>
>>>>> <<a href="https://github.com/rism-ch/verovio/issues/389" rel="noreferrer" target="_blank">https://github.com/rism-ch/<wbr>verovio/issues/389</a>><br>
>>>>><br>
>>>>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the<br>
>> issues here.<br>
>>>>><br>
>>>>> We've talked about using one of two existing tags for these annotations,<br>
>> namely <dir> and <annot>. It seems clear that <dir> is not what we want<br>
>> because it's specifically intended for performance directions. As for <annot>s,<br>
>> of course they are currently only for annotating the encoding, not the music,<br>
>> and they're not displayed in the SVG. We could add a @visible attribute to<br>
>> <annot>, but the problem then is _where_ on the music should they appear?<br>
>> But it seems to me this is only a serious problem if you expect the notation<br>
>> engine to position everything automatically, and that's something that I think<br>
>> is completely unrealistic for complex music regardless of annotation. I suggest<br>
>> visible <annot>s should have a crudely-calculated default position, and it'd be<br>
>> up to the user to specify a different position if they want.<br>
>>>>><br>
>>>>> Giuliano has raised a related concern. He wrote yesterday that<br>
>>>>><br>
>>>>> "[N]ot only something like <dir> for arbitrary non-lyric text is needed, but<br>
>> also some arbitrary segmentation, to encapsulate portions of music and/or<br>
>> lyric/non-lyric text where things happen (such as, lyric text loosely connected<br>
>> with a portion of music, or passages where the mensuration is uncertain...).<br>
>>>>><br>
>>>>> "If I understand correctly, most of the problem with <dir>  originates from<br>
>> the missing <measure> level in the hierarchy (at least this creates problems<br>
>> with Verovio), so I was wondering whether the introduction of a tag<br>
>> <segment> at that level could be useful. The latter, contrary to <measure><br>
>> would be totally optional, and contrary to <measure> or <section> would be<br>
>> used without any structural meaning.<br>
>>>>><br>
>>>>> "This is the point where we felt the need that the discussion escalates on<br>
>> MEI-L.  Non-structural segmentation is something that TEI introduced lately in<br>
>> their schema (they call it <seg> when the portion of text is shorter than a<br>
>> paragraph, and <ab> when an 'anonymous block' of text is found that escapes<br>
>> from the paragraph structure). In my experience this is one of the most useful<br>
>> features when dealing with complex documents, and in past projects I used it<br>
>> also to provide annotations. I wonder whether there are any reasons for not<br>
>> having a <seg>-like tag available at any level."<br>
>>>>><br>
>>>>> Giuliano's ideas make sense to me, but I don't feel very well qualified to<br>
>> evaluate them.<br>
>>>>><br>
>>>>> I'm looking forward to hearing people's thoughts on all of this!<br>
>>>>><br>
>>>>> --Don<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
><br>
</div></div>> <AllMensuralDurs.mei>_________<wbr>______________________________<wbr>________<br>
<span class="">> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" rel="noreferrer" target="_blank">https://lists.uni-paderborn.<wbr>de/mailman/listinfo/mei-l</a><br>
<br>
---<br>
Donald Byrd<br>
Woodrow Wilson Indiana Teaching Fellow<br>
Adjunct Associate Professor of Informatics<br>
Visiting Scientist, Research Technologies<br>
Indiana University Bloomington<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</span>______________________________<wbr>_________________<br>
<div class="HOEnZb"><div class="h5">mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" rel="noreferrer" target="_blank">https://lists.uni-paderborn.<wbr>de/mailman/listinfo/mei-l</a><br>
</div></div></blockquote></div><br></div>