[MEI-L] syllable connectors

[Craig Sapp]

Hi Perry,

 1. The position of a syllable with a word is handled by syl/@wordpos,
> where the value can be ‘i’, ‘m’, or ‘t’.  There probably should also be a
> value for ‘complete word’ as well, ‘w’ perhaps?
>
>
I think that a 'w' @wordpos value could be useful.  Particularly if
syl/@wordpos is optional. This would distinguish between cases where the
word linking is unknown/undefined and where the syllable is known to be a
complete word.


> 2. There was a typo in the elision example.  It should’ve been --
>
>
>
> <lyrics xmlns="http://www.music-encoding.org/ns/mei">
>
>   <verse>
>
>     <syl>Dios</syl>
>
>     <syl con="elided" >que˘</syl>
>
>     <syl>al</syl>
>
>     <syl>mun-</syl>
>
>     <syl>do</syl>
>
>   </verse>
>
> </lyrics>
>

OK, that makes more sense.  And I would then always expect the last CDATA
character in syl/@con="elided" elements to be the elision character.  There
would be a complication if the elision consisted of more than one character
for some reason...


> 3. Since @n is restricted to a single NMTOKEN, use verse/@label to capture
> multiple verse numbers:
>
>
>
> <lyrics xmlns="http://www.music-encoding.org/ns/mei">
>
>   <verse label="1.,2.,6">
>
>     <syl>Dios</syl>
>
>     <syl con="elided" >que˘</syl>
>
>     <syl>al</syl>
>
>     <syl>mun-</syl>
>
>     <syl>do</syl>
>
>   </verse>
>
> </lyrics>
>

That looks good (and you told me that before :-).  Also, I in rondeaux I
would need verse labels to occur multiple times, since the music is split
into an A section and a B section, so there would be another one at the
start of the B section, such as "3.,4.,5.".  Is that possible/allowable?

Now, for the real “meat”.  We can’t forget that one of the functions of
> MEI, if not the primary one, is to represent existing documents.  The
> reality is that real-world documents are going to contain errors and
> inconsistencies that have to be dealt with.  If MEI could mandate the
> “correct” way of doing things, as SCORE can, for example that divisions
> between syllables are always indicated by either a dash or an underscore,
> then life would be much easier.  What we need, however, is to accommodate
> multiple purposes -- recording what the document says, what it *ought to
> say*, and what it means (when we’re interested in that sort of thing).
>

SCORE definitely does not mandate a correct way of doing things, although
there are more correct and less correct ways of doing things.  For example,
the multiple hyphens case is typically implemented as a single dashed line.
 If you want to simulate a dashed line with unevenly spaced dashes, then
you could either use separate little short lines, or use text hyphens
instead.  But as a programmer trying to parse the lyrics in the SCORE file,
I would be irritated if I see a non-conventional method of displaying
lyrics.

 What other [music] XML representations typically do (and what MEI does in
> some other places) is to record what the document says as the content of
> elements and any necessary annotations of that content as embedded elements
> and/or attributes.  My proposed changes are an attempt to do that with
> <syl>.  In the case of the syllable “que˘” above, the elision marker is “in
> the text” of the document.  I would prefer to leave it there and record the
> fact that this syllable is elided with the next in the @con attribute.
> Sure, the connector can be moved to an attribute, but there are several
> problems with that approach:
>

>
> a. the ability to say anything about the visual aspect of the connector,
> for example that it’s bold, is lost;
>
> b. omissions or errors can’t be explicitly indicated, for example that a
> connector isn’t present but ought to be or is there when it shouldn’t be;
>
> c. it’s difficult (but not impossible) to handle multiple values when, for
> example multiple connectors are present (erroneously or not), as in
> ‘que-˘’.  The rules of SCORE and modern notation aren’t universally
> followed.  J
>

The important thing is that the elision marker be distinguishable from the
linguistic text, so the elision marker can be manipulated independent of
the text, such as to remove or replace it.

Surveying MusicXML's treatment of elision markers:

http://www.finalemusic.com/usermanuals/finale2012win/content/finale/Elisions2.htm


I am having difficulty.  The official method of displaying an elision
marker in Finale is to use capital-I with the EngraverFontSet font as part
of the syllable text.  When exporting MusicXML with such an elision marker
in Finale 2012, the syllable with the elision marker disappears....

Here is the official MusicXML encoding method for elisions:

http://www.finalemusic.com/UserManuals/MusicXML/Content/EL-MusicXML-elision.htm

        <lyric number="1">
          <syllabic>single</syllabic>
          <text>mi</text>
          <elision> </elision>
          <syllabic>begin</syllabic>
          <text>a</text>
        </lyric>

With <lyric> being the text attached to a note, and this lyric containing
two text syllables separated by an elision character.  I like that it is
easy to identify the elision character(s).  The above example is with a
space character as the elision.  Here is the typical elision character,
which unfortunately is not so pretty (as illustrated on the above link for
the <elision> documentation):

        <lyric number="1">
          <syllabic>single</syllabic>
          <text>mi</text>
         <elision font-family="EngraverFontSet,engraved"
font-size="10.25">I</elision>
          <syllabic>begin</syllabic>
          <text>a</text>
        </lyric>

However, when I load this example into Finale 2012, the elision marker is
converted automatically into a space (and when I convert back to MusicXML,
the <lyric> with the elision completely disappears).

Another interesting case: MuseData encodes elisions as spaces in the
syllable text, with "\0+" used to indicate an literal space character.
 This is useful since most lyrics containing spaces will be intended to be
joined by an elision character, which is not usually easy to type.

 In other words, the markup <syl con=”separated”>wan-</syl> contains the
> same data as <syl con=”d”>wan</syl>. The difference is simply where the
> data is.  BUT, as I indicated in the list above, the latter is much more
> restrictive regarding what data can appear.  Unless @con is also allowed to
> contain unrestricted CDATA, it will never be able to accommodate all the
> symbols that have been (or even could be) used to connect syllables.
>

>
> I recognize that you’d like the data to be as regular as possible and so
> want to place the connector(s) in an attribute.  But what would you do with
> (c)?  Splitting the data by putting ‘que’ in <syl> and ‘-˘’ in @con (if
> such a thing were allowed) could still result in “something [going] wrong
> in some obscure case”, whether the splitting is done by a human or by a
> software agent (Mr. OMR).  In my opinion, it’s less dangerous to leave the
> data together in just one place.
>

(c) (que-˘) would be the text "que-" followed by an elision marker, where
the hyphen is part of the text and not a connector or part of the elision:

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

  <verse>

    <syl con="elided">que-˘</syl>

  </verse>
</lyrics>

 I agree with you that putting "wan- - - - - - - - - - -" inside <syl> is
> not likely to be useful for (re-)rendering notation from the markup (and
> should probably be processed to be simply “wan-“), but it does preserve
> information about the original document.
>

If it is part of the prose text, I would allow it in the <syl> CDATA;
otherwise, if it represents standard visual alignment dashes so that the
singer does not sing the incorrect verse line for the next syllable, it is
not directly related to the text "wan", and so should not be so closely
associated with "wan".

 Again, it’s less dangerous (and less work) to just leave it in place than
> to create the markup <syl con=”d”>wan</syl>, especially if you’re not
> interesting in (re-)rendering or reconstructing the text (i.e., prose),
> which might be the case if the creation of the markup is done in stages.
>
>
>
> Under no circumstances is this change (putting the connector in the
> character data of <syl>) meant to take the place of intelligent, dynamic
> rendering using SCORE or any other processor.  For example, even when a
> processor encounters “wan- - - - - - - - - - -" it shouldn’t render this
> literally.  The size and number of dashes, underscores, etc. should be
> automagically calculated.  But this data could be useful to those dealing
> strictly with an image of the notation, and so shouldn’t be discarded.
>

There will need to be a mechanism for a renderer to know that the dashes
should be removed as computers are too stupid to figure that out by
themselves.  The only way I see to allow such constructs is to embed the
dashes in some element:
     wan<something>- - - - - - - - - - -</something>
This might be useful for multi-character elisions as well:
    que<elision>-˘</elision>
which would be different from:
     que-<elision>˘</elision>


-=+Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140710/9c6ff1d9/attachment.html>