[MEI-L] Annotations visible on the music and arbitrary segmentation

[Daniel Alles]

Maybe I understand it wrong, but I have a problem with @synch: Does it  
only give me a starting-point for the text? Wouldn't then the text be  
associated to only one note and not to the whole line it is written  
under? That was why I suggested @startid AND @endid (or something  
similar), which would (in my imagination) span a widely spread word  
wider in the layout, if necessary, just like it does with slurs.

Daniel



Zitat von "Roland, Perry D. (pdr4h)" <pdr4h at eservices.virginia.edu>:

> The approach Giuliano suggests may work for single-staff notation,  
> but it won't work for music on multiple staves because the segment  
> boundary would have to be the same for all staves.  Unless the total  
> duration of the segment is the same in all layers of all the staves  
> (which is likely not to be the case because of the polyphonic style  
> with which mensural notation is usually associated), then the  
> following won't work --
>
> <segment>
>   <staff>
>     <layer>
>       <note/>
>     </layer>
>     <layer>
>       <note/>
>       <note/>
>       <note/>
>     </layer>
>   </staff>
>   <staff>
>     <layer>
>       <note/>
>       <note/>
>     </layer>
>   </staff>
>   <lyrics></lyrics>
> </segment>
>
> Also, in the case of multiple staves, to which staff are the lyrics  
> to be attached?
>
> Even if <segment> were used lower in the hierarchy, say at the layer level --
>
> <staff>
>   <layer>
>     <segment>
>       <note/>
>       <note/>
>       <note/>
>     </segment>
>   </layer>
> </staff>
> <staff>
>   <layer>
>     <segment>
>       <note/>
>       <note/>
>       <note/>
>     </segment>
>   </layer>
> </staff>
>
> the same problem would persist.
>
> The only possibility left is to forego segmentation other than that  
> of <staff> and <layer> and associate text directly with events via  
> @synch --
>
> <staff>
>   <layer>
>     <note xml:id="n1"/>
>     <note/>
>     <note/>
>   </layer>
> </staff>
> <staff>
>   <layer>
>     <note/>
>     <note/>
>     <note/>
>   </layer>
>   <lyrics>
>     <lg>
>       <l><syl synch="#n1">Hmmm?</syl></l>
>     </lg>
>   </lyrics>
> </staff>
>
> This method works regardless of where the <lyrics> element is  
> actually placed, be it inside <layer>, <staff>, or elsewhere.  It  
> can be extended to <l> if necessary --
>
> <l synch="#n1">Hmm? Say what?</l>
>
> In case you're wondering why @synch and not @startid -- I know it's  
> somewhat arbitrary, but @startid is reserved for musical events  
> (like <slur>, <hairpin>, and such) that are attached to other  
> musical events, while @synch (borrowed from TEI) is used on elements  
> that may or may not be musical events (<l>, <p>, <name>).  If a new  
> element for performed text that was always a musical event were  
> created, then it would use @startid instead of @synch.
>
>> I am not sure what the remark about "@align" means at the bottom of  
>> http://music-encoding.org/documentation/3.0.0/syl/  -- do we have  
>> such attribute on syl?
>
> That's an error which has been fixed in the development version.
>
> --
> p.
>
>
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf  
> Of Giuliano Di Bacco
> Sent: Monday, March 06, 2017 6:17 AM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary  
> segmentation
>
>
> Daniel Alles wrote on 06/03/2017 08:57:
> "this text starts on that note and ends on that note".
> This is where I saw the *possibility* to do also the reverse, giving  
> priority to the music: Something like
> <segment>
>  <staff>
>   <layer>
>    <note/>
>    <note/>
>    <note/>
>   </layer>
>  </staff>
>  <lyrics>
>   <verse>exultavit</verse>
>  </lyrics>
> </segment>
>
> which would mean "this chunk of music here has a chunk of text  
> under-laid to it".
>
> Perry: I know that directions and lyrics are two different things.  
> What I meant to say is that both things can share the nature of  
> being a chunk of text to be aligned with a chunk of music.
>
> Daniel: of course your idea of using pointers is good as well. But I  
> though that to identify an "arbitrary" chunk of music may be also  
> useful.
>
> And this is just an idea, probably there are a hundred reasons why  
> this may be wrong. Let me clarify that it sprang to my mind because  
> of something Don mentioned, that the absence of <measure> in the  
> hierarchy makes it difficult for Verovio to process textual stuff in  
> the mensural module. Note above that <segment> is where <measure>  
> would be in CMN. But I may have misinterpreted his words!
>
> One may say that this is relevant to the effort of reproducing the  
> source as closely as possible, when ultimately we are supposed to  
> interpret where the scribe wanted us to sing each syllable. I also  
> believe this, but I see some good value in encoding the original,  
> especially if one cannot show the image. So I suppose that I need to  
> make one step forward and try to get both the diplomatic and the  
> interpretive edition:
>
> <segment>
> ...
>  <verse>
>   <choice>
>    <orig>exultavit</orig>
>    <reg><syl align="#">ex</syl><syl>ul</syl><syl>ta</syl><syl>vit</syl></reg>
>   </choice>
>  </verse>
> ...
> </segment>
>
> Here I would use a pointer on <syl> to reconnect syllables with the  
> <note>s they belong.  [I am not sure what the remark about "@align"  
> means at the bottom of  
> http://music-encoding.org/documentation/3.0.0/syl/  -- do we have  
> such attribute on syl?]
>
> All in all, I am sure there are better methods to do this -- but I  
> wanted to explain what my words quoted in Don's first message implied.
>
> Giuliano
>
>
>
> Daniel Alles wrote on 06/03/2017 08:57:
> 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><mailto: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><mailto: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><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<mailto: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<mailto:mei-l at lists.uni-paderborn.de>
>
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l