[MEI-L] Annotations visible on the music...
Roland, Perry D. (pdr4h)
pdr4h at eservices.virginia.edu
Mon Mar 6 23:50:25 CET 2017
Don,
There's no reason to abuse verse/syl to attach non-sung text to a note. Abuse <dir> instead. :-) Or better yet, suggest a new element for holding such text.
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 --
<staff n="1" label="feature-example">
<layer n="1">
<note pname="c" dur="maxima" oct="4" xml:id="n1"> </note>
<note pname="b" dur="longa" oct="3"/>
<note pname="c" dur="brevis" oct="4"/>
<note pname="b" dur="semibrevis" oct="3"/>
<note pname="c" dur="minima" oct="4"/>
<note pname="d" dur="semiminima" oct="4"/>
<note pname="g" dur="fusa" oct="3"/>
<rest dur="semifusa"/>
<barLine/>
<note xml:id="note-67" pname="b" dur="longa" oct="3"/>
<dot form="div"/>
<note pname="b" dur="brevis" oct="3"/>
<dot form="div"/>
<note pname="b" dur="semibrevis" oct="3"/>
<dot form="div"/>
<note pname="b" dur="minima" oct="3"/>
<dot form="div"/>
<note pname="b" dur="semiminima" oct="3"/>
<barLine/>
<note pname="c" dur="maxima" oct="4" colored="true" xml:id="n2"/>
<note pname="b" dur="longa" oct="3" colored="true"/>
<note pname="c" dur="brevis" oct="4" colored="true"/>
<note pname="b" dur="semibrevis" oct="3" colored="true"/>
<note pname="c" dur="minima" oct="4" colored="true"/>
<note pname="d" dur="semiminima" oct="4" colored="true"/>
<note pname="g" dur="fusa" oct="3" colored="true"/>
<rest dur="semifusa" xml:id="r1"/>
</layer>
<dir startid="#n1" place="above">black</dir>
<dir startid="#n2" place="above">colored</dir>
<dir startid="#r1" place="above">testing</dir>
</staff>
--
p.
> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd,
> Donald A.
> Sent: Monday, March 06, 2017 4:44 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Annotations visible on the music...
>
> 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: 5045 bytes
Desc: AllMensuralDurs.mei
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170306/d140bac9/attachment.obj>
More information about the mei-l
mailing list