<div dir="ltr">Hi Perry,<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><<</span><span style="font-family:arial,sans-serif;font-size:13px">But now I believe it would be better to use @con to record the *function* of the connector and put the lyric transcription/visual rendition *inside* the syllable element itself as is done in many other places in MEI.</span><span style="font-family:arial,sans-serif;font-size:13px"> >></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><< Repetitions of a connector, "wan - - - - - - - - - - -" for example, would be allowed inside <syl> so that no data is lost (well, except for the location of each dash), but could be compressed to a single dash for presentation purposes.>></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">I am not too keen on placing the visual aspect of the lyrics text inside of <syl> CDATA since it is mixing the underlying prose content with its graphical presentation in the music. The <syl> character data should only contain the prose of the text. If the text extracted from the music should include "- - - -" after the word "wan", then it should be in the <syl> character data; otherwise, it should not.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">For text extraction from lyrics, I would want to know if the <syl> data is at the start, middle or end of word, so that I can extract the data segmented by words instead of syllables by adding spaces or not between the <syl> character data (primarily for searching purposes, but also for displaying as regular prose/verse). It would be preferable if I do not have to delete any characters from the <syl> data when reconstructing the prose, since something will go wrong in some obscure case.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">When two syllables of a word are separated by a long distance between two notes in a graphical score, multiple dashes are used. If they layout of music changes, then the single/multiple dash display should change (automatically). Hard-encoding of single/double dashes distinction is not very useful for manipulation of the layout unless you are intent on encoding the static layout of a specific edition.</font></div>
<div><br></div><div><span style="font-family:arial,sans-serif">As an aside: I often come across the reverse case when two syllables are too close to comfortably be separated by a hyphen, the hyphen should be dropped and the two syllables should be displayed as a single word. I do not know any notation editor which handles this case, and I have to do it manually when necessary (attaching the word to a single note, and leaving the next note without a syllable).</span><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif">SCORE always uses a dashed line between two syllables, and multiple dashes appear automatically as the line is extended.</span></div>
<div><span style="font-family:arial,sans-serif">The number, size and distance between the dashes is controllable on this line. In other words SCORE does not use a character-encoding of a hyphen to display the word separators. The same goes for word extenders which are not literally a sequence of underscores. </span><br>
</div><div><br></div><div><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif;font-size:13px"><<The text inside <syl> can be processed (using regular expression matching) to create any output needed, for example, the text "as-is" with hyphenated words (e.g., "wan-ton a-ban-don") or "joined-up" in a more poetic style (e.g., "wanton abandon"). >></span><font face="arial, sans-serif"><br>
</font></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">This is how the Humdrum representation for lyrics works. In general it works well, but there are complications. In particular when there is a hyphen between two syllables in prose, you need a way of indicating that it should remain. I don't come across that much in lyrics, but I would encode the word "long-term" as two syllables:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">"long--" and "-term", with the double hyphen indicating that when the lyrics are extracted from the music, the final prose should include a hyphen between those two syllables. Such a system should be spelled out. This system works well in 7-bit ASCII data, but I wonder if someone uses a strange or inconsistent unicode hyphen characters, what will happen? Also, this would not be great if graphic-like display is used, for example "wan - - - - - - - - - - " could be compensated for in a regular expression, but only after discovering that someone was doing such a thing in the data, and would make the regular expression quite complicated for removing the extended hyphen.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Another complication when extracting text prose, is how am I to detect an elision character in the CDATA as you have pointed out so many of them occur in unicode? :-) This seems to make a case for a functional elision tag which contains a optional attribute for how it should be rendered as character(s) for separating two syllables.</span></div>
<div><br></div><div><br></div><div>I don't understand this encoding which you can explain more:</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><lyrics xmlns="</span><a href="http://www.music-encoding.org/ns/mei" target="_blank" style="font-family:arial,sans-serif;font-size:13px">http://www.music-encoding.org/ns/mei</a><span style="font-family:arial,sans-serif;font-size:13px">"></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> <verse></span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> <syl>Dios</syl></span><br style="font-family:arial,sans-serif;font-size:13px">
<font color="#9900ff"><span style="font-family:arial,sans-serif;font-size:13px"> <syl con="elided">que˘al</syl></span><br style="font-family:arial,sans-serif;font-size:13px"></font><span style="font-family:arial,sans-serif;font-size:13px"> <syl>mun-</syl></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> <syl>do</syl></span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> </verse></span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"></lyrics></span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I would expect that the syl@con attribute describes how the current syllable connects to the following syllable, not an internal connector:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><lyrics xmlns="</span><a href="http://www.music-encoding.org/ns/mei" target="_blank" style="font-size:13px;font-family:arial,sans-serif">http://www.music-encoding.org/ns/mei</a><span style="font-size:13px;font-family:arial,sans-serif">"></span><br style="font-size:13px;font-family:arial,sans-serif">
<span style="font-size:13px;font-family:arial,sans-serif"> <verse></span><br style="font-size:13px;font-family:arial,sans-serif"><span style="font-size:13px;font-family:arial,sans-serif"> <syl>Dios</syl></span></div>
<div><font color="#9900ff"> <syl con="elided">que</syl><br style="font-size:13px;font-family:arial,sans-serif"><span style="font-size:13px;font-family:arial,sans-serif"> <syl>al</syl></span></font><br style="font-size:13px;font-family:arial,sans-serif">
<span style="font-size:13px;font-family:arial,sans-serif"> <syl>mun-</syl></span><br style="font-size:13px;font-family:arial,sans-serif"><span style="font-size:13px;font-family:arial,sans-serif"> <syl>do</syl></span><br style="font-size:13px;font-family:arial,sans-serif">
<span style="font-size:13px;font-family:arial,sans-serif"> </verse></span><br style="font-size:13px;font-family:arial,sans-serif"><span style="font-size:13px;font-family:arial,sans-serif"></lyrics></span><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">Also remember a few months ago we were having problems on representing verse numbers (in rondeaux), such as , "1.,2.,6" for indicating that the line of music is for the 1st, 2nd and 6th verses. How should this be encoded. In most musical editors, this has to be treated as regular text with a space elision before the first syllable in the lyrics.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><br></div><div>-=+Craig</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 9 July 2014 11:50, Roland, Perry D. (pdr4h) <span dir="ltr"><<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi everybody,<br>
<br>
I knew that eventually someone would trip over this. :-) And that we'd need to fix it.<br>
<br>
This is another one of those places where the original purpose/form of MEI conflicts with later developments. One of the original purposes of syl/@con was to allow a hand-encoder to mark the *function* of a syllable connector just by indicating just what they saw -- if the score contained a dash, the encoder would write <syl con="d"> and so on. Another was to make it easier to convert existing representations into MEI. For me, however, the main point was to get at the function of the individual syllable.<br>
<br>
But now I believe it would be better to use @con to record the *function* of the connector and put the lyric transcription/visual rendition *inside* the syllable element itself as is done in many other places in MEI. Consider for a moment --<br>
<br>
"wan", "ton", and "wanton" are all English words. The difference between the word "wan" followed by the word "ton" and the single word "wanton" divided syllabically is all in the connectors between the syllables. For example:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl>wan-</syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
Of course, in the following markup, because a connector is absent the difference is not discernible:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
But, if we allow @con to have a value of "none", we're really no better off because we still don't know which visual connector *ought* to be present or what its (supposed) purpose is. The following is still semantically indistinguishable from the preceding example because the orthography of the word "wan" and that of the first syllable of "wanton" (without its hyphen) are the same thing:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl con="none">wan</syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
But, to record which connector *should* be present we can use <supplied>:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl>wan<supplied>-</supplied></syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
Or use <gap> to record a missing connector without supplying one:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl>wan<gap reason="missing hyphen"/></syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
Having put the connector *inside* <syl>, @con can be used to record the function of the connector:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl con="separated">wan<supplied>-</supplied></syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
Actually, I think I prefer @con to record info *about the syllable* since it's an attribute *of* the syllable. The new values for @con (or for a new attribute if we want to keep @con around but deprecate it) could be "separated", "extended", "elided", and "unknown". But I could be persuaded otherwise.<br>
<br>
This also works in the (hopefully) more usual case when the connector is present but our favorite naïve encoder (Mr. OMR) can't (or doesn't want to) determine the function of the connector:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl>wan-</syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
It would be better to have this info, of course, because depending on the rhythm of the vocal line and the prevailing notational style, a dash can be used for both separation and extension. For example, when the first syllable is to be sung on multiple notes the markup could be:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl con="extended">wan-</syl><br>
<syl>ton</syl><br>
</verse><br>
<verse><br>
<syl>wan</syl><br>
<syl>ton</syl><br>
</verse><br>
</lyrics><br>
<br>
In fact, there could be (and often are) multiple dashes filling the space between the first and last notes of the melisma or just one depending on the source document or on the rendering processor (when the MEI is to be rendered). The same thing occurs with the underscore separator.<br>
<br>
But this kind of many-visual-representations-to-one-function situation is particularly acute when it comes to elision. Various symbols have been used to indicate syllable elision -- breve, inverted breve, caron, circumflex, and tilde just to name a few. The following example indicates an elision of "que" and "al":<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl>Dios</syl><br>
<syl con="elided">que˘al</syl><br>
<syl>mun-</syl><br>
<syl>do</syl><br>
</verse><br>
</lyrics><br>
<br>
But so does this:<br>
<br>
<lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<verse><br>
<syl>Dios</syl><br>
<syl con="elided">que^al</syl<br>
<syl>mun-</syl><br>
<syl>do</syl><br>
</verse><br>
</lyrics><br>
<br>
One could encounter any number of visual renditions indicating elision. And one should be able to use any appropriate Unicode or SMuFL code point for the connector. SMuFL provides<br>
<br>
U+E550<br>
lyricsElisionNarrow<br>
Narrow elision<br>
<br>
U+E551<br>
lyricsElision<br>
Elision<br>
<br>
U+E552<br>
lyricsElisionWide<br>
Wide elision<br>
<br>
U+E553<br>
lyricsHyphenBaseline<br>
Baseline hyphen<br>
<br>
U+E554<br>
lyricsHyphenBaselineNonBreaking<br>
Non-breaking baseline hyphen<br>
<br>
(See the attached image or <a href="http://www.smufl.org/version/latest/range/lyrics/" target="_blank">http://www.smufl.org/version/latest/range/lyrics/</a> for visual examples)<br>
<br>
The text inside <syl> can be processed (using regular expression matching) to create any output needed, for example, the text "as-is" with hyphenated words (e.g., "wan-ton a-ban-don") or "joined-up" in a more poetic style (e.g., "wanton abandon"). Repetitions of a connector, "wan - - - - - - - - - - -" for example, would be allowed inside <syl> so that no data is lost (well, except for the location of each dash), but could be compressed to a single dash for presentation purposes.<br>
<br>
I believe this will work better than the old system (it's clearer, no info is lost), but I'd like to hear other viewpoints.<br>
<br>
--<br>
p.<br>
<div class="im HOEnZb"><br>
<br>
<br>
> -----Original Message-----<br>
> From: mei-l [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] On Behalf Of<br>
</div><div class="HOEnZb"><div class="h5">> Christine Siegert<br>
> Sent: Friday, July 04, 2014 9:58 AM<br>
> To: Music Encoding Initiative<br>
> Subject: Re: [MEI-L] syllable connectors<br>
><br>
> Dear Johannes, dear list,<br>
> The Sarti project agrees, too.<br>
> All the best,<br>
> Christine<br>
><br>
><br>
> Prof. Dr. Christine Siegert<br>
> Universität der Künste Berlin<br>
> Fakultät Musik, Musikwissenschaft<br>
> Fasanenstraße 1B<br>
> D-10623 Berlin<br>
><br>
> Tel.: <a href="tel:%2B49%20%280%2930%203185%202318" value="+493031852318">+49 (0)30 3185 2318</a><br>
> <a href="mailto:siegert@udk-berlin.de">siegert@udk-berlin.de</a><br>
> -----Ursprüngliche Nachricht-----<br>
> From: Karen McAulay<br>
> Sent: Friday, July 04, 2014 12:16 PM<br>
> To: Music Encoding Initiative<br>
> Subject: Re: [MEI-L] syllable connectors<br>
><br>
> Yes!<br>
><br>
> Best wishes<br>
> Karen<br>
><br>
> Dr. Karen McAulay<br>
> Music and Academic Services Librarian<br>
> <a href="tel:%2B44%20%280%29141%20270%208267" value="+441412708267">+44 (0)141 270 8267</a> (direct)<br>
> <a href="mailto:K.McAulay@rcs.ac.uk">K.McAulay@rcs.ac.uk</a><br>
> -----Original Message-----<br>
> From: mei-l [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] On Behalf Of<br>
> Johannes Kepper<br>
> Sent: 04 July 2014 10:56<br>
> To: Music Encoding Initiative<br>
> Subject: [MEI-L] syllable connectors<br>
><br>
> Dear MEI-Listeners,<br>
><br>
> doing some manual coding of vocal music, we ran across a situation where<br>
> the<br>
> layout of the printed score did not allow to put in any separator (well,<br>
> better connector) between two syllables of a word. The current list of<br>
> allowed connectors does not have an explicit option of "no connector at<br>
> all". Do we all agree that there should be one?<br>
><br>
> Best,<br>
> Johannes<br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div></div><br>_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br></blockquote></div><br></div>