[MEI-L] Encoding Square Notation
Prof. Dr. Morent
stefan.morent at uni-tuebingen.de
Sat Jun 26 13:38:10 CEST 2010
Hi Andrew, Perry,
I have been on tour the last two weeks - but now I find some time to
comment on a few things.
- General remark: Wouldn't it be easier to take the "undecorated"
Vaticana edition as a test field for optical recognition?
I think including all these additional Solesmes signs in the
recognition process makes it more difficult. Already the recognition
of the neume forms as such will be a big task.
Also I would suggest to concentrate on the chants for Mass. The big
advantage would be, that you could compare the Vaticana square
notation later on with the earliest neumed sources (the most important
adiastematic neumed sources are available as digitized images online,
and the last missing, the Codex Einsiedeln 121 wil be added due to my
suggestion within the e-codices project at the end of this year).
This would be most welcome by the scholarly community.
For the office chants the situation is much less clear ...
I know that the Liber Usualis is available online, but you could
easily scan pages from the Vaticana edition of the Gradual for
training your software.
- The Solesmes episemata are the result of the special rhythmic
theories developed at Solesmes for the interpretation of chant (mainly
by Dom Mocquereau). Today they are no longer accepted within the
scholarly community nor at Solesmes, so they have more or less value
as a historic theory.
If you want to include them, I think they should be represented in MEI
the way Andrew suggested, giving them values as "horizontal",
"vertical" etc. since this is the way they are labeld by Solesmes.
The exact rhythmic meaning should be left open to interpretation,
since there is simply no exact meaning (even if you read through the
Solesmes writings, the meaning of these signs is circumscribed as
"slightly longer", "more relaxed" etc.)
To mark the differenc to the episemata used in medieval neume
notation, we should perhaps think of labelling them "solepisema" or
something like this.
- The current MEI neumes model was designed for the Hildegard
notation, this is neumes WITH pitches, since the manuscripts are
written in german neumes on staff lines.
It is also clear, that an uneume never has other uneumes or ineumes as
subcomponents (since it is a shape written in ONE graphical stroke).
The <note> element was added, to provide pitch information. This can
be a single one (e.g. for a punctum or virga) or more (pes, clivis,
torculus etc.)
Adiastematic neumes (chironomic neumes is no longer used as a term)
simply don't have this additional pitch information.
We can interpretate their pitch information by comparing them with
sources written on lines (in this case, the pitch information would be
stored in the encoding of this source, and you could e.g. link the
adiastematic encoding saying: this could be interpretated like this ...)
(One could discuss in genereal of course, if the modern notion of
"pitch" is really adequate for medieval music, regarding questions of
tuning, tone system etc.)
In sum: Since Hildegard's notation is not too far from square
notation, you should find most of your needs already in the current
MEI neumes module, I think.
My best
Stefan
Zitat von "Andrew Hankinson, Mr" <andrew.hankinson at mail.mcgill.ca>:
> 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
>
More information about the mei-l
mailing list