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

Wed Mar 8 16:50:07 CET 2017

Comments inline below --

--
p.

> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Anna
> Plaksin
> Sent: Wednesday, March 08, 2017 7:57 AM
> To: 'Music Encoding Initiative'
> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary
> segmentation
> 
> Hi all,
> 
> I was also one of the participants of the discussion on the MEI mensural list
> and very happy to see this topic is getting solved. I'm also sorry for popping
> into this discussion here that late, but I didn't have a computer in reach within
> the last days and feel now a little bit overwhelmed, also my inbox does right
> now.
> On that point, I try to summarize the results and add some of my remarks, I
> wanted to.
> 
> - 1: Lyrics -
> The revision of the content of <lyrics>, which is done in the development
> version as far as is see, uses line groups and lines for the organization; also
> <syl> is allowed within, but not mixing plain text and <syl>. Also, the use of
> @startid, @endid, and @plist should be allowed within <l> and the
> introduction of <seg> for grouping was mentioned.
> Am I right with that?

[PR: ] Yes, the reorganization of <lyrics> is available only within the development version.  The addition of @startid, @endid, and @plist on <l> and the introduction of <seg> within <l> have been proposed, but I don't think there's agreement yet that these changes are the optimal solution.  Once again, I'd prefer that the mensural group propose an alternative to <lyrics> that would appear within <staff> and encode *performed text, the syllables of which are not directly associated with notes*, your "Sub cuius patula coma" for example.  This element is analogous to CMME's <originalText> element.  This element would carry @startid, @endid, @plist and other attributes found on other controlEventLike elements.  Adding it would make a clear distinction between the functions of <l> (for poetic lines) and this element (text visible above/below a staff). 

> I was also one of those persons struggling with the text handling of mensural
> sources and this approach seems very useful to me. There is only one thing, I
> want to ask, just to get a clear idea. <l> is meant to be used for a line of a poem
> or also for a visible line of text below a staff? It would be good to know
> because in the case of my attached example those two different
> understandings of <l> would lead to different encodings. If <l> is meant as a
> poetic line, I could divide each chunk of text with line, and the two lines sung
> on that repeated part of music would be attached to the same part of music:
> <lyrics>
> 	<lg>
> 		<l startid="#nA" endid="#nB">Sub cuius patula coma</l>
> 		<l startid="#nA" endid="#nB">& phebi lira blandius</l>
> 		<l startid="#nC" endid="#nD">& vox blandius insonat</l>
> 		[...]
> 	</lg>
> </lyrics>
> In that case, is it possible to give the information of two underlying lines of
> lyrics below a chunk of music?
> If <l> is meant to represent a visual line of underlying lyrics, the encoding
> would need to look like that, as it seems to me:
> <lyrics>
> 	<lg>
> 		<l n="1">
> 			<seg startid="#nA" endid="#nB">Sub cuius patula
> coma</seg>
> 			<seg startid="#nC" endid="#nD">& vox blandius
> insonat</seg>
> 		</l>
> 		<l n="2">
> 			<seg startid="#nA" endid="#nB">">& phebi lira
> blandius</seg>
> 		</l>
> 	</lg>
> </lyrics>
> In that case, the encoding seems logically very confusing to me, but the visual
> organization of the lyrics is given. So, for giving me a better understanding I
> would welcome a clarification on that issue. And I can also be sure that one of
> my examples is now able to encoded properly.

[PR: ] Indeed, the markup becomes "fuzzy" because there's too much "overloading of the semantics" of <l> going on here.  Better to use different elements for different functions -- <l> for lines of poetry, a new element for mensural notation text strings.  In this new element, one may encode explicit line breaks --

<newElement startid="#n1">Sub cuius patula coma<lb/>& phebi lira blandius</newElement>

to position the 2nd line or break the text across multiple newElements --

<newElement startid="#n1">Sub cuius patula coma</newElement>
<newElement startid="#n1">& phebi lira blandius</newElement>

The usual behavior of Verovio is such that two staff-attached elements like this occurring at the same time (i.e., associated with the same event) will be displayed vertically, one atop the other.  The choice between using a single element or multiple elements is likely to be influenced by how much (visual?) control one needs to have over each chunk of text.

> - 2: control events -
> Also, control events, e.g. <dir>, are meant to be put directly into <staff> and
> not anymore within <layer> in mensural notation?
> But, where should <lyrics> be put in, still within <layer>? I'm just asking
> because in cmn it is also one of those elements to be put directly into
> <measure>.

[PR: ] At present, <lyrics> can occur in <layer> or <staff> in order to accommodate a wider variety of source material.  In other words, I'm not knowledgeable enough about mensural sources to definitively say that a chunk of poetry can never occur in a layer.  It seems unlikely, but I don't know for sure.  Also, allowing <lyrics> in <layer> may provide some processing benefits; that is, a closer association of the poetry and the voice.  This seems unlikely as well.  In both cases, I'm waiting for experts to tell me to take it out.  :-)  The opposite approach is also valid -- leave it out until the experts say it needs to be there.  I'm open to either method.

> - 3: non-sung text -
> I also want to come back on the topic of non-sung text. Unlike Don I'm not
> thinking about visible annotations by the encoder, instead I'm thinking about
> text directives within the source itself. My second example is in my opinion a
> problematic one because I'm not sure how to solve I right now.
> Because it is meant as the directive, that the Tenor voice should keep silent, I
> would encode it as "<dir>Tenor Laurus tacet.</dir>".
> My problem is, that <dir> needs to have a pointing attribute to be valid. In cmn
> I would use @tstamp="0" to point at the left barline, but within mensural
> music only @startid and @endid are valid pointing attributes. But on what
> should I point in that case? While I try to explain the problem, my only idea
> would be like that:
> <staff>
> 	<layer>
> 		<space xml:id="space-0" />
> 		[...]
> 	</layer>
> 	<dir startid="#space-0" endid="#space-0">Tenor Laurus tacet.</dir>
> </staff> Is that solution appropriate? I would welcome any comments and
> suggestions.

[PR: ] <space> represents *time-filling space*, similar to push codes in DARMS.  Its typical use is to fill the time preceding material that doesn't begin at the start of a measure, for instance, in pianistic writing where a "voice" suddenly materializes out of thin air in the middle of a measure.  Here, <pad> is more appropriate.  It encodes *visual space*.  It has no duration, its extent expressed only in virtual units (where half the distance between staff lines equals one vu).  So, I'd amend your encoding to be --

<staff>
  <layer>
    <pad xml:id="pad0" n="10"/>
  <layer>
  <dir startid="#pad0">Tenor Laurus tacet.</dir>
</staff>

As far as I know, however, Verovio doesn't yet do anything with <pad> elements.

> Again, I have to apologize for answering that late and arguing about things
> which seemed to be solved already. It seems to me, that discussion was spread
> on a lot of places, MEI mensural list, github and Verovio, and about a lot of
> related issues, what makes me feeling in need of a clear summarization.
> Another short question: When are the changes already made in the
> development version planned to be released in a stable version?

[PR: ] This discussion has indeed spread over many forums.  At this point, the best place to follow discussion of a technical nature is in the Github repositories for MEI and Verovio.  The release date for v. 4.0 is not yet determined.  My original plan was to make it around the time of the conference in Tours, but now I think it's best to delay it until the end of the year.  This will give us time to 
  - consider broader changes, esp. those necessary for mensural and neume notation, 
  - tackle small but important issues related to CMN display,
  - plan and begin to implement MEI Go!, and 
  -handle other administrative stuff (conferences, workshops, web site updates, etc.).

> Best wishes,
> Anna
> 
> -----Ursprüngliche Nachricht-----
> Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von
> Roland, Perry D. (pdr4h)
> Gesendet: Dienstag, 7. März 2017 23:01
> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
> Betreff: Re: [MEI-L] Annotations visible on the music and arbitrary
> segmentation
> 
> 
> I've just been looking at some music with (mostly) Western notation and
> Arabic lyrics.  I don't know if it's typical, but the song at
> http://www.classicalarabicmusic.com/Added%20Music%20Notations/Popular
> %20Traditional%20-1/asl_elgharam.html provides the notation first, followed
> by the lyrics.  This is precisely the situation that the lyrics/lg/l construct was
> designed for.  Association of each syllable with the note that it starts on via
> @synch is sufficient for rendition of the lyrics and notation together.
> 
> --
> p.
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l