[MEI-L] Annotations visible on the music...
Laurent Pugin
lxpugin at gmail.com
Tue Mar 7 14:28:26 CET 2017
Hi Don,
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
https://github.com/music-encoding/music-encoding/issues/329) as Perry just
suggested.
Laurent
On Tue, Mar 7, 2017 at 1:25 AM, Byrd, Donald A. <donbyrd at indiana.edu> wrote:
> On Mar 6, 2017, at 5:50 PM, "Roland, Perry D. (pdr4h)" <
> pdr4h at eservices.virginia.edu>
> wrote:
> > Don,
> >
> > There's no reason to abuse verse/syl to attach non-sung text to a note.
> Abuse <dir> instead. :-)
>
> 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?
>
> > Or better yet, suggest a new element for holding such text.
>
> I just suggested an old element -- <annot> -- with a new attribute --
> @visible -- and I thought you thought that was a good idea! No?
>
> --DAB
>
>
> > 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> > <AllMensuralDurs.mei>_______________________________________________
> > 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
>
>
>
>
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170307/7ec97e02/attachment.html>
More information about the mei-l
mailing list