[MEI-L] Encoding Square Notation

[Roland, Perry (pdr4h)]

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