[MEI-L] syllable connectors

Roland, Perry D. (pdr4h) pdr4h at eservices.virginia.edu
Wed Jul 9 20:50:37 CEST 2014 

Hi everybody,

I knew that eventually someone would trip over this.  :-)  And that we'd need to fix it.

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.

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 --

"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:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl>wan-</syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

Of course, in the following markup, because a connector is absent the difference is not discernible:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

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:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl con="none">wan</syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

But, to record which connector *should* be present we can use <supplied>:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl>wan<supplied>-</supplied></syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

Or use <gap> to record a missing connector without supplying one:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl>wan<gap reason="missing hyphen"/></syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

Having put the connector *inside* <syl>, @con can be used to record the function of the connector:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl con="separated">wan<supplied>-</supplied></syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

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.  

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:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl>wan-</syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

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:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl con="extended">wan-</syl>
    <syl>ton</syl>
  </verse>
  <verse>
    <syl>wan</syl>
    <syl>ton</syl>
  </verse>
</lyrics>

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.

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":

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl>Dios</syl>
    <syl con="elided">que˘al</syl>   
    <syl>mun-</syl>
    <syl>do</syl>
  </verse>
</lyrics>

But so does this:

<lyrics xmlns="http://www.music-encoding.org/ns/mei">
  <verse>
    <syl>Dios</syl>
    <syl con="elided">que^al</syl
    <syl>mun-</syl>
    <syl>do</syl>
  </verse>
</lyrics>

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

      U+E550
      lyricsElisionNarrow
      Narrow elision

      U+E551
      lyricsElision
      Elision

      U+E552
      lyricsElisionWide
      Wide elision

      U+E553
      lyricsHyphenBaseline
      Baseline hyphen

      U+E554
      lyricsHyphenBaselineNonBreaking
      Non-breaking baseline hyphen

     (See the attached image or http://www.smufl.org/version/latest/range/lyrics/ for visual examples)

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.

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.

--
p.



> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
> Christine Siegert
> Sent: Friday, July 04, 2014 9:58 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] syllable connectors
> 
> Dear Johannes, dear list,
> The Sarti project agrees, too.
> All the best,
> Christine
> 
> 
> Prof. Dr. Christine Siegert
> Universität der Künste Berlin
> Fakultät Musik, Musikwissenschaft
> Fasanenstraße 1B
> D-10623 Berlin
> 
> Tel.: +49 (0)30 3185 2318
> siegert at udk-berlin.de
> -----Ursprüngliche Nachricht-----
> From: Karen McAulay
> Sent: Friday, July 04, 2014 12:16 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] syllable connectors
> 
> Yes!
> 
> Best wishes
> Karen
> 
> Dr. Karen McAulay
> Music and Academic Services Librarian
> +44 (0)141 270 8267 (direct)
> K.McAulay at rcs.ac.uk
> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
> Johannes Kepper
> Sent: 04 July 2014 10:56
> To: Music Encoding Initiative
> Subject: [MEI-L] syllable connectors
> 
> Dear MEI-Listeners,
> 
> doing some manual coding of vocal music, we ran across a situation where
> the
> layout of the printed score did not allow to put in any separator (well,
> better connector) between two syllables of a word. The current list of
> allowed connectors does not have an explicit option of "no connector at
> all". Do we all agree that there should be one?
> 
> Best,
> Johannes
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lyricsRangeSMuFL.png
Type: image/png
Size: 13393 bytes
Desc: lyricsRangeSMuFL.png
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140709/026172a0/attachment.png>

More information about the mei-l mailing list