[MEI-L] Annotations visible on the music...
Byrd, Donald A.
donbyrd at indiana.edu
Tue Mar 7 01:25:33 CET 2017
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
More information about the mei-l
mailing list