[MEI-L] Annotations visible on the music and arbitrary segmentation
Roland, Perry D. (pdr4h)
pdr4h at eservices.virginia.edu
Mon Mar 6 23:53:08 CET 2017
Hi Daniel,
Yes, @synch only provides a *point of synchronization*. But rather than add @startid and @endid on text elements borrowed from TEI, I'd rather the mensural group came up with a new MEI element that can express these semantics.
--
p.
> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Daniel
> Alles
> Sent: Monday, March 06, 2017 4:40 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary
> segmentation
>
> 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
>
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list