[MEI-L] Encoding Square Notation

[Andrew Hankinson, Mr]

I completely missed your earlier mention of the use of the note elements! Sorry about that. It may be that I was confusing a lot of my terminology, so I'll attempt to be clearer.

I think I'm happy with your ideas about the episema element. Using a @startid and @endid makes sense.

I put together a few examples using your suggestion of the <ineume> element as a substitute for the <note> to see if it made sense. Where I ran into the most problem was in trying to describe a neume like a "climacus" with this encoding. (A climacus is a virga, followed by a number of diamond-head puncta [1] all as unconnected shapes) This is almost always referred to as a single neume, but it is made with a couple strokes of a pen and is thus an unconnected neume.

A typical climacus might be:

<ineume name="climacus"> //note: NO pitch indication, since it is a group of sub-neumes
  <ineume pname="b" oct="3" />
  <ineume pname="a" oct="3" /> // a "punctum inclinatum" is a punctum as a diamond instead of a square
  <ineume pname="g" oct="3" />
</ineume>

My worry here would be that we would be "overloading" the <ineume> element. Since an <ineume> can refer to a group of notes as well as a single note, it does not necessarily have a pitch, but using the same element for both pitched notes and unpitched groups of notes doesn't seem very clear. At this point, it may be clearer to keep the <note> element, since that assumes no need to be connected or disconnected - it just names a pitch value within a i/uneume group.

In other words, I don't know that I would go so far as to throw the <note> element out of this module. Since this is pitched repertoire, there will usually need to be some indication of a pitch value for the component parts of a neume. The sources I checked (the introduction to the Liber and Apel's notation book) refer to the component parts of a neume or a ligature as a note, so I think it's still a very clear indication of what is meant. It also doesn't preclude any transcription into modern notation, since the pitch information would be the same in either case.

In fact, I really like your suggestion about breaking out any modern transcription of staffless neumes [2] into a rdg element, since it is an interpretation of the symbols written over text syllables. That would solve some of the ambiguity. I wouldn't go so far as to do that for actual pitched neume notation, though, since the pitch isn't just an interpretation of the notes, it's a part of the notation itself (just the same as it is for CMN notes).

The only place this becomes a little awkward is in the use of a single neume, like a "punctum" or a "virga." In that case, your suggestion of using <ineume> with pitch information would be:

<ineume name="virga" pname="c" oct="4" />

Whereas the other way is a little more verbose:

<ineume name="virga">
  <note pname="c" oct="4" />
</ineume>

I'll have to do some more reading and thinking about the ligature option. I usually think of a ligature to mean a connected set of symbols, whereas a neume can be a neume without necessarily having its component parts connected.


-Andrew


[1] I've uploaded the introduction to the liber as a PDF. You can get it at http://coltrane.music.mcgill.ca/square_notation/liber_introduction.pdf. The different neumes that I've been referring to are on page 3 of that document. You can also download the entire Liber at http://www.sanctamissa.org/en/music/gregorian-chant/choir/liber-usualis-1961.html, if you're so interested.

[2] In researching this e-mail I stumbled across this in Apel (p.208): "Neumes are called cheironomic (staffless, in campo aperto) if their writing gives no clear indication of pitch; otherwise they are called diastematic or heighted."




On 2010-06-21, at 3:00 PM, Roland, Perry (pdr4h) wrote:

> Andrew,
>
> I think we need to clear up some confusion over notes versus neumes.  As I said before, so far note elements have been allowed within ineume and uneume only in order to facilitate transcription into modern notation, not to indicate any written feature in the neume notation.  Therefore, one must view the note elements here as "borrowed" from modern notation.  Since they're a way of inserting modern notation into neumed notation, allowing them to have any of the attributes of neumed notation or making them the targets of plist as in your example below is not advisable.
>
>> ...
>> <uneume xml:id="d1g1">
>> <note xml:id="d1n1" .../>
>> <note xml:id="d1n2" .../>
>> <note xml:id="d1n3" .../>
>> </uneume>
>> <episema value="horizontal" plist="d1n1 d1n2" /> // horizontal episema over two notes in the ligature
>>  *** OR:***
>> <episema value="horizontal" plist="d1n1" /> //horizontal episema over the whole ligature
>> <episema value="vertical" plist="d1n3" /> // vertical episema on just the third note.
>> ...
>
> "Uneume" and "ligature" are not equivalent terms.  A uneume is not a "note group", that is, an arbitrary collection of notes.  Neither is it a ligature as defined by MEI.  Instead, it is a sign written with one stroke of the pen.  I think  --
>
> <ineume xml:id="d1n1" .../>
> <ineume xml:id="d1n2" .../>
> <ineume xml:id="d1n3" .../>
> <episema value="horizontal" startid="d1n1" endid="d1n2" /> // horizontal episema over two neumes in the ligature
>  *** OR:***
> <episema value="horizontal" startid="d1n1" /> //horizontal episema over the whole ligature
> <episema value="vertical" startid="d1n3" /> // vertical episema on just the third neume.
>
> may be closer to what you want.  (Note the changes in your comments to reflect the change in terminology.)
>
> To answer your question, a startid without an endid is contextually defined.  In most cases, it means the starting point and the ending point are one and the same.
>
> Looking at this new repertoire, however, I'm thinking a revision of the definition of ligature as an arbitrary collection of notes (I assume "g1" in the ligature's ID indicates "group 1")  would allow you to wrap neumes --
>
> <ligature xml:id="d1g1">
>  <ineume xml:id="d1n1" .../>
>  <ineume xml:id="d1n2" .../>
>  <ineume xml:id="d1n3" .../>
> </ligature>
>
> However, this means that we'd have to move the ligature element from the mensural to the shared module.  Effectively, this would make the ligature element available in all repertoires.  This may cause some problems with ligatures as they're understood in modern notation, but perhaps I'm getting too far off the immediate path.
>
> As it currently stands, the MEI neumes module was designed to handle pitch-less neumes.  Basically, the name attribute functions as an alternative to pname and oct attributes on notes.  Since you're dealing with pitched neumes, it's probably a good idea to add these attributes to i/uneumes for your new module.  This will help clear up some of the confusion over the use of note elements.
>
> By the way, I think that note elements within i/uneume should be deprecated in favor of using an app/rdg structure.  This would resolve the note use confusion once and for all by encouraging the user to put the neume notation in one rdg and the modern transcription in another.
>
> It wasn't clear from the initial material you provided that episema functioned in quite the way you describe in the comments above.  Now that I see this explanation, I think you're right to suggest that episemata be handled as what I call "control events" -- those that rely on basic events for their existence.  A phrase mark, for instance, is a control event.  It must start and end on a note (a so-called phrase mark that isn't attached to notes is not a phrase mark by this definition) and it does so by referencing those notes' IDs (among other methods).  Yes, startid and endid are preferable to plist, which provides a method of marking *all* the participants in a control event, not just the start and end points.  For example, a phrase element encompassing 10 notes will have its startid set to "n1", its endid to "n10" and its plist attribute (if present) to "n1 n2 n3 ... n10".
>
> Making the episema a control event would accommodate the sanctus example.  In fact, it would allow an episema to be placed over any single neume or combination of neumes and even allow overlapping episemata.
>
> I prefer the attribute name "value" (or another similarly neutral moniker) as an indication of the logical/visual semantics of the episema over "name" for reasons similar to those I gave for my handling of the attribute "type" --
>
> a) xml:id "names" an individual element with a unique (at least within the current document) label, while
> b) the n attribute (n for "name or number") "names" the attribute with a potentially non-unique label.
>
> In this case, we're not looking to label the element, but rather to pass along information about the value/function of the episema.  Admittedly, I have not been completely consistent throughout MEI with this, having succumbed to the temptation to use a name attribute on i/uneume elements, but I reserve the right to be inconsistent.  Sometimes.  :)
>
> The values "horizontal" and "vertical" are fine if you never anticipate using the Solesmes module along with some other module that defines "horizontal" and "vertical" differently.  I just can't say at this point whether this matters now or not.  Perhaps we can't know until we attempt a merging of the Solesmes module with other modules.
>
> --
> p.
>
> __________________________
> Perry Roland
> Digital Curation Services
> University of Virginia Library
> P. O. Box 400155
> Charlottesville, VA 22904-4155
> 434-982-2702 (w)
> pdr4h at virginia.edu
> ________________________________________
> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
> Sent: Monday, June 21, 2010 11:54 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Encoding Square Notation
>
> Hi Perry,
>
> I'll answer inline below to address some of your questions:
>
> On 2010-06-17, at 6:32 PM, Roland, Perry (pdr4h) wrote:
>
>> Andrew,
>>
>> Let me do a little house cleaning in the McGill repo first.  I'm waiting on the results of a little poll of the other members of the technical team, but I should have this done by early next week.  Then we'll talk about where to put the new stuff.
>>
>> Yes, RNG and XSD are the targets right now.  We hope that by early next year, the target will switch to ODD, but you don't need to worry about that now.
>>
>> My modus operandi has been to work in RNG (because I find it easier to comprehend) and then use Trang from inside oXygen to convert to XSD.  Periodic testing of this conversion is a good idea as there are some things that can't be automagically translated.  But if the conversion doesn't work, then it's a clue that you're being too RNG-centric and you should find another way of writing the schema.
>>
>> I think a good starting point would be to modify the neumes module and then the mei-all driver file to include your modified neumes module instead of the original one.  We can take up the possibility of using the current neumes module plus a solesmes module later.
>
> That all sounds good to me. I think a separate Solemnes module is probably the best way to go, given the differences between the variations of neume notation. If we do see some crossover later, we can merge it into a "neumes common" module.
>
>> Regarding episemata:
>>
>> Rather than using the values "horizontal", "vertical", "both" --
>>
>>>> <syllable>
>>>> <syl>DE_</syl>
>>>> <uneume xml:id="d1e1" name="punctum">
>>>>    <note pname="c" oct="4"/>
>>>> </uneume>
>>>> </syllable>
>>>> <syllable>
>>>> <syl>us</syl>
>>>>    <uneume xml:id="d2e1" name="punctum">
>>>>       <note pname="c" oct="4" episema="both" />
>>>>               **OR**
>>>>       <note pname="c" oct="4">
>>>>          <episema type="horizontal" />
>>>>          <episema type="vertical" />
>>>>       </note>
>>>>    </uneume>
>>>> </syllable>
>>
>> I think it would be easier to mesh with any meaning(s) in other repertoires later, if you chose values based on what's being indicated rather than the visual symbol.  For instance --
>>
>> <syllable>
>> <syl>DE_</syl>
>> <uneume xml:id="d1e1" name="punctum">
>>   <note pname="c" oct="4"/>
>> </uneume>
>> </syllable>
>> <syllable>
>> <syl>us</syl>
>> <uneume xml:id="d2e1" name="punctum" episema="compoundbeatbeginningandslightlengthening">
>>   <!-- OR elements instead of the attribute:
>>   <episema value="slightlengthening" />
>>   <episema value="compoundbeatbeginning" /> -->
>>   <note pname="c" oct="4"/>
>> </uneume>
>> </syllable>
>>
>> Of course, these particular values are absurd, but you get the point.  A more appropriate value for "compoundbeatbeginning" is "ictus" (if I read the Harvard Dictionary correctly), but I'm less sure about the other ones.  I hope Stefan will suggest values for the others.  Stefan?
>
> From what I've read, "horizontal" and "vertical" are the "proper" names of the characters, even outside of their visual appearance. They're indicated as such in the introduction to the _Liber_ and in most other texts, so I would imagine it's how most people would be able to refer to them. It's true that the vertical can also be known as the "ictus," but that may be a bit confusing since that also describes the pulse of the chant as well. The vertical episema is just showing an *explicit* ictus, usually indicating a place where the pulse changes from e.g. 3 to 2 or vice-versa, while the absence of a mark may just indicate a continuation of an implicit ictus.
>
> If Stefan has any suggestions, that would be great.
>
>>
>> Also, it seems to me that the episema attribute belongs on the neume, not on the note children, as these are there to provide a ready translation into modern pitch and duration.  Placing the episema attribute on notes would make the attribute available throughout MEI, which is probably not a good idea.  However, the episema values could be translated into modern notation pretty easily; e.g. episema value="slightlengthening" translates to note artic="ten", etc.
>
> There is a difference. A vertical only appears on a single neume, either alone or within a ligature, but a horizontal one can go over a single note, an entire ligature, a partial ligature, or even a number of ligatures. You can see a pretty complex example here:
>
> http://coltrane.music.mcgill.ca/square_notation/sanctus_excerpt.png
>
> Would using a "plist" attribute make sense here, using IDs to refer to either a ligature or a note?
>
> e.g.:
> ...
> <uneume xml:id="d1g1">
>  <note xml:id="d1n1" .../>
>  <note xml:id="d1n2" .../>
>  <note xml:id="d1n3" .../>
> </uneume>
> <episema value="horizontal" plist="d1n1 d1n2" /> // horizontal episema over two notes in the ligature
>  *** OR:***
> <episema value="horizontal" plist="d1n1" /> //horizontal episema over the whole ligature
> <episema value="vertical" plist="d1n3" /> // vertical episema on just the third note.
> ...
>
> Your later comment about episemata being equivalent to articulation is correct, but I couldn't really think about many articulation marks that are applicable to both a single note and a number of notes. The closest I could think of was a trill. In the MEI examples, this is encoded with "startid=" and "endid=" for the note events that it's attached to. Would this be preferable than the "plist=" notation? Would an episema on just one note have a "startid" and no "endid" or would they both just be the same value?
>
>
>>
>> The articulation attribute allows multiple tokens for those cases where several articulation signs occur on the same note.  A similar approach could be used here --
>>
>> <uneume xml:id="d2e1" name="punctum" episema="compoundbeatbeginning slightlengthening">
>>   <!-- OR elements instead of the attribute:
>>   <episema value="slightlengthening" />
>>   <episema value="compoundbeatbeginning" /> -->
>>   <note pname="c" oct="4"/>
>> </uneume>
>>
>> This doesn't preclude using multiple elements as above, which is probably what you'd want to do in OMR.
>
> The more I think about it, the less I think having an attribute for this is necessary. We would almost certainly need to add an attribute to the <note> element if we do go that route, which you're right to point out that we probably don't want to make available through the entire schema. We don't need this as an attribute, I think.
>
>>
>> In addition, you'll notice that I changed your type attribute on episema to "value".  I think it's good practice to use @type to indicate the *classification of the element itself, not its contents.*  For example, <name type="personal">Perry Roland</name> as opposed to <name type="composer">Perry Roland</name>.  The first seems to me like a good use of @type -- it classifies the name, not Perry Roland.  Down the second path is ruin and death. :)
>
> I generally try to avoid ruin and death, so your sage advice on @type is duly noted! What about taking something from the <uneume> element and using the "@name" attribute, if indeed we come to the conclusion that "horizontal" and "vertical" are their names?
>
>>
>> The doubling dot attached to a neume should be accommodated in a similar fashion as episema.  The dots attribute can be cribbed from modern notation, if the dot following a neume is always a dot of augmentation.  I don't think that the difference in the amount of augmentation between neume and modern notation; i.e., double vs. 1 and a half times, presents a significant problem as there will always be different rendering rules for the different repertoires.  But, as always, I defer to experts in the repertoire.
>
> I don't know of any other use for the dot in this repertoire, so I think you're right.
>
>>
>> Looking back over my suggestions, it seems to me, in the absence of other information, that ultimately the meaning and function of "episemata" might be somewhat equivalent to articulations.  It might be a good idea to exploit the parallels even if the terminology is different.
>
> I'll keep investigating this, but in the meantime it would be great to hear from others if they have any opinions on this. We'll probably download the schema and start doing our modifications to it this week, but we'll wait until you do your housecleaning before putting anything in the repository.
>
> Thanks!
>
> -Andrew
>
>
>
> _______________________________________________
> 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