[MEI-L] Encoding Square Notation

[Prof. Dr. Morent]

I agree with Perry that we should hold these two principal cases apart:

1) neumes which don't intend to provide exact pitch information and to  
"store" this information in a system of lines with clef(s) (because  
the melody itself is stored in the memory of a singing tradition), but  
which are nevertheless rich in providing relativ pitch information  
("higher", "lower" etc.) and other hints for intepretation ("faster",  
"slower" etc.) using partly additional signs (as e.g. episemata).
These are generelly called adiastematic neumes (and they don't have  
been covered in their special information in MEI yet)

2) neumes which have made the "step" on line(s) (roughly about after  
the year 1000). They typically loose much of the additional agogical  
information of adiastematic neumes, but (normally) provide exact pitch  
information (special case: ornamental neumes, which are open to exact  
interpretation even if written on lines). Pitch information is so to  
say inherent to this neumes.

While case 2) (e.g. square notation of the 13th or 19th century)  
brings pitch information with itself, case 1) can only be transcribed  
with pitches, if you have a parallel source of case 2) with the same  
melody.
You will normally find, that this parallel melody will not match the  
information of the adiastematic neumes in every place.
This is why, in order to "reconstruct" the older, more original (at  
least this is the assumption) melody of the adiastematic neumes,  
scholars try to modify the pitched melody according to this  
information in these places.

The result is of course a kind of "virtual" melody, which never  
existed in THIS form in ONE source, but which nevertheless has the  
advantage of being closer to the earliest sources, if done carefully  
by experts.

Stefan



Zitat von "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>:

> Hi all,
>
> Johannes' suggestion is correct when dealing with adiastematic  
> neumes.  Because there's no pitch info. contained in the original  
> neumes, any pitch assignment is interpretative.  One should use  
> choice/orig/reg *around* the neumes as in Johannes' example or use  
> app/rdg *inside* each neume.
>
> However, when pitch is a feature of the neume notation (diastematic  
> neumes), then the encoding of pitch is about transcription, not  
> interpretation.  In this case, there must be an element within  
> i/uneume that can be hold pitch information for the neume.  As  
> Andrew has pointed out, an attribute won't work because a neume may  
> represent multiple pitches.
>
> Despite my earlier confusion, now I don't think using <note> inside  
> i/uneume is tag abuse.  It depends on how one defines "note".  The  
> current definition is "a single pitched event".  I think this  
> definition is broad enough to encompass uses in CMN and neumatic  
> notation.  A note in CMN has a lot more "properties" than just pitch  
> -- duration, head size and shape, stem length, etc. -- while in  
> neume notation the list of properties is (probably) shorter and  
> different.  But, differences in the number or value of properties of  
> a note don't, as far as I can see now, make them fundamentally  
> different things in the two repertoires.  The availability of  
> certain note properties in CMN and others in neume notation can be  
> controlled using schema modules and schematron rules.
>
> As Eleanor says, at some point there may be a need for the same  
> kinds of information to be associated with notes in the neume  
> repertoire as that available in the CMN rep.  Ease of processing in  
> this case is another good reason for retaining <note> within i/uneume.
>
> We must, however, make it clear that within i/uneume <note> should  
> only be used for transcription, not interpretation.  Of course, all  
> encoding is interpretation on some level, but the kind of  
> interpretation I'm talking about here is the furnishing of  
> information not in the source being transcribed.
>
> I think we should stick with the original plan, my earlier  
> mis-statements hopefully forgotten.  As Stefan says, "it's all  
> already there".  No need to re-design what's working.  This makes  
> Andrew's job of accommodating the Solesmes notation easier because  
> he doesn't have to add superfluous new features.
>
> --
> 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 Johannes Kepper  
> [kepper at edirom.de]
> Sent: Tuesday, June 29, 2010 1:51 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Encoding Square Notation
>
> Hello all,
>
> sorry for stepping in late, although admittedly I don't have to  
> contribute much from the musicological perspective of this thread.  
> What I am wondering is if the current usage of note within the  
> neumes module is a kind of interpretation of the actual neumes. If  
> so, I'm tempted to call it a transcription into a different notation  
> system (and concept of notation). From that perspective, one might  
> want to encode this as
>
> <choice>
>         <orig type="neumes">…</orig>
>         <reg type="solesmes">…</reg>
>         <reg type="cmn">…</reg>
> </choice>
>
> I'm not sure if my usage of "solesmes" is appropriate here, but I  
> think you get the point. The original neumes do not contain all  
> this, but instead it's something added by the encoder (and thus  
> should be tagged accordingly using the @resp attribute, or even  
> better the <add>-tag) and expressed in a different notational  
> system. If this understanding is wrong, and those additions are  
> really added directly to the neumes, using the <note>-element looks  
> like tag abuse to me, as a cmn note has no business in neumes music.
>
> I can't tell which case applies here, but perhaps this opens another  
> perspective…?
>
> Best regards,
> Johannes
>
>
>
>
> PS: I could think of an element <trans> (transcription) as syntactic  
> sugar for this usage of <reg>…
>
>
>
>
> Am 29.06.2010 um 19:17 schrieb Laurent Pugin:
>
>> Sorry for the typo, I meant <noterdg> (for "note reading") and <rdg>
>>
>> On Tue, Jun 29, 2010 at 7:11 PM, Laurent Pugin  
>> <laurent at music.mcgill.ca> wrote:
>>> It is confusing. I think we agree on the meaning of what has to be
>>> encoded, but using the same element name as for CMN yields some
>>> confusion. Because there is uncertainty in what is encoded anyway,
>>> could something as <noterdg> avoid it? Would it then be too absurd to
>>> have <notergd> within <rgd> in the cases you suggested below? I don't
>>> what to make it even more confusing, but just as a suggestion...
>>>
>>> Laurent
>>>
>>>
>>> On Tue, Jun 29, 2010 at 3:40 PM, Roland, Perry (pdr4h)
>>> <pdr4h at eservices.virginia.edu> wrote:
>>>> Thanks, Laurent.  You've said what I was trying to say with  
>>>> regard to "pitch/neumepitch" vs. "note" much better than I.
>>>>
>>>> What was confusing me before was the function of <note> within a  
>>>> neume.  I think I said before that in this case, it's a carrier  
>>>> of pitch and other information *about the neume*, a kind of  
>>>> metadata regarding a feature of the notation.  Used in CMN, it's  
>>>> a feature of the notation itself.  This was confusing to me at  
>>>> first, but I think I've got it now.  :)
>>>>
>>>> Uncertainty, our old arch-nemesis, rears its head again with such  
>>>> things as quilisma.  :)
>>>>
>>>> When uncertainty of realization is involved, each realization of  
>>>> a neume can be placed in a separate <rdg> within  <app>, which,  
>>>> by the way, is already permitted within neumes.  In complex  
>>>> cases, the metadata about the neume, such as pitch, can be  
>>>> different from its realization.
>>>>
>>>> --
>>>> 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+pdr4h=virginia.edu at lists.uni-paderborn.de  
>>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On  
>>>> Behalf Of Laurent Pugin [laurent at music.mcgill.ca]
>>>> Sent: Tuesday, June 29, 2010 4:03 AM
>>>> To: Music Encoding Initiative
>>>> Subject: Re: [MEI-L] Encoding Square Notation
>>>>
>>>> "Pitch" and "note" are both modern concepts, so none of the two it is
>>>> perfect. First I had "pitch" (or "neumepitch") better than "note"
>>>> because it seemed more abstract to me. But I agree that if we need to
>>>> encode more than just the pitch or note height information here, and
>>>> which seems to be the case, we should go for something else. I can't
>>>> see anything better than "note".
>>>>
>>>> Laurent
>>>>
>>>>
>>>> On Tue, Jun 29, 2010 at 1:17 AM, Prof. Dr. Morent
>>>> <stefan.morent at uni-tuebingen.de> wrote:
>>>>> I think the <note> element works fine with neumes; we had no  
>>>>> difficulties so long with encoding.
>>>>>
>>>>> You might discuss if "note" is really a good term or if "pitch"  
>>>>> might be better, since "note" is a more modern concept.
>>>>>
>>>>> But when neumes are written on lines they relate to a certain  
>>>>> pitch, although they might loose some of the subtle qualities  
>>>>> they had as adiastematic neumes.
>>>>>
>>>>> The question Eleanor is raising would apply to ornamental  
>>>>> neumes, e.g. the quilisma. Even written on lines, the exact  
>>>>> sequence of notes in performance is not certain (probably it was  
>>>>> realized as a kind of trill, including glissando and quarter  
>>>>> tones).
>>>>>
>>>>> Stefan
>>>>>
>>>>> Zitat von "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>:
>>>>>
>>>>>> Considering Eleanor's comments, it seems eliminating <note>  
>>>>>> with all its attributes, pitch and otherwise, from the neume  
>>>>>> repertoire is not a good idea.  I'm fine with retaining <note>  
>>>>>> inside i/uneume for recording pitch.  This will also permit the  
>>>>>> encoding of the other details Eleanor mentions.
>>>>>>
>>>>>> But, I'd like to hear from others too.
>>>>>>
>>>>>> --
>>>>>> 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 Eleanor  
>>>>>> Selfridge-Field [esfield at stanford.edu]
>>>>>> Sent: Monday, June 28, 2010 11:31 AM
>>>>>> To: Music Encoding Initiative
>>>>>> Subject: Re: [MEI-L] Encoding Square Notation
>>>>>>
>>>>>> Whilte not wishing to comment on the neume discussion per se,  
>>>>>> it seems worth saying that when it touches on multi-pitch  
>>>>>> values, it starts to seem very much like the grace-note  
>>>>>> territory, where there can be several pitches, very precise  
>>>>>> graphical details, the possibility of an ambiguous rhythmic  
>>>>>> and/or accentual realization, and computer time value [in the  
>>>>>> context of notation] of zero.
>>>>>>
>>>>>> Neumes have some of those same features, though with different  
>>>>>> weightings for each. Might it be possible for someone with good  
>>>>>> skills in both context to look briefly as these similarities?  
>>>>>> From an implementation perspective, common procedures can save  
>>>>>> a lot of time and aggravation.
>>>>>>
>>>>>> Eleanor (from Belfast)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Eleanor Selfridge-Field
>>>>>> Consulting Professor
>>>>>> Braun Music Center #129
>>>>>> Stanford University
>>>>>> Stanford, CA 94305-3076
>>>>>> http://www.stanford.edu/~esfield/
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Perry Roland (pdr4h)" <pdr4h at eservices.virginia.edu>
>>>>>> To: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de>
>>>>>> Sent: Monday, June 28, 2010 6:36:55 AM
>>>>>> Subject: Re: [MEI-L] Encoding Square Notation
>>>>>>
>>>>>> Hi, all,
>>>>>>
>>>>>> I completely disregarded the fact that neumes may have more than one
>>>>>> pitch, didn't I? That was obviously an error. Doh!
>>>>>>
>>>>>> Andrew is right to suggest sub-elements for pitch. It seems we're back
>>>>>> where we started on this particular issue -- to use <note> to mark pitch
>>>>>> or something else. For the reasons I gave before, I would still like to
>>>>>> disallow <note>. <neumepitch> sounds reasonable. I wonder, however, if
>>>>>> it might not be better to call this new element simply <pitch>.
>>>>>>
>>>>>> I yield to Stefan's judgment regarding episemata. The values
>>>>>> "horizontal" and "vertical" are fine by me.
>>>>>>
>>>>>> Andrew, you and I can talk off-list about the actual schema revisions.
>>>>>>
>>>>>> Best wishes,
>>>>>>
>>>>>> -- 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: Thursday, June 24, 2010 5:00 PM
>>>>>> To: Music Encoding Initiative
>>>>>> Subject: Re: [MEI-L] Encoding Square Notation
>>>>>>
>>>>>> It's not a problem. It's a pleasure to be able to help out.
>>>>>>
>>>>>> I think at issue is the difference between a separation of neume and
>>>>>> pitch content. There may be semantic arguments for and against, but I
>>>>>> think the strongest argument for this separation is the idea that a
>>>>>> "neume" both can, and cannot, have a pitch. If a neume is one note, it
>>>>>> has a pitch. (e.g. a Punctum.) However, if a neume has three
>>>>>> sub-components, it cannot have a pitch value.
>>>>>>
>>>>>> To illustrate: If we "overload" the <uneume> element for both pitch and
>>>>>> grouping information, we can run into a situation where we can produce
>>>>>> syntactically valid XML that has a nonsense meaning. For example:
>>>>>>
>>>>>> <uneume name="torculus" pname="c" oct="4">
>>>>>> <uneume pname="c" ... />
>>>>>> <uneume pname="d" ... />
>>>>>> <uneume pname="c" ... />
>>>>>> </uneume>
>>>>>>
>>>>>> This would be syntactically valid XML, but semantically nonsensical
>>>>>> since we can't have a neume with three pitches given in a @pname
>>>>>> attribute.
>>>>>>
>>>>>> If we, instead, encode the pitch information separate from the neume
>>>>>> information, we don't have to put the @pitch attribute on any u/ineume
>>>>>> elements and reserve those elements simply for marking out groups of one
>>>>>> or many pitches. I thought the <note> element would be a fairly obvious
>>>>>> element to use, but we could also create a separate element for this
>>>>>> use, eg.:
>>>>>>
>>>>>> <uneume name="torculus">
>>>>>> <neumepitch value="c" ... />
>>>>>> <neumepitch value="d" ... />
>>>>>> <neumepitch value="c" ... />
>>>>>> </uneume>
>>>>>>
>>>>>> I think something like this might satisfy your requirement that we keep
>>>>>> any reading or modern interpretation separate from the actual neume, but
>>>>>> it would also make it clear that the pitch information is not a neume in
>>>>>> and of itself - it's simply a sub-component of a larger entity known as
>>>>>> a "torculus". This also does not forego the use of the same <uneume> and
>>>>>> <ineume> for chironomic neumes - they simply would have no pitch
>>>>>> information enclosed within them.
>>>>>>
>>>>>> -Andrew
>>>>>>
>>>>>> On 2010-06-23, at 10:13 AM, Roland, Perry (pdr4h) wrote:
>>>>>>
>>>>>>> Hi, Andrew,
>>>>>>>
>>>>>>> First, let me thank you here, at least semi-publicly, for your help
>>>>>>> with the MEI development repo at McGill. (In case everyone doesn't
>>>>>>> know, Andrew is the administration of this subversion repository.) I'm
>>>>>>> sorry for causing trouble, but I'm thankful for someone like you to
>>>>>>> fix my errors.
>>>>>>>
>>>>>>> Next, I don't think it's clearer to keep the note element, in spite of
>>>>>>> the Liber's and Apel's use of the term "note". You describe the issue
>>>>>>> very clearly when you say the climacus is "almost always referred to
>>>>>>> as a single neume". The fact that some diastematic neumes have pitch
>>>>>>> information associated with them directly while others get their pitch
>>>>>>> information from their sub-elements doesn't bother me at all. This
>>>>>>> approach works for both diastematic and chironomic neumes, the
>>>>>>> chironomic neumes being a subset of all neumes -- they just don't have
>>>>>>> pitch info. Allowing note sub-elements, which permits *transcription*
>>>>>>> of diastematic neumes but *interpretation* of chironomic neumes,
>>>>>>> causes more problems than it solves, in my opinon. Banishing note from
>>>>>>> i/uneume separates these functions -- transcription of pitch belongs
>>>>>>> in pname and oct attributes while interpretation of pitch belongs in
>>>>>>> rdg.
>>>>>>>
>>>>>>> A small correction to your example -- In this case, the climacus
>>>>>>> (interrupted due to multiple pen strokes) is made up of un-interrupted
>>>>>>> components (made with single pen strokes), e.g.,
>>>>>>>
>>>>>>> <ineume name="climacus"> //note: NO pitch indication, since it is a
>>>>>>> group of sub-neumes
>>>>>>>  <uneume pname="b" oct="3" />
>>>>>>>  <uneume pname="a" oct="3" /> // a "punctum inclinatum" is a punctum
>>>>>>>  as a diamond instead of a square
>>>>>>>  <uneume pname="g" oct="3" />
>>>>>>> </ineume>
>>>>>>>
>>>>>>> Finally, let's just pretend my earlier suggestion about using
>>>>>>> <ligature> for a neume group never happened. :) That was a lapse in
>>>>>>> judgement. We should stick with the original purpose of the ligature
>>>>>>> element; that is, marking connected component parts in the mensural
>>>>>>> repertoire.
>>>>>>>
>>>>>>> -- 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+pdr4h=virginia.edu at lists.uni-paderborn.de
>>>>>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of
>>>>>>> Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
>>>>>>> Sent: Monday, June 21, 2010 10:26 PM
>>>>>>> To: Music Encoding Initiative
>>>>>>> Subject: Re: [MEI-L] Encoding Square Notation
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________ 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> 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
>