From thomas.weber at notengrafik.com  Thu Sep  7 11:21:35 2017
From: thomas.weber at notengrafik.com (Thomas Weber)
Date: Thu, 7 Sep 2017 11:21:35 +0200
Subject: [mei-neumes-ig] Recent discussion
Message-ID: <f000c4f5-b91c-7df5-95a7-80038abddef8@notengrafik.com>

Hi group,

here at the Cantus-Network-Tagung in Graz I learned from Inga that there was lively discussion going on off-list where among other things an information hierarchy/tree was circulated that I'd be interested to see.

Elaine and me, we used the opportunity of this conference to develop additional thoughts on the encoding of both neumes with and without lines which we'd want to present to the list soon.  I hope we can still join the ongoing discussion.  (Is there a reason why it's lead off-list?  Is this a matter of trying to make things not too complicated by getting too many people involved?)

I'll end here because conference...
Thomas


-- 

Notengrafik Berlin GmbH
HRB 15007

UstID: DE 289234097
Geschäftsführer:
Thomas Weber und Werner J. Wolff

fon: +49 30 220661685

Leuschnerdamm 13
10999 Berlin

notengrafik.com



From ichiro.fujinaga at mcgill.ca  Thu Sep  7 14:51:25 2017
From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.)
Date: Thu, 7 Sep 2017 12:51:25 +0000
Subject: [mei-neumes-ig] Recent discussion
In-Reply-To: <14184_1504776329_59B11089_14184_231_1_f000c4f5-b91c-7df5-95a7-80038abddef8@notengrafik.com>
References: <14184_1504776329_59B11089_14184_231_1_f000c4f5-b91c-7df5-95a7-80038abddef8@notengrafik.com>
Message-ID: <32FFD450-D180-4B37-A259-8CC077B03C20@mcgill.ca>

Hi Thomas,

Yes, you’re right. I was trying not to over complicate the matters; mostly for my sake, as I was trying to understand the issues.

I will post what I have currently as a draft.

Ichiro

> On Sep 7, 2017, at 5:21 AM, Thomas Weber <thomas.weber at notengrafik.com> wrote:
> 
> Hi group,
> 
> here at the Cantus-Network-Tagung in Graz I learned from Inga that there was lively discussion going on off-list where among other things an information hierarchy/tree was circulated that I'd be interested to see.
> 
> Elaine and me, we used the opportunity of this conference to develop additional thoughts on the encoding of both neumes with and without lines which we'd want to present to the list soon.  I hope we can still join the ongoing discussion.  (Is there a reason why it's lead off-list?  Is this a matter of trying to make things not too complicated by getting too many people involved?)
> 
> I'll end here because conference...
> Thomas
> 
> 
> -- 
> 
> Notengrafik Berlin GmbH
> HRB 15007
> 
> UstID: DE 289234097
> Geschäftsführer:
> Thomas Weber und Werner J. Wolff
> 
> fon: +49 30 220661685
> 
> Leuschnerdamm 13
> 10999 Berlin
> 
> notengrafik.com
> 
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


From ichiro.fujinaga at mcgill.ca  Thu Sep  7 14:57:43 2017
From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.)
Date: Thu, 7 Sep 2017 12:57:43 +0000
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
Message-ID: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>

Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
I’ve arbitrarily named it Version 0.2, so that we can refer back to it.

For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re: @oriscus.

Thanks,

Ichiro

==============================
MEI Neumes Module Draft, Version 0.2

A <neume> element consists of one or more <nc> element(s).

A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.

Attributes for <neume>:
@intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
@significative letters
@hispanicTick (type1, type2)
@hook

Attributes for <nc>: 
@pname
@oct
@intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
@wavy 
@significative letters
@curved (anticlockwise, clockwise)
@angular (plain, v-shaped, staircase) (was @angled) 
@liquescence
@episema
@extended
@tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
@quilisma (2, 3, or 4 curves)
@oriscus (curved, flat, jagged)
@con (gapped, looped) (connection to the previous <nc> within the same <neume>)

Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.


From stefan.morent at uni-tuebingen.de  Thu Sep  7 19:02:46 2017
From: stefan.morent at uni-tuebingen.de (Prof. Dr. Morent)
Date: Thu, 07 Sep 2017 19:02:46 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
Message-ID: <20170907190246.Horde.7WgYzyQtrS06Z_eTmqfrTTV@webmail.uni-tuebingen.de>

Dear all,

thanks for this update.
Would be indeed good to discuss all matters concerning the MEI Neumes  
module on this list so that all can contribute to the ongoing  
discussion.

Would be great to have some sample encodings to see how the proposed  
draft could work and what should or could be adjusted for different  
repertoires of neumed manuscripts.

Thanks a lot,
best regards
Stefan

----- Nachricht von "Ichiro Fujinaga, Prof."  
<ichiro.fujinaga at mcgill.ca> ---------
      Datum: Thu, 7 Sep 2017 12:57:43 +0000
        Von: "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca>
Antwort an: "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca>,  
Neumes Interest Group of the Music Encoding Initiative  
<mei-neumes-ig at lists.uni-paderborn.de>
    Betreff: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
         An: Neumes Interest Group of the Music Encoding Initiative  
<mei-neumes-ig at lists.uni-paderborn.de>


> Here’s what I have for the draft of the proposal for the new MEI  
> Neumes Module schema.
> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>
> For ease of discussion and efficiency, please discuss one issue at a  
> time in separate email threads, e.g., Re: @oriscus.
>
> Thanks,
>
> Ichiro
>
> ==============================
> MEI Neumes Module Draft, Version 0.2
>
> A <neume> element consists of one or more <nc> element(s).
>
> A <nc> (neume component) is a single pitched event, although the  
> exact pitch may not be known.
>
> Attributes for <neume>:
> @intm (interval melodic; relative to the previous <neume>)  
> {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n =  
> neutral/unknown, sh = same or higher (but not lower), sl = same or  
> lower (but not higher))
> @significative letters
> @hispanicTick (type1, type2)
> @hook
>
> Attributes for <nc>:
> @pname
> @oct
> @intm (interval melodic; relative to the previous <neume>)  
> {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh  
> = same or higher (but not lower), sl = same or lower (but not higher))
> @wavy
> @significative letters
> @curved (anticlockwise, clockwise)
> @angular (plain, v-shaped, staircase) (was @angled)
> @liquescence
> @episema
> @extended
> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
> @quilisma (2, 3, or 4 curves)
> @oriscus (curved, flat, jagged)
> @con (gapped, looped) (connection to the previous <nc> within the  
> same <neume>)
>
> Removed from the previous version: @jagged, @flat, @long,  
> @diagonalright, and @hispanicLoop from the <neume> level.
>
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


----- Ende der Nachricht von "Ichiro Fujinaga, Prof."  
<ichiro.fujinaga at mcgill.ca> -----





From ichiro.fujinaga at mcgill.ca  Sat Sep  9 15:55:33 2017
From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.)
Date: Sat, 9 Sep 2017 13:55:33 +0000
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <1448_1504803774_59B17BBE_1448_62_1_20170907190246.Horde.7WgYzyQtrS06Z_eTmqfrTTV@webmail.uni-tuebingen.de>
References: <1448_1504803774_59B17BBE_1448_62_1_20170907190246.Horde.7WgYzyQtrS06Z_eTmqfrTTV@webmail.uni-tuebingen.de>
Message-ID: <6B26E7E2-562D-4089-9713-D4FFCFC0BF3A@mcgill.ca>

Here’s a simple one. I’ll provide more examples later.

[cid:clip_image002.png] Climacus

<neume>
    <nc tilt= “ne”>
    <nc con= “g” intm= “d”>
    <nc con= “g" intm= “d”>
</neume >

Ich

On Sep 7, 2017, at 1:02 PM, Prof. Dr. Morent <stefan.morent at uni-tuebingen.de<mailto:stefan.morent at uni-tuebingen.de>> wrote:

Dear all,

thanks for this update.
Would be indeed good to discuss all matters concerning the MEI Neumes module on this list so that all can contribute to the ongoing discussion.

Would be great to have some sample encodings to see how the proposed draft could work and what should or could be adjusted for different repertoires of neumed manuscripts.

Thanks a lot,
best regards
Stefan

----- Nachricht von "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca<mailto:ichiro.fujinaga at mcgill.ca>> ---------
    Datum: Thu, 7 Sep 2017 12:57:43 +0000
      Von: "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca<mailto:ichiro.fujinaga at mcgill.ca>>
Antwort an: "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca<mailto:ichiro.fujinaga at mcgill.ca>>, Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-paderborn.de<mailto:mei-neumes-ig at lists.uni-paderborn.de>>
  Betreff: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
       An: Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-paderborn.de<mailto:mei-neumes-ig at lists.uni-paderborn.de>>


Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
I’ve arbitrarily named it Version 0.2, so that we can refer back to it.

For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re: @oriscus.

Thanks,

Ichiro

==============================
MEI Neumes Module Draft, Version 0.2

A <neume> element consists of one or more <nc> element(s).

A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.

Attributes for <neume>:
@intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
@significative letters
@hispanicTick (type1, type2)
@hook

Attributes for <nc>:
@pname
@oct
@intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
@wavy
@significative letters
@curved (anticlockwise, clockwise)
@angular (plain, v-shaped, staircase) (was @angled)
@liquescence
@episema
@extended
@tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
@quilisma (2, 3, or 4 curves)
@oriscus (curved, flat, jagged)
@con (gapped, looped) (connection to the previous <nc> within the same <neume>)

Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.

_______________________________________________
mei-neumes-ig mailing list
mei-neumes-ig at lists.uni-paderborn.de<mailto:mei-neumes-ig at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


----- Ende der Nachricht von "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca<mailto:ichiro.fujinaga at mcgill.ca>> -----




_______________________________________________
mei-neumes-ig mailing list
mei-neumes-ig at lists.uni-paderborn.de<mailto:mei-neumes-ig at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170909/9b39f05c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clip_image002.png
Type: image/png
Size: 2350 bytes
Desc: clip_image002.png
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170909/9b39f05c/attachment.png>

From ichiro.fujinaga at mcgill.ca  Sat Sep  9 21:31:22 2017
From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.)
Date: Sat, 9 Sep 2017 19:31:22 +0000
Subject: [mei-neumes-ig] "O splendidissima"
Message-ID: <2FC7418B-B36B-4BDB-A502-55CA40CF602C@mcgill.ca>

Here’s my attempt at encoding the example on Section 6.4.1, which is the opening of Hildegarde's "O Splendidissima Gemma" with the text "O splendidissima”;  originally encoded by Stefan Morent and Gregor Schräder:
http://music-encoding.org/documentation/2.1.1/neumes/

 [cid:208BEEFA-C80F-4C6A-B21C-DDFD60271CFC]

=================================
<?xml version="1.0" encoding="UTF-8"?>
<layer>
<syllable>
    <syl n= "initial">
        <rend color= "red"> O </rend>
    </syl>
    <!-- porrectus -->
    <neume>
        <nc oct= "3" pname= "e"/>
        <nc intm="d" oct= "3" pname= "d"/>
        <nc intm="u" oct= "3" pname= "e"/>
    </neume>
</syllable>
<syllable>
    <syl>splen_ </syl>
    <!-- clivis -->
    <neume>
        <nc oct= "3" pname= "g"/>
        <nc intm="d" oct= "3" pname= "e"/>
    </neume>
    <!-- pes -->
    <neume>
        <nc oct= "3" pname= "d"/>
        <nc intm="u" oct= "3" pname= "e"/>
    </neume>
</syllable>
<syllable>
    <syl>di_ </syl>
    <!-- climacus -->
    <neume>
        <!-- virga -->
        <nc tilt= "n" oct= "3" pname= "f"/>
        <!-- punctum -->
        <nc con= "g" intm= "d" oct= "3" pname= "d"/>
        <!-- punctum -->
        <nc con= "g" intm= "d" oct= "3" pname= "c"/>
    </neume>
</syllable>
<syllable>
    <syl>dis_ </syl>
    <!-- virga -->
    <neume>
        <nc tilt= "n" oct= "3" pname= "e"/>
    </neume>
</syllable>
<syllable>
    <syl>si_ </syl>
    <!-- scandicus -->
    <neume>
        <!-- punctum -->
        <nc oct= "2" pname= "a"/>
        <!-- punctum -->
        <nc con= "g" intm= "u" oct= "2" pname= "b"/>
        <!-- virga -->
        <nc con= "g" intm= "u" tilt= "n" oct= "3" pname= "c"/>
    </neume>
</syllable>
<syllable>
    <syl>ma </syl>
    <!-- clivis -->
    <neume>
        <nc oct= "2" pname= "b"/>
        <nc intm="d" oct= "2" pname= "a"/>
    </neume>
</syllable>
</layer>
=================================

For those unfamiliar with XML: the lines starting with " <!— “, such as " <!-- porrectus —>“, are comments and thus optional.

Ich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170909/2898cc4c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-09-09 at 3.09.11 PM.png
Type: image/png
Size: 201971 bytes
Desc: Screen Shot 2017-09-09 at 3.09.11 PM.png
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170909/2898cc4c/attachment.png>

From andrew.hankinson at mail.mcgill.ca  Sun Sep 10 14:45:46 2017
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson)
Date: Sun, 10 Sep 2017 12:45:46 +0000
Subject: [mei-neumes-ig] "O splendidissima"
In-Reply-To: <2FC7418B-B36B-4BDB-A502-55CA40CF602C@mcgill.ca>
References: <2FC7418B-B36B-4BDB-A502-55CA40CF602C@mcgill.ca>
Message-ID: <67ED4433-9D7A-44C1-8D0D-B4EF5C328E56@mail.mcgill.ca>

Is the intention that neume "names" will always be encoded in comments? (I'm not sure what you mean by "optional").

> On 9 Sep 2017, at 20:31, Ichiro Fujinaga, Prof. <ichiro.fujinaga at mcgill.ca> wrote:
> 
> Here’s my attempt at encoding the example on Section 6.4.1, which is the opening of Hildegarde's "O Splendidissima Gemma" with the text "O splendidissima”;  originally encoded by Stefan Morent and Gregor Schräder:
> http://music-encoding.org/documentation/2.1.1/neumes/
> 
>  <Screen Shot 2017-09-09 at 3.09.11 PM.png>
> 
> =================================
> <?xml version="1.0" encoding="UTF-8"?>
> <layer>
> <syllable>
>     <syl n= "initial">
>         <rend color= "red"> O </rend>
>     </syl>
>     <!-- porrectus -->    
>     <neume>
>         <nc oct= "3" pname= "e"/>
>         <nc intm="d" oct= "3" pname= "d"/>
>         <nc intm="u" oct= "3" pname= "e"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>splen_ </syl>
>     <!-- clivis -->    
>     <neume>
>         <nc oct= "3" pname= "g"/>
>         <nc intm="d" oct= "3" pname= "e"/>
>     </neume>
>     <!-- pes -->    
>     <neume>
>         <nc oct= "3" pname= "d"/>
>         <nc intm="u" oct= "3" pname= "e"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>di_ </syl>
>     <!-- climacus -->    
>     <neume>
>         <!-- virga -->
>         <nc tilt= "n" oct= "3" pname= "f"/>
>         <!-- punctum -->
>         <nc con= "g" intm= "d" oct= "3" pname= "d"/>
>         <!-- punctum -->
>         <nc con= "g" intm= "d" oct= "3" pname= "c"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>dis_ </syl>
>     <!-- virga -->    
>     <neume>
>         <nc tilt= "n" oct= "3" pname= "e"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>si_ </syl>
>     <!-- scandicus -->    
>     <neume>
>         <!-- punctum -->    
>         <nc oct= "2" pname= "a"/>
>         <!-- punctum -->    
>         <nc con= "g" intm= "u" oct= "2" pname= "b"/>
>         <!-- virga -->    
>         <nc con= "g" intm= "u" tilt= "n" oct= "3" pname= "c"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>ma </syl>
>     <!-- clivis -->    
>     <neume>
>         <nc oct= "2" pname= "b"/>
>         <nc intm="d" oct= "2" pname= "a"/>
>     </neume>
> </syllable>
> </layer>
> =================================
> 
> For those unfamiliar with XML: the lines starting with " <!— “, such as " <!-- porrectus —>“, are comments and thus optional.
> 
> Ich
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


From ichiro.fujinaga at mcgill.ca  Sun Sep 10 15:18:20 2017
From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.)
Date: Sun, 10 Sep 2017 13:18:20 +0000
Subject: [mei-neumes-ig] "O splendidissima"
In-Reply-To: <20682_1505047563_59B53409_20682_323_1_67ED4433-9D7A-44C1-8D0D-B4EF5C328E56@mail.mcgill.ca>
References: <2FC7418B-B36B-4BDB-A502-55CA40CF602C@mcgill.ca>
 <20682_1505047563_59B53409_20682_323_1_67ED4433-9D7A-44C1-8D0D-B4EF5C328E56@mail.mcgill.ca>
Message-ID: <ADCF8BBE-DF47-4BCE-86F0-4D6F0274C3A9@mcgill.ca>


> On Sep 10, 2017, at 8:45 AM, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> wrote:
> 
> Is the intention that neume "names" will always be encoded in comments? (I'm not sure what you mean by "optional”). 
> 
No, sorry I was unclear.

I put the comments in there just to help me and for people reading the encoding.

Ichiro

>> On 9 Sep 2017, at 20:31, Ichiro Fujinaga, Prof. <ichiro.fujinaga at mcgill.ca> wrote:
>> 
>> Here’s my attempt at encoding the example on Section 6.4.1, which is the opening of Hildegarde's "O Splendidissima Gemma" with the text "O splendidissima”;  originally encoded by Stefan Morent and Gregor Schräder:
>> http://music-encoding.org/documentation/2.1.1/neumes/
>> 
>> <Screen Shot 2017-09-09 at 3.09.11 PM.png>
>> 
>> =================================
>> <?xml version="1.0" encoding="UTF-8"?>
>> <layer>
>> <syllable>
>>    <syl n= "initial">
>>        <rend color= "red"> O </rend>
>>    </syl>
>>    <!-- porrectus -->    
>>    <neume>
>>        <nc oct= "3" pname= "e"/>
>>        <nc intm="d" oct= "3" pname= "d"/>
>>        <nc intm="u" oct= "3" pname= "e"/>
>>    </neume>
>> </syllable>
>> <syllable>
>>    <syl>splen_ </syl>
>>    <!-- clivis -->    
>>    <neume>
>>        <nc oct= "3" pname= "g"/>
>>        <nc intm="d" oct= "3" pname= "e"/>
>>    </neume>
>>    <!-- pes -->    
>>    <neume>
>>        <nc oct= "3" pname= "d"/>
>>        <nc intm="u" oct= "3" pname= "e"/>
>>    </neume>
>> </syllable>
>> <syllable>
>>    <syl>di_ </syl>
>>    <!-- climacus -->    
>>    <neume>
>>        <!-- virga -->
>>        <nc tilt= "n" oct= "3" pname= "f"/>
>>        <!-- punctum -->
>>        <nc con= "g" intm= "d" oct= "3" pname= "d"/>
>>        <!-- punctum -->
>>        <nc con= "g" intm= "d" oct= "3" pname= "c"/>
>>    </neume>
>> </syllable>
>> <syllable>
>>    <syl>dis_ </syl>
>>    <!-- virga -->    
>>    <neume>
>>        <nc tilt= "n" oct= "3" pname= "e"/>
>>    </neume>
>> </syllable>
>> <syllable>
>>    <syl>si_ </syl>
>>    <!-- scandicus -->    
>>    <neume>
>>        <!-- punctum -->    
>>        <nc oct= "2" pname= "a"/>
>>        <!-- punctum -->    
>>        <nc con= "g" intm= "u" oct= "2" pname= "b"/>
>>        <!-- virga -->    
>>        <nc con= "g" intm= "u" tilt= "n" oct= "3" pname= "c"/>
>>    </neume>
>> </syllable>
>> <syllable>
>>    <syl>ma </syl>
>>    <!-- clivis -->    
>>    <neume>
>>        <nc oct= "2" pname= "b"/>
>>        <nc intm="d" oct= "2" pname= "a"/>
>>    </neume>
>> </syllable>
>> </layer>
>> =================================
>> 
>> For those unfamiliar with XML: the lines starting with " <!— “, such as " <!-- porrectus —>“, are comments and thus optional.
>> 
>> Ich
>> _______________________________________________
>> mei-neumes-ig mailing list
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


From thomas.weber at notengrafik.com  Mon Sep 11 17:12:57 2017
From: thomas.weber at notengrafik.com (Thomas Weber)
Date: Mon, 11 Sep 2017 17:12:57 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
Message-ID: <5ca33c12-784b-4deb-224d-4b0a04d91a03@notengrafik.com>

Hi Ich and all,

thanks so much for your draft and the recent example.  For the past conference, Elaine and me tried to structure our thoughts on the neumes module and zoom out a little.  It really helped to discuss this at the conference (thanks especially to Inga!) and we had a lot to discuss afterwards.

As a result of the discussion, we (Elaine and me) are in the process of preparing a table of concrete encoding suggestions for different signs.  Our goal for this is to improve the logical domain encoding, especially with regard to adiastematic notation and the cleaner separation of logical and visual domain, always keeping in mind the attributes suggested in the latest draft.

I might not have much time to make progress on the table before Wednesday, but I thought I'd let you know there's something coming.

Best
Thomas



Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>
> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re: @oriscus.
>
> Thanks,
>
> Ichiro
>
> ==============================
> MEI Neumes Module Draft, Version 0.2
>
> A <neume> element consists of one or more <nc> element(s).
>
> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
>
> Attributes for <neume>:
> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
> @significative letters
> @hispanicTick (type1, type2)
> @hook
>
> Attributes for <nc>:
> @pname
> @oct
> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
> @wavy
> @significative letters
> @curved (anticlockwise, clockwise)
> @angular (plain, v-shaped, staircase) (was @angled)
> @liquescence
> @episema
> @extended
> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
> @quilisma (2, 3, or 4 curves)
> @oriscus (curved, flat, jagged)
> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
>
> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.
>
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


-- 

Notengrafik Berlin GmbH
HRB 15007

UstID: DE 289234097
Geschäftsführer:
Thomas Weber und Werner J. Wolff

fon: +49 30 220661685

Leuschnerdamm 13
10999 Berlin

notengrafik.com



From ichiro.fujinaga at mcgill.ca  Mon Sep 11 17:31:28 2017
From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.)
Date: Mon, 11 Sep 2017 15:31:28 +0000
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <5ca33c12-784b-4deb-224d-4b0a04d91a03@notengrafik.com>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <5ca33c12-784b-4deb-224d-4b0a04d91a03@notengrafik.com>
Message-ID: <F618C840-AAF0-49C1-A8E2-74B2FCA7E46D@mcgill.ca>

Hi Thomas,

Thank you for the update.
We plan to discuss this in person in Halifax, at the SIMSSA Workshop XIII, hosted by Jennifer Bain, on 22 September.
It would be great if you can have something ready so we can discuss your suggestions.
In attendance will be: Jennifer Bain, Alessandra Ignesti, Debra Lacoste, Kate Helsen, Elsa De Luca, Sarah Long, and Inga Behrendt.

Best,

Ich

> On Sep 11, 2017, at 11:12 AM, Thomas Weber <thomas.weber at notengrafik.com> wrote:
> 
> Hi Ich and all,
> 
> thanks so much for your draft and the recent example.  For the past conference, Elaine and me tried to structure our thoughts on the neumes module and zoom out a little.  It really helped to discuss this at the conference (thanks especially to Inga!) and we had a lot to discuss afterwards.
> 
> As a result of the discussion, we (Elaine and me) are in the process of preparing a table of concrete encoding suggestions for different signs.  Our goal for this is to improve the logical domain encoding, especially with regard to adiastematic notation and the cleaner separation of logical and visual domain, always keeping in mind the attributes suggested in the latest draft.
> 
> I might not have much time to make progress on the table before Wednesday, but I thought I'd let you know there's something coming.
> 
> Best
> Thomas
> 
> 
> 
> Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
>> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>> 
>> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re: @oriscus.
>> 
>> Thanks,
>> 
>> Ichiro
>> 
>> ==============================
>> MEI Neumes Module Draft, Version 0.2
>> 
>> A <neume> element consists of one or more <nc> element(s).
>> 
>> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
>> 
>> Attributes for <neume>:
>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>> @significative letters
>> @hispanicTick (type1, type2)
>> @hook
>> 
>> Attributes for <nc>:
>> @pname
>> @oct
>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>> @wavy
>> @significative letters
>> @curved (anticlockwise, clockwise)
>> @angular (plain, v-shaped, staircase) (was @angled)
>> @liquescence
>> @episema
>> @extended
>> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>> @quilisma (2, 3, or 4 curves)
>> @oriscus (curved, flat, jagged)
>> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
>> 
>> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.
>> 
>> _______________________________________________
>> mei-neumes-ig mailing list
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> 
> 
> -- 
> 
> Notengrafik Berlin GmbH
> HRB 15007
> 
> UstID: DE 289234097
> Geschäftsführer:
> Thomas Weber und Werner J. Wolff
> 
> fon: +49 30 220661685
> 
> Leuschnerdamm 13
> 10999 Berlin
> 
> notengrafik.com
> 


From thomas.weber at notengrafik.com  Tue Sep 12 08:58:22 2017
From: thomas.weber at notengrafik.com (Thomas Weber)
Date: Tue, 12 Sep 2017 08:58:22 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <F618C840-AAF0-49C1-A8E2-74B2FCA7E46D@mcgill.ca>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <F618C840-AAF0-49C1-A8E2-74B2FCA7E46D@mcgill.ca>
Message-ID: <985fdb28-46f0-469c-f89a-39a0c91e60c9@notengrafik.com>

Am 11.09.2017 um 17:31 schrieb Ichiro Fujinaga, Prof.:
> We plan to discuss this in person in Halifax, at the SIMSSA Workshop XIII, hosted by Jennifer Bain, on 22 September.
> It would be great if you can have something ready so we can discuss your suggestions.


That's good to know.  I'd intend to have something ready soon so that you have some time to look at it before the Halifax discussion.

Thomas


-- 

Notengrafik Berlin GmbH
HRB 15007

UstID: DE 289234097
Geschäftsführer:
Thomas Weber und Werner J. Wolff

fon: +49 30 220661685

Leuschnerdamm 13
10999 Berlin

notengrafik.com



From stefan.morent at uni-tuebingen.de  Tue Sep 12 11:51:17 2017
From: stefan.morent at uni-tuebingen.de (Prof. Dr. Morent)
Date: Tue, 12 Sep 2017 11:51:17 +0200
Subject: [mei-neumes-ig] "O splendidissima"
In-Reply-To: <2FC7418B-B36B-4BDB-A502-55CA40CF602C@mcgill.ca>
Message-ID: <20170912115117.Horde.w_qFvf1vYrDUn0vzAx9vFv-@webmail.uni-tuebingen.de>

  thanks for this encoding example!
Should work from my point of view for the Hildegard piece.
We included the neume names in our original encoding, since they were  
also used by the SVG drawing routines of our MEI neumes viewer:

http://www.dimused.uni-tuebingen.de/hildegard/?isForm=1&FILE=2&source=D&L=0

Since classifaction and nomenclature of neumes may vary over time and  
space we discussed at the meeting in Tübingen Nov 16 the idea to  
include pointers to external neume tables, if I remember well.

We should indeed run more test cases in particular with adiastematic sources.

Best
Stefan

----- Nachricht von "Ichiro Fujinaga, Prof."  
<ichiro.fujinaga at mcgill.ca> ---------
     Datum: Sat, 9 Sep 2017 19:31:22 +0000
       Von: "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca>
Antwort an: "Ichiro Fujinaga, Prof." <ichiro.fujinaga at mcgill.ca>,  
Neumes Interest Group of the Music Encoding Initiative  
<mei-neumes-ig at lists.uni-paderborn.de>
   Betreff: [mei-neumes-ig] "O splendidissima"
        An: Neumes Interest Group of the Music Encoding Initiative  
<mei-neumes-ig at lists.uni-paderborn.de>

> Here’s my attempt at encoding the example on Section 6.4.1, which is  
> the opening of Hildegarde's "O Splendidissima Gemma" with the text  
> "O splendidissima”;  originally encoded by Stefan Morent and Gregor  
> Schräder:
>   http://music-encoding.org/documentation/2.1.1/neumes/
>    
>    
>    
>   =================================
>   <?xml version="1.0" encoding="UTF-8"?>
> <layer>
> <syllable>
>     <syl n= "initial">
>         <rend color= "red"> O </rend>
>     </syl>
>     <!-- porrectus -->    
>     <neume>
>         <nc oct= "3" pname= "e"/>
>         <nc intm="d" oct= "3" pname= "d"/>
>         <nc intm="u" oct= "3" pname= "e"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>splen_ </syl>
>     <!-- clivis -->    
>     <neume>
>         <nc oct= "3" pname= "g"/>
>         <nc intm="d" oct= "3" pname= "e"/>
>     </neume>
>     <!-- pes -->    
>     <neume>
>         <nc oct= "3" pname= "d"/>
>         <nc intm="u" oct= "3" pname= "e"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>di_ </syl>
>     <!-- climacus -->    
>     <neume>
>         <!-- virga -->
>         <nc tilt= "n" oct= "3" pname= "f"/>
>         <!-- punctum -->
>         <nc con= "g" intm= "d" oct= "3" pname= "d"/>
>         <!-- punctum -->
>         <nc con= "g" intm= "d" oct= "3" pname= "c"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>dis_ </syl>
>     <!-- virga -->    
>     <neume>
>         <nc tilt= "n" oct= "3" pname= "e"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>si_ </syl>
>     <!-- scandicus -->    
>     <neume>
>         <!-- punctum -->    
>         <nc oct= "2" pname= "a"/>
>         <!-- punctum -->    
>         <nc con= "g" intm= "u" oct= "2" pname= "b"/>
>         <!-- virga -->    
>         <nc con= "g" intm= "u" tilt= "n" oct= "3" pname= "c"/>
>     </neume>
> </syllable>
> <syllable>
>     <syl>ma </syl>
>     <!-- clivis -->    
>     <neume>
>         <nc oct= "2" pname= "b"/>
>         <nc intm="d" oct= "2" pname= "a"/>
>     </neume>
> </syllable>
> </layer>
> =================================
>  
>   For those unfamiliar with XML: the lines starting with " <!— “,  
> such as " <!-- porrectus —>“, are comments and thus optional.
>    
>   Ich

----- Ende der Nachricht von "Ichiro Fujinaga, Prof."  
<ichiro.fujinaga at mcgill.ca> -----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170912/95bfdce7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-09-09 at 3.09.11 PM.png
Type: image/png
Size: 201971 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170912/95bfdce7/attachment.png>

From thomas.weber at notengrafik.com  Wed Sep 20 16:26:37 2017
From: thomas.weber at notengrafik.com (Thomas Weber)
Date: Wed, 20 Sep 2017 16:26:37 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
Message-ID: <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>

An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170920/e65f9aaa/attachment.html>

From andrew.hankinson at mail.mcgill.ca  Wed Sep 20 16:58:17 2017
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson)
Date: Wed, 20 Sep 2017 14:58:17 +0000
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
Message-ID: <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>

Hi Thomas,

Thanks for this, and spending time putting forward some concrete suggestions. 

I'm also of the opinion that the current proposal has a significant bias towards the visual component. I believe this has emerged largely because the exact musical content of some repertoires is unknown, making a system built on a "logical" domain approach to musical description difficult to define. (that is, when all you have a symbol that is angled, and you don't even know what pitch it is, how do you describe it musically?) That said, I think it's worthwhile to try and tug the existing proposal in the direction of addressing and describing the musical content directly.

I have been under the impression that building a system built on explicit naming of neumes as elements would not be a good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape name.

That isn't to say that names are not a valuable thing to encode, but the idea is that these names would be included in a separate taxonomy within the file (or even a separate controlled vocabulary) that might be referenced within an encoding. I think this will go further towards making a general encoding system for all neumed repertoires, instead of narrowing it down to a particular style. 

You might imagine something along the lines of:

<neume type="#clivis">
 ...
</neume>

or

<neume type="http://example.org/neumevocabulary#clivis">
 ...
</neume>

This would let you use your own controlled vocabulary to name things for your own encoding, while maintaining a more general 'data shape' for the musical structures, allowing them to be compared across repertoires.

-Andrew

> On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
> 
> Dear group,
> 
> 
> Elaine and me looked at both the Hildegard example as well as the "standard" neumes table by Cardine and made an attempt at encoding the signs' properties with better separation of domains.  We tried to add more logical domain information to the previously mostly graphical domain info.
> 
> Our thesis was that the main distinguishing factor between different use cases of the Neumes module is in how much detail the notation should be described.  Many projects right now use the Volpiano font to capture only the melodic contour and potentially connection information.  For Corpus monodicum, we want to encode more properties of single staff-bound components, mainly whether a component is an oriscus, quilisma or strophicus.  Our understanding is that the Old Hispanic project as well as the Optical Neumes Recognition project need even more detailed information to be encodable.
> 
> We came to the conclusion that the problem we still need to solve is better separation of visual and logical domains.  Our impression is that the visual domain is of primary importance for both of the named projects.  That might be the reason why the       current draft seems to mainly focus on the visual domain.
> 
> We prepared the following table based on Cardine that outlines our suggested encoding.
> 
>   http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
> 
> The most obvious addition are sub-elements describing each <nc> as one of the seven basic single pitch signs (four basic signs based on Anonymus Vaticanus: acuta, gravis, punctus, producta; three special signs: quilisma, oriscus, strophicus).  We chose to make them elements so that each of those can get its specific set of attributes describing them in more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or "waves" for quilisma.  The idea behind that was to make it clearer which attributes are usable in which contexts, but this could also be done by means of Schematron rules when using attributes instead of elements - which we did in our pre-Graz state of ideas:
> 
>   http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
>   http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
> 
> We suggest to represent the "angled" property using the @con attribute, as "angularity" is a property of the connection.  Depending on the sign, the logical meaning of this would be to lengthen the component before or after the angled connection.  This logical domain info could be recorded using @dur on the proper <nc>.
> 
> We picked up Ich's encoding of "O splendidissima" and made a modified version here:
> 
>   http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
> 
> Here we also tried to illustrate how more detailed visual domain information could added, namely the suggested @tilt.  As the tilt is in most cases a consistent scribal idiosyncrasy, this might however better be solved using the tables of signs that Stefan Morent reminded us of recently.  There, these idiosyncrasies could be described once for an entire file, source or hand.  Johannes (hi to Johannes in CC) suggested that these "standard" patterns of writing might be best put in <scoreDef> and to encode deviations where they occur.  These tables could also be useful to document variation among tokens.
> 
> We suggest to keep the table problem and how to link between the content and the tables (by semi-standardized names, by project       specific naming/numbering schemes or by simple XML IDs, or maybe implicitly by characteristic sequence of single pitch signs) for later discussion, together with other topics like how to represent mi signs and rubrics.
> 
> We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about any outcome concerning the neumes module!
> Thomas
> 
> 
> Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
>> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>> 
>> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re: @oriscus.
>> 
>> Thanks,
>> 
>> Ichiro
>> 
>> ==============================
>> MEI Neumes Module Draft, Version 0.2
>> 
>> A <neume> element consists of one or more <nc> element(s).
>> 
>> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
>> 
>> Attributes for <neume>:
>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>> @significative letters
>> @hispanicTick (type1, type2)
>> @hook
>> 
>> Attributes for <nc>: 
>> @pname
>> @oct
>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>> @wavy 
>> @significative letters
>> @curved (anticlockwise, clockwise)
>> @angular (plain, v-shaped, staircase) (was @angled) 
>> @liquescence
>> @episema
>> @extended
>> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>> @quilisma (2, 3, or 4 curves)
>> @oriscus (curved, flat, jagged)
>> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
>> 
>> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.
>> 
>> _______________________________________________
>> mei-neumes-ig mailing list
>> 
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> 
> -- 
> 
> Notengrafik Berlin GmbH
> HRB 15007
> 
> UstID: DE 289234097
> Geschäftsführer:
> Thomas Weber und Werner J. Wolff
> 
> fon: +49 30 220661685
> 
> Leuschnerdamm 13
> 10999 Berlin
> 
> notengrafik.com
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


From elaine.stratton_hild at uni-wuerzburg.de  Wed Sep 20 17:55:36 2017
From: elaine.stratton_hild at uni-wuerzburg.de (Elaine Stratton Hild)
Date: Wed, 20 Sep 2017 17:55:36 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
Message-ID: <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>


















Dear All,


 


Thank you for your work on this.


 


I agree completely, Andrew, that the neume names should be
able to be included in the encoding, but the encoding should not depend on
them. A quick thought concerning your suggestion below… “neume name” (rather
than “neume type” would probably be more specific and clearer to musicologists
(like me!) using the module.


 


Just to clarify… the proposal Thomas Weber and I have put
forward does not rely upon neume names. The designations we recommend (“acuta”
/ “gravis” \ “punctus” . and “producta” _ ) are the earliest historical
designations for notational signs, and—most importantly—they are not limited to
one notational type. (Perhaps this is along the lines of what you meant with "data shapes", Andrew?)


They designate basic shapes that themselves convey basic information (acuta = one note with the same or higher pitch;
gravis = one note with lower pitch; punctus = one note with same or lower pitch and normal duration; producta = one note
with same or lower pitch and longer duration).


 


They are especially convenient for encoding because they can
be combined to create all the notational signs of all types medieval notation.


 


(Small historical detour... For the writer of the 10th century treatise
where these terms are first used for musical notation, the signs formed binary
oppositions to each other: “Acuta” and “gravis” were drawn from the study of
grammar, with the acuta placed over vowels where the voice rose in pitch and
the gravis placed with syllables where the voice fell in pitch. “Punctus” and “producta”
are symbols drawn from verse analysis: short syllables in Latin were marked
with punctus; long syllables were marked with producta.)


 


We suggest using these designations (as basic "data shapes"), rather than the tilt
attribute, because the basic meaning conveyed by an acuta (the logical domain)
remains consistent across all medieval notations, but the nuanced tilt of the
sign (the visual domain, whether it’s written “north” or “northeast”, for
example) varies with individual scribes.


 


Many thanks and all best wishes,
Elaine   











Dr. Elaine Stratton Hild
Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
Julius-Maximilians-Universität Würzburg
Institut für Musikforschung
Domerschulstraße 13
D-97070 Würzburg





>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
Hi Thomas,

Thanks for this, and spending time putting forward some concrete suggestions. 

I'm also of the opinion that the current proposal has a significant bias towards the visual component. I believe this
has emerged largely because the exact musical content of some repertoires is unknown, making a system built on a
"logical" domain approach to musical description difficult to define. (that is, when all you have a symbol that is
angled, and you don't even know what pitch it is, how do you describe it musically?) That said, I think it's worthwhile
to try and tug the existing proposal in the direction of addressing and describing the musical content directly.

I have been under the impression that building a system built on explicit naming of neumes as elements would not be a
good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across
styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer
non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape
name.

That isn't to say that names are not a valuable thing to encode, but the idea is that these names would be included in a
separate taxonomy within the file (or even a separate controlled vocabulary) that might be referenced within an
encoding. I think this will go further towards making a general narrowing it down to a particular style. 

You might imagine something along the lines of:

<neume type="#clivis">
 ...
</neume>

or

<neume type="http://example.org/neumevocabulary#clivis">
 ...
</neume>

This would let you use your own controlled vocabulary to name things for your own encoding, while maintaining a more
general 'data shape' for the musical structures, allowing them to be compared across repertoires.

-Andrew

> On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
> 
> Dear group,
> 
> 
> Elaine and me looked at both the Hildegard example as well as the "standard" neumes table by Cardine and made an
attempt at encoding the signs' properties with better separation of domains.  We tried to add more logical domain
information to the previously mostly graphical domain info.
> 
> Our thesis was that the main distinguishing factor between different use cases of the Neumes module is in how much
detail the notation should be described.  Many projects right now use the Volpiano font to capture only the melodic
contour and potentially connection information.  For Corpus monodicum, we want to encode more properties of single
staff-bound components, mainly whether a component is an oriscus, quilisma or strophicus.  Our understanding is that the
Old Hispanic project as well as the Optical Neumes Recognition project need even more detailed information to be
encodable.
> 
> We came to the conclusion that the problem we still need to solve is better separation of visual and logical domains. 
Our impression is that the visual domain is of primary importance for both of the named projects.  That might be the
reason why the       current draft seems to mainly focus on the visual domain.
> 
> We prepared the following table based on Cardine that outlines our suggested encoding.
> 
>   http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
> 
> The most obvious addition are sub-elements describing each <nc> as one of the seven basic single pitch signs (four
basic signs based on Anonymus Vaticanus: acuta, gravis, punctus, producta; three special signs: quilisma, oriscus,
strophicus).  We chose to make them elements so that each of those can get its specific set of attributes describing
them in more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or "waves" for quilisma.
 The idea behind that was to make it clearer which attributes are usable in which contexts, but this could also be done
by means of Schematron rules when using attributes instead of elements - which we did in our pre-Graz state of ideas:
> 
>   http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
>   http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
> 
> We suggest to represent the "angled" property using the @con attribute, as "angularity" is a property of the
connection.  Depending on the sign, the logical meaning of this would be to lengthen the component before or after the
angled connection.  This logical domain info could be recorded using @dur on the proper <nc>.
> 
> We picked up Ich's encoding of "O splendidissima" and made a modified version here:
> 
>   http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
> 
> Here we also tried to illustrate how more detailed visual domain information could added, namely the suggested @tilt. 
As the tilt is in most cases a consistent scribal idiosyncrasy, this might however better be solved using the tables of
signs that Stefan Morent reminded us of recently.  There, these idiosyncrasies could be described once for an entire
file, source or hand.  Johannes (hi to Johannes in CC) suggested that these "standard" patterns of writing might be best
put in <scoreDef> and to encode deviations where they occur.  These tables could also be useful to document variation
among tokens.
> 
> We suggest to keep the table problem and how to link between the content and the tableby project       specific naming/numbering schemes or by simple XML IDs, or maybe implicitly by characteristic sequence
of single pitch signs) for later discussion, together with other topics like how to represent mi signs and rubrics.
> 
> We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about any outcome concerning the
neumes module!
> Thomas
> 
> 
> Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
>> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>> 
>> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re:
@oriscus.
>> 
>> Thanks,
>> 
>> Ichiro
>> 
>> ==============================
>> MEI Neumes Module Draft, Version 0.2
>> 
>> A <neume> element consists of one or more <nc> element(s).
>> 
>> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
>> 
>> Attributes for <neume>:
>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n =
neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>> @significative letters
>> @hispanicTick (type1, type2)
>> @hook
>> 
>> Attributes for <nc>: 
>> @pname
>> @oct
>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n =
neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>> @wavy 
>> @significative letters
>> @curved (anticlockwise, clockwise)
>> @angular (plain, v-shaped, staircase) (was @angled) 
>> @liquescence
>> @episema
>> @extended
>> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>> @quilisma (2, 3, or 4 curves)
>> @oriscus (curved, flat, jagged)
>> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
>> 
>> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.
>> 
>> _______________________________________________
>> mei-neumes-ig mailing list
>> 
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> 
> -- 
> 
> Notengrafik Berlin GmbH
> HRB 15007
> 
> UstID: DE 289234097
> Geschäftsführer:
> Thomas Weber und Werner J. Wolff
> 
> fon: +49 30 220661685
> 
> Leuschnerdamm 13
> 10999 Berlin
> 
> notengrafik.com
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig

_______________________________________________
mei-neumes-ig mailing list
mei-neumes-ig at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170920/2c9beb35/attachment.html>

From andrew.hankinson at mail.mcgill.ca  Wed Sep 20 21:23:30 2017
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson)
Date: Wed, 20 Sep 2017 19:23:30 +0000
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
 <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
Message-ID: <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>

Thank you, Elaine! This clarifies a few things.

"Shape" is a term I borrowed from the process of data modelling to mean two objects which share the same properties and values, but which may be completely different instances of something. Two houses with one door and 10 windows could be said to have the same 'data shape', and it doesn't matter if one is a bungalow and one a skinny three-story Dutch house, and one is called a 'house' and another a 'huis'. 

In this case, it simply means that two things that have a pitch contour of "up-then-down," for example, must be instances of the same class of things regardless of any particular name or identifier attached to them. The thing is defined by its properties, and not by a name that is given to it.

Perhaps you could clarify a few things about the functioning of your proposed elements. It seems that there are properties of these symbols that are non-exclusive, and that a single symbol can carry with it multiple dimensions of description. 

As an encoder, when would I choose to use a 'gravis' over a 'puncta' if they can both mean 'lower' pitch? I understand that only puncta can be 'same or lower' but it seems, on the face of it, that there might be some confusion about when to use each. It also seems like there are three signs available to encode the 'same' pitch, two for 'lower', and only one for 'higher.' Will this cover the range of pitch movements necessary in the repertoires?

Both 'puncta' and 'producta' also seem to have an impact on duration, which I think should be clearly separated from pitch. Is there any way to separate the duration implications out from them? If we remove duration from the meaning of the sign (and encode it in a separate attribute), are 'punctus' and 'productus' effectively the same thing? 

Is there a sign for 'same or higher with longer duration'? Is that necessary?

Is there a reason the 'neume' element has been replaced with 'ncg' in the supplied encoding?

Cheers!
-Andrew

> On 20 Sep 2017, at 16:55, Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> wrote:
> 
> Dear All,
>  
> Thank you for your work on this.
>  
> I agree completely, Andrew, that the neume names should be able to be included in the encoding, but the encoding should not depend on them. A quick thought concerning your suggestion below… “neume name” (rather than “neume type” would probably be more specific and clearer to musicologists (like me!) using the module.
>  
> Just to clarify… the proposal Thomas Weber and I have put forward does not rely upon neume names. The designations we recommend (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the earliest historical designations for notational signs, and—most importantly—they are not limited to one notational type. (Perhaps this is along the lines of what you meant with "data shapes", Andrew?)
> 
> They designate basic shapes that themselves convey basic information (acuta = one note with the same or higher pitch; gravis = one note with lower pitch; punctus = one note with same or lower pitch and normal duration; producta = one note with same or lower pitch and longer duration).
>  
> They are especially convenient for encoding because they can be combined to create all the notational signs of all types medieval notation.
>  
> (Small historical detour... For the writer of the 10th century treatise where these terms are first used for musical notation, the signs formed binary oppositions to each other: “Acuta” and “gravis” were drawn from the study of grammar, with the acuta placed over vowels where the voice rose in pitch and the gravis placed with syllables where the voice fell in pitch. “Punctus” and “producta” are symbols drawn from verse analysis: short syllables in Latin were marked with punctus; long syllables were marked with producta.)
>  
> We suggest using these designations (as basic "data shapes"), rather than the tilt attribute, because the basic meaning conveyed by an acuta (the logical domain) remains consistent across all medieval notations, but the nuanced tilt of the sign (the visual domain, whether it’s written “north” or “northeast”, for example) varies with individual scribes.
>  
> Many thanks and all best wishes,
> Elaine   
>  
> 
> 
> 
> 
> 
> Dr. Elaine Stratton Hild
> Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
> Julius-Maximilians-Universität Würzburg
> Institut für Musikforschung
> Domerschulstraße 13
> D-97070 Würzburg
> 
> 
> >>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
> Hi Thomas,
> 
> Thanks for this, and spending time putting forward some concrete suggestions. 
> 
> I'm also of the opinion that the current proposal has a significant bias towards the visual component. I believe this has emerged largely because the exact musical content of some repertoires is unknown, making a system built on a "logical" domain approach to musical description difficult to define. (that is, when all you have a symbol that is angled, and you don't even know what pitch it is, how do you describe it musically?) That said, I think it's worthwhile to try and tug the existing proposal in the direction of addressing and describing the musical content directly.
> 
> I have been under the impression that building a system built on explicit naming of neumes as elements would not be a good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape name.
> 
> That isn't to say that names are not a valuable thing to encode, but the idea is that these names would be included in a separate taxonomy within the file (or even a separate controlled vocabulary) that might be referenced within an encoding. I think this will go further towards making a general encoding system for all neumed repertoires, instead of narrowing it down to a particular style. 
> 
> You might imagine something along the lines of:
> 
> <neume type="#clivis">
> ...
> </neume>
> 
> or
> 
> <neume type="http://example.org/neumevocabulary#clivis">
> ...
> </neume>
> 
> This would let you use your own controlled vocabulary to name things for your own encoding, while maintaining a more general 'data shape' for the musical structures, allowing them to be compared across repertoires.
> 
> -Andrew
> 
> > On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
> > 
> > Dear group,
> > 
> > 
> > Elaine and me looked at both the Hildegard example as well as the "standard" neumes table by Cardine and made an attempt at encoding the signs' properties with better separation of domains. We tried to add more logical domain information to the previously mostly graphical domain info.
> > 
> > Our thesis was that the main distinguishing factor between different use cases of the Neumes module is in how much detail the notation should be described. Many projects right now use the Volpiano font to capture only the melodic contour and potentially connection information. For Corpus monodicum, we want to encode more properties of single staff-bound components, mainly whether a component is an oriscus, quilisma or strophicus. Our understanding is that the Old Hispanic project as well as the Optical Neumes Recognition project need even more detailed information to be encodable.
> > 
> > We came to the conclusion that the problem we still need to solve is better separation of visual and logical domains. Our impression is that the visual domain is of primary importance for both of the named projects. That might be the reason why the current draft seems to mainly focus on the visual domain.
> > 
> > We prepared the following table based on Cardine that outlines our suggested encoding.
> > 
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
> > 
> > The most obvious addition are sub-elements describing each <nc> as one of the seven basic single pitch signs (four basic signs based on Anonymus Vaticanus: acuta, gravis, punctus, producta; three special signs: quilisma, oriscus, strophicus). We chose to make them elements so that each of those can get its specific set of attributes describing them in more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or "waves" for quilisma. The idea behind that was to make it clearer which attributes are usable in which contexts, but this could also be done by means of Schematron rules when using attributes instead of elements - which we did in our pre-Graz state of ideas:
> > 
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
> > 
> > We suggest to represent the "angled" property using the @con attribute, as "angularity" is a property of the connection. Depending on the sign, the logical meaning of this would be to lengthen the component before or after the angled connection. This logical domain info could be recorded using @dur on the proper <nc>.
> > 
> > We picked up Ich's encoding of "O splendidissima" and made a modified version here:
> > 
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
> > 
> > Here we also tried to illustrate how more detailed visual domain information could added, namely the suggested @tilt. As the tilt is in most cases a consistent scribal idiosyncrasy, this might however better be solved using the tables of signs that Stefan Morent reminded us of recently. There, these idiosyncrasies could be described once for an entire file, source or hand. Johannes (hi to Johannes in CC) suggested that these "standard" patterns of writing might be best put in <scoreDef> and to encode deviations where they occur. These tables could also be useful to document variation among tokens.
> > 
> > We suggest to keep the table problem and how to link between the content and the tables (by semi-standardized names, by project specific naming/numbering schemes or by simple XML IDs, or maybe implicitly by characteristic sequence of single pitch signs) for later discussion, together with other topics like how to represent mi signs and rubrics.
> > 
> > We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about any outcome concerning the neumes module!
> > Thomas
> > 
> > 
> > Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
> >> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
> >> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
> >> 
> >> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re: @oriscus.
> >> 
> >> Thanks,
> >> 
> >> Ichiro
> >> 
> >> ==============================
> >> MEI Neumes Module Draft, Version 0.2
> >> 
> >> A <neume> element consists of one or more <nc> element(s).
> >> 
> >> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
> >> 
> >> Attributes for <neume>:
> >> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
> >> @significative letters
> >> @hispanicTick (type1, type2)
> >> @hook
> >> 
> >> Attributes for <nc>: 
> >> @pname
> >> @oct
> >> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
> >> @wavy 
> >> @significative letters
> >> @curved (anticlockwise, clockwise)
> >> @angular (plain, v-shaped, staircase) (was @angled) 
> >> @liquescence
> >> @episema
> >> @extended
> >> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
> >> @quilisma (2, 3, or 4 curves)
> >> @oriscus (curved, flat, jagged)
> >> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
> >> 
> >> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.
> >> 
> >> _______________________________________________
> >> mei-neumes-ig mailing list
> >> 
> >> mei-neumes-ig at lists.uni-paderborn.de
> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> > 
> > -- 
> > 
> > Notengrafik Berlin GmbH
> > HRB 15007
> > 
> > UstID: DE 289234097
> > Geschäftsführer:
> > Thomas Weber und Werner J. Wolff
> > 
> > fon: +49 30 220661685
> > 
> > Leuschnerdamm 13
> > 10999 Berlin
> > 
> > notengrafik.com
> > 
> > _______________________________________________
> > mei-neumes-ig mailing list
> > mei-neumes-ig at lists.uni-paderborn.de
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


From elaine.stratton_hild at uni-wuerzburg.de  Thu Sep 21 14:05:37 2017
From: elaine.stratton_hild at uni-wuerzburg.de (Elaine Stratton Hild)
Date: Thu, 21 Sep 2017 14:05:37 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
 <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
 <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>
Message-ID: <59C3AB11020000E30006742C@gwia01.uni-wuerzburg.de>

Thanks so much for your time, Andrew (and all!).  My answers are below, marked with *. 

All best wishes,
Elaine










Dr. Elaine Stratton Hild
Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
Julius-Maximilians-Universität Würzburg
Institut für Musikforschung
Domerschulstraße 13
D-97070 Würzburg





>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 9:24 PM >>>
Thank you, Elaine! This clarifies a few things.

"Shape" is a term I borrowed from the process of data modelling to mean two objects which share the same properties and
values, but which may be completely different instances of something. Two houses with one door and 10 windows could be
said to have the same 'data shape', and it doesn't matter if one is a bungalow and one a skinny three-story Dutch house,
and one is called a 'house' and another a 'huis'. 

In this case, it simply means that two things that have a pitch contour of "up-then-down," for example, must be
instances of the same class of things regardless of any particular name or identifier attached to them. The thing is
defined by its properties, and not by a name that is given to it.


***Thank you for the explanation!

Perhaps you could clarify a few things about the functioning of your proposed elements. It seems that there are
properties of these symbols that are non-exclusive, and that a single symbol can carry with it multiple dimensions of
description. 

As an encoder, when would I choose to use a 'gravis' over a 'puncta' if they can both mean 'lower' pitch? 


***These terms refer to different signs, different visual forms on the page. A gravis looks different than a punctus.
(Gravis looks like \ while punctus looks like a period . In O splendidissima, the first notational sign above the
syllable "splen" is an acuta connected to a gravis; two punctus are visible above the syllable "di")  A musicologist
encoding the notation can record the basic visual forms with the terms gravis, acuta, punctus, producta. The meanings of
these signs will need to encoded separately, because the meanings depend, to some extent, on context of the surrounding
signs (which a musicologist can interpret). A punctus can mean "lower than preceding pitch" or it could also be slightly
more ambiguous--it could mean "same or lower than the preceding pitch." 


 I understand that only puncta can be 'same or lower' but it seems, on the face of it, that there might be some
confusion about when to use each. It also seems like there are three signs available to encode the 'same' pitch, two for
'lower', and only one for 'higher.' 


***When choosing which basic sign to encode, the musicologist will follow the scribe's use of the signs. Yes, you're
right, different signs were used to convey the same information about pitch content. Conveying information about pitch
content was not the only (or even the most important) aspect of notation for many medieval scribes. They used different
forms to show different aspects of performance, and that's why it's important for us to be able to encode both the
graphic signs (the visual domain) as well as the meanings we can glean from the scribe's use of the signs (the logical
domain).  Returning to O splendidissima, the "lower" pitches the scribe wrote with punctus were probably performed
shorter, or "lighter" than the the "lower" pitch recorded with the gravis. A musicologist should be able to add as much
of this nuanced performance information that she wants, depending on her understanding of the notation and her desire
for detail.


 Will this cover the range of pitch movements necessary in the repertoires?


***We need the options of neutral (or unknown), same, lower, same or lower, higher, same or higher. In some cases, a
scribe will modify a sign to give additional information concerning pitch content. For instance, a scribe sometimes
wrote a gravis longer, visually--extending down further than usual. (The gravis over "splen" happens to be one example.)
The information about melodic interval is still "lower than previous pitch", but the musicologist might want to record
the additional visual information (extended) and also record the meaning she attributes to the scribe's modification
("lower than the previous pitch by a third or more").  (In the case of O splendidissima, because the scribe used a
staff, we can record absolute pitch levels--the descent of "g" to "e".)

Both 'puncta' and 'producta' also seem to have an impact on duration, which I think should be clearly separated from
pitch. Is there any way to separate the duration implications out from them? If we remove duration from the meaning of
the sign (and encode it in a separate attribute), are 'punctus' and 'productus' effectively the same thing? 


****We would still differentiate between punctus and producta to reflect the sign the scribe used (for our visual
domain). Yes, I think we absolutely should record the duration implications separately, because some scribes used
"producta" as the standard sign for "lower" and "same or lower" pitches, while other scribes used "punctus" as the
standard and only used "producta" in special situations, to indicate lengthened duration. I think Thomas Weber was
considering suggesting the @dur attribute (data.DURATION.neumes) with the values "longer" and "shorter". 

Is there a sign for 'same or higher with longer duration'? Is that necessary?


**No, there's no basic sign for that. To show a higher pitch with longer duration, a scribe would add an episema to the
acuta, or add a significative letter "t" (tenere) next to the acuta. The proposal from Thomas Weber and me would allow a
significative letter element and using the @dur attribute (longer and shorter duration) to record the meaning of the
scribe's use of episema and significative letters.

Is there a reason the 'neume' element has been replaced with 'ncg' in the supplied encoding?


***Yes! We are trying to make the Neumes Module revision comfortable for all musicologists. The term neume can mean
different things, depending on the context in which it is used, and the musicologist. Neume component grouping is
clearly a technical term, specific to the encoding, that will not cause confusion for chant scholars.

Cheers!
-Andrew

> On 20 Sep 2017, at 16:55, Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> wrote:
> 
> Dear All,
>  
> Thank you for your work on this.
>  
> I agree completely, Andrew, that the neume names should be able to be included in the encoding, but the encoding
should not depend on them. A quick thought concerning your suggestion below… “neume name” (rather than “neume type”
would probably be more specific and clearer to musicologists (like me!) using the module.
>  
> Just to clarify… the proposal Thomas Weber and I have put forward does not rely upon neume names. The designations we
recommend (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the earliest historical designations for notational
signs, and—most importantly—they are not limited to one notational type. (Perhaps this is along the lines of what you
meant with "data shapes", Andrew?)
> 
> They designate basic shapes that themselves convey basic information (acuta = one note with the same or higher pitch;
gravis = one note with lower pitch; punctus = one note with same or lower pitch and normal duration; producta = one note
with same or lower pitch and longer duration).
>  
> They are especially convenient for encoding because they can be combined to create all the notational signs of all
types medieval notation.
>  
> (Small historical detour... For the writer of the 10th century treatise where these terms are first used for musical
notation, the signs formed binary oppositions to each other: “Acuta” and “gravis” were drawn from the study of grammar,
with the acuta placed over vowels where the voice rose in pitch and the gravis placed with syllables where the voice
fell in pitch. “Punctus” and “producta” are symbols drawn from verse analysis: short syllables in Latin were marked with
punctus; long syllables were marked with producta.)
>  
> We suggest using these designations (as basic "data shapes"), rather than the tilt attribute, because the basic
meaning conveyed by an acuta (the logical domain) remains consistent across all medieval notations, but the nuanced tilt
of the sign (the visual domain, whether it’s written “north” or “northeast”, for example) varies with individual
scribes.
>  
> Many thanks and all best wishes,
> Elaine   
>  
> 
> 
> 
> 
> 
> Dr. Elaine Stratton Hild
> Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
> Julius-Maximilians-Universität Würzburg
> Institut für Musikforschung
> Domerschulstraße 13
> D-97070 Würzburg
> 
> 
> >>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
> Hi Thomas,
> 
> Thanks for this, and spending time putting forward some concrete suggestions. 
> 
> I'm also of the opinion that the current proposal has a significant bias towards the visual component. I believe this
has emerged largely because the exact musical content of some repertoires is unknown, making a system built on a
"logical" domain approach to musical description difficult to define. (that is, when all you have a symbol that is
angled, and you don't even know what pitch it is, how do you describe it musically?) That said, I think it's worthwhile
to try and tug the existing proposal in the direction of addressing and describing the musical content directly.
> 
> I have been under the impression that building a system built on explicit naming of neumes as elements would not be a
good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across
styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer
non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape
name.
> 
> That isn't to say that names are not a valuable thing to encode, but the idea is that these names would be included in
a separate taxonomy within the file (or even a separate controlled vocabulary) that might be referenced within an
encoding. I think this will go further towards making a general encoding system for all neumed repertoires, instead of
narrowing it down to a particular style. 
> 
> You might imagine something along the lines of:
> 
> <neume type="#clivis">
> ...
> </neume>
> 
> or
> 
> <neume type="http://example.org/neumevocabulary#clivis">
> ...
> </neume>
> 
> This would let you use your own controlled vocabulary to name things for your own encoding, while maintaining a more
general 'data shape' for the musical structures, allowing them to be compared across repertoires.
> 
> -Andrew
> 
> > On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
> > 
> > Dear group,
> > 
> > 
> > Elaine and me looked at both the Hildegard example as well as the "standard" neumes table by Cardine and made an
attempt at encoding the signs' properties with better separation of domains. We tried to add more logical domain
information to the previously mostly graphical domain info.
> > 
> > Our thesis was that the main distinguishing factor between different use cases of the Neumes module is in how much
detail the notation should be described. Many projects right now use the Volpiano font to capture only the melodic
contour and potentially connection information. For Corpus monodicum, we want to encode more properties of single
staff-bound components, mainly whether a component is an oriscus, quilisma or strophicus. Our understanding is that the
Old Hispanic project as well as the Optical Neumes Recognition project need even more detailed information to be
encodable.
> > 
> > We came to the conclusion that the problem we still need to solve is better separation of visual and logical
domains. Our impression is that the visual domain is of primary importance for both of the named projects. That might bthe reason why the current draft seems to mainly focus on the visual domain.
> > 
> > We prepared the following table based on Cardine that outlines our suggested encoding.
> > 
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
> > 
> > The most obvious addition are sub-elements describing each <nc> as one of the seven basic single pitch signs (four
basic signs based on Anonymus Vaticanus: acuta, gravis, punctus, producta; three special signs: quilisma, oriscus,
strophicus). We chose to make them elements so that each of those can get its specific set of attributes describing them
in more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or "waves" for quilisma. The
idea behind that was to make it clearer which attributes are usable in which contexts, but this could also be done by
means of Schematron rules when using attributes instead of elements - which we did in our pre-Graz state of ideas:
> > 
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
> > 
> > We suggest to represent the "angled" property using the @con attribute, as "angularity" is a property of the
connection. Depending on the sign, the logical meaning of this would be to lengthen the component before or after the
angled connection. This logical domain info could be recorded using @dur on the proper <nc>.
> > 
> > We picked up Ich's encoding of "O splendidissima" and made a modified version here:
> > 
> >  http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
> > 
> > Here we also tried to illustrate how more detailed visual domain information could added, namely the suggested
@tilt. As the tilt is in most cases a consistent scribal idiosyncrasy, this might however better be solved using the
tables of signs that Stefan Morent reminded us of recently. There, these idiosyncrasies could be described once for an
entire file, source or hand. Johannes (hi to Johannes in CC) suggested that these "standard" patterns of writing might
be best put in <scoreDef> and to encode deviations where they occur. These tables could also be useful to document
variation among tokens.
> > 
> > We suggest to keep the table problem and how to link between the content and the tables (by semi-standardized names,
by project specific naming/numbering schemes or by simple XML IDs, or maybe implicitly by characteristic sequence of
single pitch signs) for later discussion, together with other topics like how to represent mi signs and rubrics.
> > 
> > We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about any outcome concerning the
neumes module!
> > Thomas
> > 
> > 
> > Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
> >> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
> >> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
> >> 
> >> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re:
@oriscus.
> >> 
> >> Thanks,
> >> 
> >> Ichiro
> >> 
> >> ==============================
> >> MEI Neumes Module Draft, Version 0.2
> >> 
> >> A <neume> element consists of one or more <nc> element(s).
> >> 
> >> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
> >> 
> >> Attributes for <neume>:
> >> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n
= neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
> >> @significative letters
> >> @hispanicTick (type1, type2)
> >> @hook
> >> 
> >> Attributes for <nc>: 
> >> @pname
> >> @oct
> >> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n =
neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
> >> @wavy 
> >> @significative letters
> >> @curved (> >> @angular (plain, v-shaped, staircase) (was @angled) 
> >> @liquescence
> >> @episema
> >> @extended
> >> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
> >> @quilisma (2, 3, or 4 curves)
> >> @oriscus (curved, flat, jagged)
> >> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
> >> 
> >> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.
> >> 
> >> _______________________________________________
> >> mei-neumes-ig mailing list
> >> 
> >> mei-neumes-ig at lists.uni-paderborn.de
> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> > 
> > -- 
> > 
> > Notengrafik Berlin GmbH
> > HRB 15007
> > 
> > UstID: DE 289234097
> > Geschäftsführer:
> > Thomas Weber und Werner J. Wolff
> > 
> > fon: +49 30 220661685
> > 
> > Leuschnerdamm 13
> > 10999 Berlin
> > 
> > notengrafik.com
> > 
> > _______________________________________________
> > mei-neumes-ig mailing list
> > mei-neumes-ig at lists.uni-paderborn.de
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig

_______________________________________________
mei-neumes-ig mailing list
mei-neumes-ig at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170921/aea11842/attachment.html>

From thomas.weber at notengrafik.com  Thu Sep 21 14:06:39 2017
From: thomas.weber at notengrafik.com (Thomas Weber)
Date: Thu, 21 Sep 2017 14:06:39 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
Message-ID: <9ec524a0-36af-5938-6c03-e1cf0e7e4857@notengrafik.com>

I made a mistake here:


Am 20.09.2017 um 16:26 schrieb Thomas Weber:
>
> http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml


The correct link is:


http://cm.notengrafik.com/2017-Graz-Cantus-Network/cardine-table/cardine_web.xml


("Network" instead of "Newtork").

Thomas

-- 

Notengrafik Berlin GmbH
HRB 15007

UstID: DE 289234097
Geschäftsführer:
Thomas Weber und Werner J. Wolff

fon: +49 30 220661685

Leuschnerdamm 13
10999 Berlin

notengrafik.com



From pdr4h at virginia.edu  Wed Sep 20 17:20:15 2017
From: pdr4h at virginia.edu (Roland, Perry D. (pdr4h))
Date: Wed, 20 Sep 2017 15:20:15 +0000
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
Message-ID: <CY1PR13MB0127A5306CF29A717FF8068A9F610@CY1PR13MB0127.namprd13.prod.outlook.com>


Thomas,

I haven't yet had the time to read your proposal, but I agree with Andrew that semantic meaning (rather than visual characteristics) should be the primary focus of any encoding.  As for naming, MEI 4.0.0 allows one to reference a locally- or externally-defined taxonomy/ontology/controlled vocabulary/classification scheme using the @class attribute, e.g., 

<div class="http://www.myTaxonomy.com/#class001">

The @type attribute can be used for ad hoc typing for extension or restriction; that is, where a formal taxonomy doesn't exist, e.g.,

<div type="foo">
<div type="bar">
<div type="bingo">

--
p.


> -----Original Message-----
> From: mei-neumes-ig [mailto:mei-neumes-ig-bounces at lists.uni-paderborn.de] On Behalf
> Of Andrew Hankinson
> Sent: Wednesday, September 20, 2017 10:58 AM
> To: Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-
> paderborn.de>
> Cc: Johannes Kepper <kepper at edirom.de>
> Subject: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
> 
> Hi Thomas,
> 
> Thanks for this, and spending time putting forward some concrete suggestions.
> 
> I'm also of the opinion that the current proposal has a significant bias towards the visual
> component. I believe this has emerged largely because the exact musical content of some
> repertoires is unknown, making a system built on a "logical" domain approach to musical
> description difficult to define. (that is, when all you have a symbol that is angled, and you
> don't even know what pitch it is, how do you describe it musically?) That said, I think it's
> worthwhile to try and tug the existing proposal in the direction of addressing and
> describing the musical content directly.
> 
> I have been under the impression that building a system built on explicit naming of neumes
> as elements would not be a good idea, based on critiques I have heard on the existing
> neume module. The same neume can have many names (across styles or languages) and
> building a system on neume names makes it more difficult to accurately capture the longer
> non-standard (i.e., "compound") neumes. Thus the reason for building a system based on
> shape contour, rather than shape name.
> 
> That isn't to say that names are not a valuable thing to encode, but the idea is that these
> names would be included in a separate taxonomy within the file (or even a separate
> controlled vocabulary) that might be referenced within an encoding. I think this will go
> further towards making a general encoding system for all neumed repertoires, instead of
> narrowing it down to a particular style.
> 
> You might imagine something along the lines of:
> 
> <neume type="#clivis">
>  ...
> </neume>
> 
> or
> 
> <neume type="http://example.org/neumevocabulary#clivis">
>  ...
> </neume>
> 
> This would let you use your own controlled vocabulary to name things for your own
> encoding, while maintaining a more general 'data shape' for the musical structures,
> allowing them to be compared across repertoires.
> 
> -Andrew
> 
> > On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
> >
> > Dear group,
> >
> >
> > Elaine and me looked at both the Hildegard example as well as the "standard" neumes
> table by Cardine and made an attempt at encoding the signs' properties with better
> separation of domains.  We tried to add more logical domain information to the previously
> mostly graphical domain info.
> >
> > Our thesis was that the main distinguishing factor between different use cases of the
> Neumes module is in how much detail the notation should be described.  Many projects
> right now use the Volpiano font to capture only the melodic contour and potentially
> connection information.  For Corpus monodicum, we want to encode more properties of
> single staff-bound components, mainly whether a component is an oriscus, quilisma or
> strophicus.  Our understanding is that the Old Hispanic project as well as the Optical
> Neumes Recognition project need even more detailed information to be encodable.
> >
> > We came to the conclusion that the problem we still need to solve is better separation of
> visual and logical domains.  Our impression is that the visual domain is of primary
> importance for both of the named projects.  That might be the reason why the       current
> draft seems to mainly focus on the visual domain.
> >
> > We prepared the following table based on Cardine that outlines our suggested encoding.
> >
> >
> > http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardi
> > ne_web.xml
> >
> > The most obvious addition are sub-elements describing each <nc> as one of the seven
> basic single pitch signs (four basic signs based on Anonymus Vaticanus: acuta, gravis,
> punctus, producta; three special signs: quilisma, oriscus, strophicus).  We chose to make
> them elements so that each of those can get its specific set of attributes describing them in
> more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or
> "waves" for quilisma.  The idea behind that was to make it clearer which attributes are
> usable in which contexts, but this could also be done by means of Schematron rules when
> using attributes instead of elements - which we did in our pre-Graz state of ideas:
> >
> >   http://cm.notengrafik.com/2017-Graz-Cantus-
> Network/presentation/presentation.html#variations
> >
> > http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presen
> > tation.html#code-sign
> >
> > We suggest to represent the "angled" property using the @con attribute, as "angularity"
> is a property of the connection.  Depending on the sign, the logical meaning of this would
> be to lengthen the component before or after the angled connection.  This logical domain
> info could be recorded using @dur on the proper <nc>.
> >
> > We picked up Ich's encoding of "O splendidissima" and made a modified version here:
> >
> >
> > http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.me
> > i
> >
> > Here we also tried to illustrate how more detailed visual domain information could
> added, namely the suggested @tilt.  As the tilt is in most cases a consistent scribal
> idiosyncrasy, this might however better be solved using the tables of signs that Stefan
> Morent reminded us of recently.  There, these idiosyncrasies could be described once for
> an entire file, source or hand.  Johannes (hi to Johannes in CC) suggested that these
> "standard" patterns of writing might be best put in <scoreDef> and to encode deviations
> where they occur.  These tables could also be useful to document variation among tokens.
> >
> > We suggest to keep the table problem and how to link between the content and the tables
> (by semi-standardized names, by project       specific naming/numbering schemes or by
> simple XML IDs, or maybe implicitly by characteristic sequence of single pitch signs) for
> later discussion, together with other topics like how to represent mi signs and rubrics.
> >
> > We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about
> any outcome concerning the neumes module!
> > Thomas
> >
> >
> > Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
> >> Here’s what I have for the draft of the proposal for the new MEI Neumes Module
> schema.
> >> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
> >>
> >> For ease of discussion and efficiency, please discuss one issue at a time in separate
> email threads, e.g., Re: @oriscus.
> >>
> >> Thanks,
> >>
> >> Ichiro
> >>
> >> ==============================
> >> MEI Neumes Module Draft, Version 0.2
> >>
> >> A <neume> element consists of one or more <nc> element(s).
> >>
> >> A <nc> (neume component) is a single pitched event, although the exact pitch may not
> be known.
> >>
> >> Attributes for <neume>:
> >> @intm (interval melodic; relative to the previous <neume>)
> >> {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n =
> >> neutral/unknown, sh = same or higher (but not lower), sl = same or
> >> lower (but not higher)) @significative letters @hispanicTick (type1,
> >> type2) @hook
> >>
> >> Attributes for <nc>:
> >> @pname
> >> @oct
> >> @intm (interval melodic; relative to the previous <neume>)
> >> {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh
> >> = same or higher (but not lower), sl = same or lower (but not
> >> higher)) @wavy @significative letters @curved (anticlockwise,
> >> clockwise) @angular (plain, v-shaped, staircase) (was @angled)
> >> @liquescence @episema @extended @tilt {n|ne|e|se|s|sw|w|ne} (north,
> >> northeast, etc.) @quilisma (2, 3, or 4 curves) @oriscus (curved,
> >> flat, jagged) @con (gapped, looped) (connection to the previous <nc>
> >> within the same <neume>)
> >>
> >> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and
> @hispanicLoop from the <neume> level.
> >>
> >> _______________________________________________
> >> mei-neumes-ig mailing list
> >>
> >> mei-neumes-ig at lists.uni-paderborn.de
> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> >
> > --
> >
> > Notengrafik Berlin GmbH
> > HRB 15007
> >
> > UstID: DE 289234097
> > Geschäftsführer:
> > Thomas Weber und Werner J. Wolff
> >
> > fon: +49 30 220661685
> >
> > Leuschnerdamm 13
> > 10999 Berlin
> >
> > notengrafik.com
> >
> > _______________________________________________
> > mei-neumes-ig mailing list
> > mei-neumes-ig at lists.uni-paderborn.de
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig

From stefan.morent at uni-tuebingen.de  Fri Sep 22 12:56:51 2017
From: stefan.morent at uni-tuebingen.de (Prof. Dr. Morent)
Date: Fri, 22 Sep 2017 12:56:51 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <59C3AB11020000E30006742C@gwia01.uni-wuerzburg.de>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
 <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
 <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>
 <59C3AB11020000E30006742C@gwia01.uni-wuerzburg.de>
Message-ID: <20170922125651.Horde.KU9pknlFsI5FhW8Rhs1b6Km@webmail.uni-tuebingen.de>

  I would agree with the idea to encode the logical concept behind  
neume signs, considering the individual visual appearance as a "font"  
used by scribes within various traditions over time and space and  
within these traditions to express individual meaning.

Even if "producta" sounds probably unfamiliar to most chant scholars  
as to now it has the advantage to have a historical-theoretical  
background compared to the (modern invention) "tractulus".

I would however be cautious with terms like "longer", "duration" ...  
perhaps something like "light"/"heavy", "more emphasized", "strong"  
... would be more appropriate?

best Stefan

----- Nachricht von Elaine Stratton Hild  
<elaine.stratton_hild at uni-wuerzburg.de> ---------
     Datum: Thu, 21 Sep 2017 14:05:37 +0200
       Von: Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de>
Antwort an: Neumes Interest Group of the Music Encoding Initiative  
<mei-neumes-ig at lists.uni-paderborn.de>
   Betreff: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
        An: mei-neumes-ig at lists.uni-paderborn.de

> Thanks so much for your time, Andrew (and all!).  My answers are  
> below, marked with *. 
>
>    All best wishes,
>    Elaine
>  
>
>         
>      
>      
>     Dr. Elaine Stratton Hild
>     Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
>          Julius-Maximilians-Universität Würzburg
> Institut für Musikforschung
> Domerschulstraße 13
> D-97070 Würzburg            
>        
>
>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 9:24 PM >>>
> Thank you, Elaine! This clarifies a few things.
>
> "Shape" is a term I borrowed from the process of data modelling to  
> mean two objects which share the same properties and values, but  
> which may be completely different instances of something. Two houses  
> with one door and 10 windows could be said to have the same 'data  
> shape', and it doesn't matter if one is a bungalow and one a skinny  
> three-story Dutch house, and one is called a 'house' and another a  
> 'huis'.
>
> In this case, it simply means that two things that have a pitch  
> contour of "up-then-down," for example, must be instances of the  
> same class of things regardless of any particular name or identifier  
> attached to them. The thing is defined by its properties, and not by  
> a name that is given to it.
>      
>     ***Thank you for the explanation!
>
> Perhaps you could clarify a few things about the functioning of your  
> proposed elements. It seems that there are properties of these  
> symbols that are non-exclusive, and that a single symbol can carry  
> with it multiple dimensions of description.
>
> As an encoder, when would I choose to use a 'gravis' over a 'puncta'  
> if they can both mean 'lower' pitch? 
>      
>     ***These terms refer to different signs, different visual forms  
> on the page. A gravis looks different than a punctus. (Gravis looks  
> like \ while punctus looks like a period . In O splendidissima, the  
> first notational sign above the syllable "splen" is an acuta  
> connected to a gravis; two punctus are visible above the syllable  
> "di")  A musicologist encoding the notation can record the basic  
> visual forms with the terms gravis, acuta, punctus, producta. The  
> meanings of these signs will need to encoded separately, because the  
> meanings depend, to some extent, on context of the surrounding signs  
> (which a musicologist can interpret). A punctus can mean "lower than  
> preceding pitch" or it could also be slightly more ambiguous--it  
> could mean "same or lower than the preceding pitch." 
>      
>      I understand that only puncta can be 'same or lower' but it  
> seems, on the face of it, that there might be some confusion about  
> when to use each. It also seems like there are three signs available  
> to encode the 'same' pitch, two for 'lower', and only one for  
> 'higher.' 
>      
>     ***When choosing which basic sign to encode, the musicologist  
> will follow the scribe's use of the signs. Yes, you're right,  
> different signs were used to convey the same information about pitch  
> content. Conveying information about pitch content was not the only  
> (or even the most important) aspect of notation for many medieval  
> scribes. They used different forms to show different aspects of  
> performance, and that's why it's important for us to be able to  
> encode both the graphic signs (the visual domain) as well as the  
> meanings we can glean from the scribe's use of the signs (the  
> logical domain).  Returning to O splendidissima, the "lower" pitches  
> the scribe wrote with punctus were probably performed shorter, or  
> "lighter" than the the "lower" pitch recorded with the gravis. A  
> musicologist should be able to add as much of this nuanced  
> performance information that she wants, depending on her  
> understanding of the notation and her desire for detail.
>      
>      Will this cover the range of pitch movements necessary in the  
> repertoires?
>      
>     ***We need the options of neutral (or unknown), same, lower,  
> same or lower, higher, same or higher. In some cases, a scribe will  
> modify a sign to give additional information concerning pitch  
> content. For instance, a scribe sometimes wrote a gravis longer,  
> visually--extending down further than usual. (The gravis over  
> "splen" happens to be one example.) The information about melodic  
> interval is still "lower than previous pitch", but the musicologist  
> might want to record the additional visual information (extended)  
> and also record the meaning she attributes to the scribe's  
> modification ("lower than the previous pitch by a third or more").  
>  (In the case of O splendidissima, because the scribe used a staff,  
> we can record absolute pitch levels--the descent of "g" to "e".)
>
> Both 'puncta' and 'producta' also seem to have an impact on  
> duration, which I think should be clearly separated from pitch. Is  
> there any way to separate the duration implications out from them?  
> If we remove duration from the meaning of the sign (and encode it in  
> a separate attribute), are 'punctus' and 'productus' effectively the  
> same thing? 
>      
>     ****We would still differentiate between punctus and producta to  
> reflect the sign the scribe used (for our visual domain). Yes, I  
> think we absolutely should record the duration implications  
> separately, because some scribes used "producta" as the standard  
> sign for "lower" and "same or lower" pitches, while other scribes  
> used "punctus" as the standard and only used "producta" in special  
> situations, to indicate lengthened duration. I think Thomas Weber  
> was considering suggesting the @dur attribute  
> (data.DURATION.neumes) with the values "longer" and "shorter". 
>
> Is there a sign for 'same or higher with longer duration'? Is that necessary?
>      
>     **No, there's no basic sign for that. To show a higher pitch  
> with longer duration, a scribe would add an episema to the acuta, or  
> add a significative letter "t" (tenere) next to the acuta. The  
> proposal from Thomas Weber and me would allow a significative letter  
> element and using the @dur attribute (longer and shorter duration)  
> to record the meaning of the scribe's use of episema and  
> significative letters.
>
> Is there a reason the 'neume' element has been replaced with 'ncg'  
> in the supplied encoding?
>      
>     ***Yes! We are trying to make the Neumes Module revision  
> comfortable for all musicologists. The term neume can mean different  
> things, depending on the context in which it is used, and the  
> musicologist. Neume component grouping is clearly a technical term,  
> specific to the encoding, that will not cause confusion for chant  
> scholars.
>
> Cheers!
> -Andrew
>
>> On 20 Sep 2017, at 16:55, Elaine Stratton Hild  
>> <elaine.stratton_hild at uni-wuerzburg.de> wrote:
>>
>> Dear All,
>>
>> Thank you for your work on this.
>>
>> I agree completely, Andrew, that the neume names should be able to  
>> be included in the encoding, but the encoding should not depend on  
>> them. A quick thought concerning your suggestion below… “neume  
>> name” (rather than “neume type” would probably be more specific and  
>> clearer to musicologists (like me!) using the module.
>>
>> Just to clarify… the proposal Thomas Weber and I have put forward  
>> does not rely upon neume names. The designations we recommend  
>> (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the  
>> earliest historical designations for notational signs, and—most  
>> importantly—they are not limited to one notational type. (Perhaps  
>> this is along the lines of what you meant with "data shapes",  
>> Andrew?)
>>
>> They designate basic shapes that themselves convey basic  
>> information (acuta = one note with the same or higher pitch; gravis  
>> = one note with lower pitch; punctus = one note with same or lower  
>> pitch and normal duration; producta = one note with same or lower  
>> pitch and longer duration).
>>
>> They are especially convenient for encoding because they can be  
>> combined to create all the notational signs of all types medieval  
>> notation.
>>
>> (Small historical detour... For the writer of the 10th century  
>> treatise where these terms are first used for musical notation, the  
>> signs formed binary oppositions to each other: “Acuta” and “gravis”  
>> were drawn from the study of grammar, with the acuta placed over  
>> vowels where the voice rose in pitch and the gravis placed with  
>> syllables where the voice fell in pitch. “Punctus” and “producta”  
>> are symbols drawn from verse analysis: short syllables in Latin  
>> were marked with punctus; long syllables were marked with producta.)
>>
>> We suggest using these designations (as basic "data shapes"),  
>> rather than the tilt attribute, because the basic meaning conveyed  
>> by an acuta (the logical domain) remains consistent across all  
>> medieval notations, but the nuanced tilt of the sign (the visual  
>> domain, whether it’s written “north” or “northeast”, for example)  
>> varies with individual scribes.
>>
>> Many thanks and all best wishes,
>> Elaine
>>
>>
>>
>>
>>
>>
>> Dr. Elaine Stratton Hild
>> Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters
>> Julius-Maximilians-Universität Würzburg
>> Institut für Musikforschung
>> Domerschulstraße 13
>> D-97070 Würzburg
>>
>>
>> >>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
>> Hi Thomas,
>>
>> Thanks for this, and spending time putting forward some concrete  
>> suggestions.
>>
>> I'm also of the opinion that the current proposal has a significant  
>> bias towards the visual component. I believe this has emerged  
>> largely because the exact musical content of some repertoires is  
>> unknown, making a system built on a "logical" domain approach to  
>> musical description difficult to define. (that is, when all you  
>> have a symbol that is angled, and you don't even know what pitch it  
>> is, how do you describe it musically?) That said, I think it's  
>> worthwhile to try and tug the existing proposal in the direction of  
>> addressing and describing the musical content directly.
>>
>> I have been under the impression that building a system built on  
>> explicit naming of neumes as elements would not be a good idea,  
>> based on critiques I have heard on the existing neume module. The  
>> same neume can have many names (across styles or languages) and  
>> building a system on neume names makes it more difficult to  
>> accurately capture the longer non-standard (i.e., "compound")  
>> neumes. Thus the reason for building a system based on shape  
>> contour, rather than shape name.
>>
>> That isn't to say that names are not a valuable thing to encode,  
>> but the idea is that these names would be included in a separate  
>> taxonomy within the file (or even a separate controlled vocabulary)  
>> that might be referenced within an encoding. I think this will go  
>> further towards making a general encoding system for all neumed  
>> repertoires, instead of narrowing it down to a particular style.
>>
>> You might imagine something along the lines of:
>>
>> <neume type="#clivis">
>> ...
>> </neume>
>>
>> or
>>
>> <neume type="http://example.org/neumevocabulary#clivis">
>> ...
>> </neume>
>>
>> This would let you use your own controlled vocabulary to name  
>> things for your own encoding, while maintaining a more general  
>> 'data shape' for the musical structures, allowing them to be  
>> compared across repertoires.
>>
>> -Andrew
>>
>> > On 20 Sep 2017, at 15:26, Thomas Weber  
>> <thomas.weber at notengrafik.com> wrote:
>> >
>> > Dear group,
>> >
>> >
>> > Elaine and me looked at both the Hildegard example as well as the  
>> "standard" neumes table by Cardine and made an attempt at encoding  
>> the signs' properties with better separation of domains. We tried  
>> to add more logical domain information to the previously mostly  
>> graphical domain info.
>> >
>> > Our thesis was that the main distinguishing factor between  
>> different use cases of the Neumes module is in how much detail the  
>> notation should be described. Many projects right now use the  
>> Volpiano font to capture only the melodic contour and potentially  
>> connection information. For Corpus monodicum, we want to encode  
>> more properties of single staff-bound components, mainly whether a  
>> component is an oriscus, quilisma or strophicus. Our understanding  
>> is that the Old Hispanic project as well as the Optical Neumes  
>> Recognition project need even more detailed information to be  
>> encodable.
>> >
>> > We came to the conclusion that the problem we still need to solve  
>> is better separation of visual and logical domains. Our impression  
>> is that the visual domain is of primary importance for both of the  
>> named projects. That might be the reason why the current draft  
>> seems to mainly focus on the visual domain.
>> >
>> > We prepared the following table based on Cardine that outlines  
>> our suggested encoding.
>> >
>> >  
>> http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
>> >
>> > The most obvious addition are sub-elements describing each <nc>  
>> as one of the seven basic single pitch signs (four basic signs  
>> based on Anonymus Vaticanus: acuta, gravis, punctus, producta;  
>> three special signs: quilisma, oriscus, strophicus). We chose to  
>> make them elements so that each of those can get its specific set  
>> of attributes describing them in more detail, like "extended" for  
>> acuta/gravis (understood to indicate larger intervals) or "waves"  
>> for quilisma. The idea behind that was to make it clearer which  
>> attributes are usable in which contexts, but this could also be  
>> done by means of Schematron rules when using attributes instead of  
>> elements - which we did in our pre-Graz state of ideas:
>> >
>> >  
>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
>> >  
>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
>> >
>> > We suggest to represent the "angled" property using the @con  
>> attribute, as "angularity" is a property of the connection.  
>> Depending on the sign, the logical meaning of this would be to  
>> lengthen the component before or after the angled connection. This  
>> logical domain info could be recorded using @dur on the proper <nc>.
>> >
>> > We picked up Ich's encoding of "O splendidissima" and made a  
>> modified version here:
>> >
>> > http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
>> >
>> > Here we also tried to illustrate how more detailed visual domain  
>> information could added, namely the suggested @tilt. As the tilt is  
>> in most cases a consistent scribal idiosyncrasy, this might however  
>> better be solved using the tables of signs that Stefan Morent  
>> reminded us of recently. There, these idiosyncrasies could be  
>> described once for an entire file, source or hand. Johannes (hi to  
>> Johannes in CC) suggested that these "standard" patterns of writing  
>> might be best put in <scoreDef> and to encode deviations where they  
>> occur. These tables could also be useful to document variation  
>> among tokens.
>> >
>> > We suggest to keep the table problem and how to link between the  
>> content and the tables (by semi-standardized names, by project  
>> specific naming/numbering schemes or by simple XML IDs, or maybe  
>> implicitly by characteristic sequence of single pitch signs) for  
>> later discussion, together with other topics like how to represent  
>> mi signs and rubrics.
>> >
>> > We wish you a fruitful workshop in Halifax, and we are looking  
>> forward to hearing about any outcome concerning the neumes module!
>> > Thomas
>> >
>> >
>> > Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>> >> Here’s what I have for the draft of the proposal for the new MEI  
>> Neumes Module schema.
>> >> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>> >>
>> >> For ease of discussion and efficiency, please discuss one issue  
>> at a time in separate email threads, e.g., Re: @oriscus.
>> >>
>> >> Thanks,
>> >>
>> >> Ichiro
>> >>
>> >> ==============================
>> >> MEI Neumes Module Draft, Version 0.2
>> >>
>> >> A <neume> element consists of one or more <nc> element(s).
>> >>
>> >> A <nc> (neume component) is a single pitched event, although the  
>> exact pitch may not be known.
>> >>
>> >> Attributes for <neume>:
>> >> @intm (interval melodic; relative to the previous <neume>)  
>> {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n =  
>> neutral/unknown, sh = same or higher (but not lower), sl = same or  
>> lower (but not higher))
>> >> @significative letters
>> >> @hispanicTick (type1, type2)
>> >> @hook
>> >>
>> >> Attributes for <nc>:
>> >> @pname
>> >> @oct
>> >> @intm (interval melodic; relative to the previous <neume>)  
>> {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown,  
>> sh = same or higher (but not lower), sl = same or lower (but not  
>> higher))
>> >> @wavy
>> >> @significative letters
>> >> @curved (anticlockwise, clockwise)
>> >> @angular (plain, v-shaped, staircase) (was @angled)
>> >> @liquescence
>> >> @episema
>> >> @extended
>> >> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>> >> @quilisma (2, 3, or 4 curves)
>> >> @oriscus (curved, flat, jagged)
>> >> @con (gapped, looped) (connection to the previous <nc> within  
>> the same <neume>)
>> >>
>> >> Removed from the previous version: @jagged, @flat, @long,  
>> @diagonalright, and @hispanicLoop from the <neume> level.
>> >>
>> >> _______________________________________________
>> >> mei-neumes-ig mailing list
>> >>
>> >> mei-neumes-ig at lists.uni-paderborn.de
>> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>> >
>> > --
>> >
>> > Notengrafik Berlin GmbH
>> > HRB 15007
>> >
>> > UstID: DE 289234097
>> > Geschäftsführer:
>> > Thomas Weber und Werner J. Wolff
>> >
>> > fon: +49 30 220661685
>> >
>> > Leuschnerdamm 13
>> > 10999 Berlin
>> >
>> > notengrafik.com
>> >
>> > _______________________________________________
>> > mei-neumes-ig mailing list
>> > mei-neumes-ig at lists.uni-paderborn.de
>> > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>
>> _______________________________________________
>> mei-neumes-ig mailing list
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>> _______________________________________________
>> mei-neumes-ig mailing list
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig

----- Ende der Nachricht von Elaine Stratton Hild  
<elaine.stratton_hild at uni-wuerzburg.de> -----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170922/8ce36356/attachment.html>

From elaine.stratton_hild at uni-wuerzburg.de  Fri Sep 22 20:49:35 2017
From: elaine.stratton_hild at uni-wuerzburg.de (Elaine Stratton Hild)
Date: Fri, 22 Sep 2017 20:49:35 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <20170922125651.Horde.KU9pknlFsI5FhW8Rhs1b6Km@webmail.uni-tuebingen.de>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
 <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
 <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>
 <59C3AB11020000E30006742C@gwia01.uni-wuerzburg.de>
 <20170922125651.Horde.KU9pknlFsI5FhW8Rhs1b6Km@webmail.uni-tuebingen.de>
Message-ID: <59C55B3F020000E3000675B4@gwia01.uni-wuerzburg.de>


















Dear Stefan and all,


 


Thank you so much for the message and feedback.


 


Yes, for the encoding, I think the terms from the 10th
century Anonymous Vaticanus will work better than neume names, for several
reasons:



* the author of the treatise already did some of the
abstraction work that we also need to do, in order to encode: he describes the
component elements of the notational signs and their basic meanings
* his terms are contemporary with the earliest notation,
unlike the neume names, which first appear in the 12th century
* his terms can be used with all neumatic notation (unlike the
neume names, which only describe a limited selection of notational signs)











Thank you also for suggesting other interpretations (and
adjectives to use for the attribute values) of the episema and tractulus. Your
point shows the importance of being able to encode the visual domain (the
presence of an episema, for example) 
separately from the logical domain (the meaning a musicologist
associates with the episema). 


 


To what extent should we try to standardize these interpretations
of notation in the encoding’s logical domain? In other words, does the MEI
Special Interest Neumes Group need to decide now on the logical domain, the
scribe’s meaning, of an episema? If we answer yes, I’m afraid this could slow
down or stall the process of revising the module, because we would need to
agree not only on episema, but also on significative letters and angular
modifications for multiple individual signs… And would it keep other
musicologists from wanting to use the module if the more subjective layers of
performance information were automatically associated with the encoding of the more-easily-agreed-upon
visual domain? 


 


Thomas Weber and I were thinking that it would be good to allow
the option of recording only the basic signs and the basic information
concerning their connections and relative pitch (or absolute pitch, if a staff
is involved). And then, each musicologist could decide on how much of the
nuanced performance information to include in the logical domain of the
encoding. 


 


What if one musicologist understood an angled pes to
indicate a longer duration of the first note, and another musicologist
understood it to indicate a heavier, or more emphasized performance of the
first note, and another musicologist might want neither such interpretation to
be included? Knowing that musicologists will have slightly different
interpretations—with good reasons!—and that even the same musicologist might
choose a slightly different interpretation, depending on the repertory and the
scribe, maybe it’s best to allow multiple options for the attribute values in
the logical domain of the episema and angular modifications.  


 


For significative letters “c” and “t” it will be easier,
perhaps? Could we just use English translations of the Latin words?


 


I think that such level of detail—the nuanced performance
information that may or may not be present in neumatic notation—should be
optional in our encoding. It seems important to remember that the absence of an
element, like an episema, does not carry the same information as its presence.
In other words, if a scribe wrote an acuta with episema, he was indicating
something different about its performance—longer, or heavier—but an acuta
without an episema is usually ambiguous. The acuta might have had a “normal”
performance, or it might have had a longer, or heavier performance. We don’t
usually know. In many instances, it could just be that the scribe was using a
less-detailed type of notation. Just as the scribes didn’t always want to
“encode” down to a detailed level, we should allow ourselves the flexibility of
encoding differing levels of details.  


 


I’ll look forward to hearing what you all think.


 


Many thanks and all best wishes,


Elaine
   





Julius-Maximilians-Universität Würzburg
Institut für Musikforschung
Domerschulstraße 13
D-97070 Würzburg





>>> "Prof. Dr. Morent" <stefan.morent at uni-tuebingen.de> 09/22/17 12:57 PM >>>
  I would agree with the idea to encode the logical concept behind neume signs, considering the individual visual
appearance as a "font" used by scribes within various traditions over time and space and within these traditions to
express individual meaning.
 
 Even if "producta" sounds probably unfamiliar to most chant scholars as to now it has the advantage to have a
historical-theoretical background compared to the (modern invention) "tractulus".
 
 I would however be cautious with terms like "longer", "duration" ... perhaps something like "light"/"heavy", "more
emphasized", "strong" ... would be more appropriate?
 
 best Stefan
 
 ----- Nachricht von Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> ---------
      Datum: Thu, 21 Sep 2017 14:05:37 +0200
        Von: Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de>
 Antwort an: Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-paderborn.de>
    Betreff: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
         An: mei-neumes-ig at lists.uni-paderborn.de
    Thanks so much for your time, Andrew (and all!).  My answers are below, marked with *. 
 
  All best wishes,
  Elaine
 

 
 
    
   
   
  Dr. Elaine Stratton Hild
  Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
   Julius-Maximilians-Universität Würzburg
 Institut für Musikforschung
 Domerschulstraße 13
 D-97070 Würzburg   
   
 
 
 >>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 9:24 PM >>>
 Thank you, Elaine! This clarifies a few things.
 
 "Shape" is a term I borrowed from the process of data modelling to mean two objects which share the same properties and
values, but which may be completely different instances of something. Two houses with one door and 10 windows could be
said to have the same 'data shape', and it doesn't matter if one is a bungalow and one a skinny three-story Dutch house,
and one is called a 'house' and another a 'huis'.
 
 In this case, it simply means that two things that have a pitch contour of "up-then-down," for example, must be
instances of the same class of things regardless of any particular name or identifier attached to them. The thing is
defined by its properties, and not by a name that is given to it.
   
  ***Thank you for the explanation!
 
 Perhaps you could clarify a few things about the functioning of your proposed elements. It seems that there are
properties of these symbols that are non-exclusive, and that a single symbol can carry with it multiple dimensions of
description.
 
 As an encoder, when would I choose to use a 'gravis' over a 'puncta' if they can both mean 'lower' pitch? 
   
  ***These terms refer to different signs, different visual forms on the page. A gravis looks different than a punctus.
(Gravis looks like \ while punctus looks like a period . In O splendidissima, the first notational sign above the
syllable "splen" is an acuta connected to a gravis; two punctus are visible above the syllable "di")  A musicologist
encoding the notation can record the basic visual forms with the terms gravis, acuta, punctus, producta. The meanings of
these signs will need to encoded separately, because the meanings depend, to some extent, on context of the surrounding
signs (which a musicologist can interpret). A punctus can mean "lower than preceding pitch" or it could also be slightly
more ambiguous--it could mean "same or lower than the preceding pitch." 
   
   I understand that only puncta can be 'same or lower' but it seems, on the face of it, that there might be some
confusion about when to use each. It also seems like there are three signs available to encode the 'same' pitch, two for
'lower', and only one for 'higher.' 
   
  ***When choosing which basic sign to encode, the musicologist wiright, different signs were used to convey the same information about pitch content. Conveying information about pitch
content was not the only (or even the most important) aspect of notation for many medieval scribes. They used different
forms to show different aspects of performance, and that's why it's important for us to be able to encode both the
graphic signs (the visual domain) as well as the meanings we can glean from the scribe's use of the signs (the logical
domain).  Returning to O splendidissima, the "lower" pitches the scribe wrote with punctus were probably performed
shorter, or "lighter" than the the "lower" pitch recorded with the gravis. A musicologist should be able to add as much
of this nuanced performance information that she wants, depending on her understanding of the notation and her desire
for detail.
   
   Will this cover the range of pitch movements necessary in the repertoires?
   
  ***We need the options of neutral (or unknown), same, lower, same or lower, higher, same or higher. In some cases, a
scribe will modify a sign to give additional information concerning pitch content. For instance, a scribe sometimes
wrote a gravis longer, visually--extending down further than usual. (The gravis over "splen" happens to be one example.)
The information about melodic interval is still "lower than previous pitch", but the musicologist might want to record
the additional visual information (extended) and also record the meaning she attributes to the scribe's modification
("lower than the previous pitch by a third or more").  (In the case of O splendidissima, because the scribe used a
staff, we can record absolute pitch levels--the descent of "g" to "e".)
 
 Both 'puncta' and 'producta' also seem to have an impact on duration, which I think should be clearly separated from
pitch. Is there any way to separate the duration implications out from them? If we remove duration from the meaning of
the sign (and encode it in a separate attribute), are 'punctus' and 'productus' effectively the same thing? 
   
  ****We would still differentiate between punctus and producta to reflect the sign the scribe used (for our visual
domain). Yes, I think we absolutely should record the duration implications separately, because some scribes used
"producta" as the standard sign for "lower" and "same or lower" pitches, while other scribes used "punctus" as the
standard and only used "producta" in special situations, to indicate lengthened duration. I think Thomas Weber was
considering suggesting the @dur attribute (data.DURATION.neumes) with the values "longer" and "shorter". 
  
 Is there a sign for 'same or higher with longer duration'? Is that necessary?
   
  **No, there's no basic sign for that. To show a higher pitch with longer duration, a scribe would add an episema to
the acuta, or add a significative letter "t" (tenere) next to the acuta. The proposal from Thomas Weber and me would
allow a significative letter element and using the @dur attribute (longer and shorter duration) to record the meaning of
the scribe's use of episema and significative letters.
 
 Is there a reason the 'neume' element has been replaced with 'ncg' in the supplied encoding?
   
  ***Yes! We are trying to make the Neumes Module revision comfortable for all musicologists. The term neume can mean
different things, depending on the context in which it is used, and the musicologist. Neume component grouping is
clearly a technical term, specific to the encoding, that will not cause confusion for chant scholars.
 
 Cheers!
 -Andrew
 
 > On 20 Sep 2017, at 16:55, Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> wrote:
 >
 > Dear All,
 >
 > Thank you for your work on this.
 >
 > I agree completely, Andrew, that the neume names should be able to be included in the encoding, but the encoding
should not depend on them. A quick thought concerning your suggestion below… “neume name” (rather than “neume type”
would probably be more specific and clearer to musicologists (like me > Just to clarify… the proposal Thomas Weber and I have put forward does not rely upon neume names. The designations we
recommend (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the earliest historical designations for notational
signs, and—most importantly—they are not limited to one notational type. (Perhaps this is along the lines of what you
meant with "data shapes", Andrew?)
 >
 > They designate basic shapes that themselves convey basic information (acuta = one note with the same or higher pitch;
gravis = one note with lower pitch; punctus = one note with same or lower pitch and normal duration; producta = one note
with same or lower pitch and longer duration).
 >
 > They are especially convenient for encoding because they can be combined to create all the notational signs of all
types medieval notation.
 >
 > (Small historical detour... For the writer of the 10th century treatise where these terms are first used for musical
notation, the signs formed binary oppositions to each other: “Acuta” and “gravis” were drawn from the study of grammar,
with the acuta placed over vowels where the voice rose in pitch and the gravis placed with syllables where the voice
fell in pitch. “Punctus” and “producta” are symbols drawn from verse analysis: short syllables in Latin were marked with
punctus; long syllables were marked with producta.)
 >
 > We suggest using these designations (as basic "data shapes"), rather than the tilt attribute, because the basic
meaning conveyed by an acuta (the logical domain) remains consistent across all medieval notations, but the nuanced tilt
of the sign (the visual domain, whether it’s written “north” or “northeast”, for example) varies with individual
scribes.
 >
 > Many thanks and all best wishes,
 > Elaine
 >
 >
 >
 >
 >
 >
 > Dr. Elaine Stratton Hild
 > Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters
 > Julius-Maximilians-Universität Würzburg
 > Institut für Musikforschung
 > Domerschulstraße 13
 > D-97070 Würzburg
 >
 >
 > >>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
 > Hi Thomas,
 >
 > Thanks for this, and spending time putting forward some concrete suggestions.
 >
 > I'm also of the opinion that the current proposal has a significant bias towards the visual component. I believe this
has emerged largely because the exact musical content of some repertoires is unknown, making a system built on a
"logical" domain approach to musical description difficult to define. (that is, when all you have a symbol that is
angled, and you don't even know what pitch it is, how do you describe it musically?) That said, I think it's worthwhile
to try and tug the existing proposal in the direction of addressing and describing the musical content directly.
 >
 > I have been under the impression that building a system built on explicit naming of neumes as elements would not be a
good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across
styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer
non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape
name.
 >
 > That isn't to say that names are not a valuable thing to encode, but the idea is that these names would be included
in a separate taxonomy within the file (or even a separate controlled vocabulary) that might be referenced within an
encoding. I think this will go further towards making a general encoding system for all neumed repertoires, instead of
narrowing it down to a particular style.
 >
 > You might imagine something along the lines of:
 >
 > <neume type="#clivis">
 > ...
 > </neume>
 >
 > or
 >
 > <neume type="http://example.org/neumevocabulary#clivis">
 > ...
 > </neume>
 >
 > This would let you use your own controlled vocabulary to name things for your own encoding, while maintaining general 'data shape' for the musical structures, allowing them to be compared across repertoires.
 >
 > -Andrew
 >
 > > On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
 > >
 > > Dear group,
 > >
 > >
 > > Elaine and me looked at both the Hildegard example as well as the "standard" neumes table by Cardine and made an
attempt at encoding the signs' properties with better separation of domains. We tried to add more logical domain
information to the previously mostly graphical domain info.
 > >
 > > Our thesis was that the main distinguishing factor between different use cases of the Neumes module is in how much
detail the notation should be described. Many projects right now use the Volpiano font to capture only the melodic
contour and potentially connection information. For Corpus monodicum, we want to encode more properties of single
staff-bound components, mainly whether a component is an oriscus, quilisma or strophicus. Our understanding is that the
Old Hispanic project as well as the Optical Neumes Recognition project need even more detailed information to be
encodable.
 > >
 > > We came to the conclusion that the problem we still need to solve is better separation of visual and logical
domains. Our impression is that the visual domain is of primary importance for both of the named projects. That might be
the reason why the current draft seems to mainly focus on the visual domain.
 > >
 > > We prepared the following table based on Cardine that outlines our suggested encoding.
 > >
 > > http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
 > >
 > > The most obvious addition are sub-elements describing each <nc> as one of the seven basic single pitch signs (four
basic signs based on Anonymus Vaticanus: acuta, gravis, punctus, producta; three special signs: quilisma, oriscus,
strophicus). We chose to make them elements so that each of those can get its specific set of attributes describing them
in more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or "waves" for quilisma. The
idea behind that was to make it clearer which attributes are usable in which contexts, but this could also be done by
means of Schematron rules when using attributes instead of elements - which we did in our pre-Graz state of ideas:
 > >
 > > http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
 > > http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
 > >
 > > We suggest to represent the "angled" property using the @con attribute, as "angularity" is a property of the
connection. Depending on the sign, the logical meaning of this would be to lengthen the component before or after the
angled connection. This logical domain info could be recorded using @dur on the proper <nc>.
 > >
 > > We picked up Ich's encoding of "O splendidissima" and made a modified version here:
 > >
 > > http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
 > >
 > > Here we also tried to illustrate how more detailed visual domain information could added, namely the suggested
@tilt. As the tilt is in most cases a consistent scribal idiosyncrasy, this might however better be solved using the
tables of signs that Stefan Morent reminded us of recently. There, these idiosyncrasies could be described once for an
entire file, source or hand. Johannes (hi to Johannes in CC) suggested that these "standard" patterns of writing might
be best put in <scoreDef> and to encode deviations where they occur. These tables could also be useful to document
variation among tokens.
 > >
 > > We suggest to keep the table problem and how to link between the content and the tables (by semi-standardized
names, by project specific naming/numbering schemes or by simple XML IDs, or maybe implicitly by characteristic sequence
of single pitch signs) for later discussion, together with other topics like how to represent mi signs and rubrics.
 > >
 > > We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about any outcome concerning the
neumes module!
 > > Thomas
 > >
 > >
 > > Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
 > >> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
 > >> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
 > >>
 > >> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re:
@oriscus.
 > >>
 > >> Thanks,
 > >>
 > >> Ichiro
 > >>
 > >> ==============================
 > >> MEI Neumes Module Draft, Version 0.2
 > >>
 > >> A <neume> element consists of one or more <nc> element(s).
 > >>
 > >> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
 > >>
 > >> Attributes for <neume>:
 > >> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n
= neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
 > >> @significative letters
 > >> @hispanicTick (type1, type2)
 > >> @hook
 > >>
 > >> Attributes for <nc>:
 > >> @pname
 > >> @oct
 > >> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n =
neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
 > >> @wavy
 > >> @significative letters
 > >> @curved (anticlockwise, clockwise)
 > >> @angular (plain, v-shaped, staircase) (was @angled)
 > >> @liquescence
 > >> @episema
 > >> @extended
 > >> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
 > >> @quilisma (2, 3, or 4 curves)
 > >> @oriscus (curved, flat, jagged)
 > >> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
 > >>
 > >> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume>
level.
 > >>
 > >> _______________________________________________
 > >> mei-neumes-ig mailing list
 > >>
 > >> mei-neumes-ig at lists.uni-paderborn.de
 > >> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
 > >
 > > --
 > >
 > > Notengrafik Berlin GmbH
 > > HRB 15007
 > >
 > > UstID: DE 289234097
 > > Geschäftsführer:
 > > Thomas Weber und Werner J. Wolff
 > >
 > > fon: +49 30 220661685
 > >
 > > Leuschnerdamm 13
 > > 10999 Berlin
 > >
 > > notengrafik.com
 > >
 > > _______________________________________________
 > > mei-neumes-ig mailing list
 > > mei-neumes-ig at lists.uni-paderborn.de
 > > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
 >
 > _______________________________________________
 > mei-neumes-ig mailing list
 > mei-neumes-ig at lists.uni-paderborn.de
 > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
 > _______________________________________________
 > mei-neumes-ig mailing list
 > mei-neumes-ig at lists.uni-paderborn.de
 > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
 
 _______________________________________________
 mei-neumes-ig mailing list
 mei-neumes-ig at lists.uni-paderborn.de
 https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
 
 
  
 
 
 ----- Ende der Nachricht von Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> -----
 
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170922/fba79f54/attachment.html>

From inga.behrendt at uni-tuebingen.de  Sat Sep 23 02:58:43 2017
From: inga.behrendt at uni-tuebingen.de (Inga Behrendt)
Date: Sat, 23 Sep 2017 02:58:43 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <20170922125651.Horde.KU9pknlFsI5FhW8Rhs1b6Km@webmail.uni-tuebingen.de>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
 <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
 <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>
 <59C3AB11020000E30006742C@gwia01.uni-wuerzburg.de>
 <20170922125651.Horde.KU9pknlFsI5FhW8Rhs1b6Km@webmail.uni-tuebingen.de>
Message-ID: <20170923025843.Horde.xA3uieqtWddM-gaOVEnjRVR@webmail.uni-tuebingen.de>


Dear Thomas, dear Elaine,

we talked today about your suggestions during our Cantus Ultimus-Workshop.
(1) And it ended up saying that we think that terms like "acuta",  
"gravis", "punctum" fit to SOME notations, but not to ALL. However, we  
are trying to find a MEI Neumes Module Schema that covers all  
different kinds of neume notations. For example, Elsa de Luca, our  
expert in Old Hispanic Neume Notation, said that she cannot use such  
names for her signs.
And we all agreed that - if we want to create a Module Schema that we  
can use for all nematic notations - than we need to be very careful in  
the choice of names. So, I think, everybody in the Cantus Ultimus  
group would underline Andrew´s words from his previous mail:

"I have been under the impression that building a system built on  
explicit naming of neumes as elements would not be a good idea, based  
on critiques I have heard on the existing neume module. The same neume  
can have many names (across styles or languages) and building a system  
on neume names makes it more difficult to accurately capture the  
longer non-standard (i.e., "compound") neumes. Thus the reason for  
building a system based on shape contour, rather than shape name."

(2) Andrew mentioned the other point to your questions ("I'm also of  
the opinion that the current proposal has a significant bias towards  
the visual component,"). We are in the moment describing the shape of  
the notation signs rather than giving names. And long discussions let  
us think in the end that is better not to include the meaning of the  
neume sign. We just describe the neume shapes. For example, an  
episema: if it means a longer duration or if it is a modal indication  
or if it shows a semitone within a descending line..., all of this we  
know from different works of colleagues, is not encoded. We KNOW of  
the different meanings. But in order to not determine already now the  
meaning we rather describe the shape.

Herzlich
Inga

Zitat von "Prof. Dr. Morent" <stefan.morent at uni-tuebingen.de>:

> I would agree with the idea to encode the logical concept behind  
> neume signs, considering the individual visual appearance as a  
> "font" used by scribes within various traditions over time and space  
> and within these traditions to express individual meaning.
>
> Even if "producta" sounds probably unfamiliar to most chant scholars  
> as to now it has the advantage to have a historical-theoretical  
> background compared to the (modern invention) "tractulus".
>
> I would however be cautious with terms like "longer", "duration" ...  
> perhaps something like "light"/"heavy", "more emphasized", "strong"  
> ... would be more appropriate?
>
> best Stefan
>
> ----- Nachricht von Elaine Stratton Hild  
> <elaine.stratton_hild at uni-wuerzburg.de> ---------
>      Datum: Thu, 21 Sep 2017 14:05:37 +0200
>        Von: Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de>
> Antwort an: Neumes Interest Group of the Music Encoding Initiative  
> <mei-neumes-ig at lists.uni-paderborn.de>
>    Betreff: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
>         An: mei-neumes-ig at lists.uni-paderborn.de
>
>> Thanks so much for your time, Andrew (and all!).  My answers are  
>> below, marked with *. 
>>
>>  All best wishes,
>>  Elaine
>>  
>>
>>       
>>    
>>    
>>   Dr. Elaine Stratton Hild
>>   Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
>>        Julius-Maximilians-Universität Würzburg
>> Institut für Musikforschung
>> Domerschulstraße 13
>> D-97070 Würzburg            
>>      
>>
>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 9:24 PM >>>
>> Thank you, Elaine! This clarifies a few things.
>>
>> "Shape" is a term I borrowed from the process of data modelling to  
>> mean two objects which share the same properties and values, but  
>> which may be completely different instances of something. Two  
>> houses with one door and 10 windows could be said to have the same  
>> 'data shape', and it doesn't matter if one is a bungalow and one a  
>> skinny three-story Dutch house, and one is called a 'house' and  
>> another a 'huis'.
>>
>> In this case, it simply means that two things that have a pitch  
>> contour of "up-then-down," for example, must be instances of the  
>> same class of things regardless of any particular name or  
>> identifier attached to them. The thing is defined by its  
>> properties, and not by a name that is given to it.
>>    
>>   ***Thank you for the explanation!
>>
>> Perhaps you could clarify a few things about the functioning of  
>> your proposed elements. It seems that there are properties of these  
>> symbols that are non-exclusive, and that a single symbol can carry  
>> with it multiple dimensions of description.
>>
>> As an encoder, when would I choose to use a 'gravis' over a  
>> 'puncta' if they can both mean 'lower' pitch? 
>>    
>>   ***These terms refer to different signs, different visual forms  
>> on the page. A gravis looks different than a punctus. (Gravis looks  
>> like \ while punctus looks like a period . In O splendidissima, the  
>> first notational sign above the syllable "splen" is an acuta  
>> connected to a gravis; two punctus are visible above the syllable  
>> "di")  A musicologist encoding the notation can record the basic  
>> visual forms with the terms gravis, acuta, punctus, producta. The  
>> meanings of these signs will need to encoded separately, because  
>> the meanings depend, to some extent, on context of the surrounding  
>> signs (which a musicologist can interpret). A punctus can mean  
>> "lower than preceding pitch" or it could also be slightly more  
>> ambiguous--it could mean "same or lower than the preceding pitch." 
>>    
>>    I understand that only puncta can be 'same or lower' but it  
>> seems, on the face of it, that there might be some confusion about  
>> when to use each. It also seems like there are three signs  
>> available to encode the 'same' pitch, two for 'lower', and only one  
>> for 'higher.' 
>>    
>>   ***When choosing which basic sign to encode, the musicologist  
>> will follow the scribe's use of the signs. Yes, you're right,  
>> different signs were used to convey the same information about  
>> pitch content. Conveying information about pitch content was not  
>> the only (or even the most important) aspect of notation for many  
>> medieval scribes. They used different forms to show different  
>> aspects of performance, and that's why it's important for us to be  
>> able to encode both the graphic signs (the visual domain) as well  
>> as the meanings we can glean from the scribe's use of the signs  
>> (the logical domain).  Returning to O splendidissima, the "lower"  
>> pitches the scribe wrote with punctus were probably performed  
>> shorter, or "lighter" than the the "lower" pitch recorded with the  
>> gravis. A musicologist should be able to add as much of this  
>> nuanced performance information that she wants, depending on her  
>> understanding of the notation and her desire for detail.
>>    
>>    Will this cover the range of pitch movements necessary in the  
>> repertoires?
>>    
>>   ***We need the options of neutral (or unknown), same, lower, same  
>> or lower, higher, same or higher. In some cases, a scribe will  
>> modify a sign to give additional information concerning pitch  
>> content. For instance, a scribe sometimes wrote a gravis longer,  
>> visually--extending down further than usual. (The gravis over  
>> "splen" happens to be one example.) The information about melodic  
>> interval is still "lower than previous pitch", but the musicologist  
>> might want to record the additional visual information (extended)  
>> and also record the meaning she attributes to the scribe's  
>> modification ("lower than the previous pitch by a third or more").  
>>  (In the case of O splendidissima, because the scribe used a staff,  
>> we can record absolute pitch levels--the descent of "g" to "e".)
>>
>> Both 'puncta' and 'producta' also seem to have an impact on  
>> duration, which I think should be clearly separated from pitch. Is  
>> there any way to separate the duration implications out from them?  
>> If we remove duration from the meaning of the sign (and encode it  
>> in a separate attribute), are 'punctus' and 'productus' effectively  
>> the same thing? 
>>    
>>   ****We would still differentiate between punctus and producta to  
>> reflect the sign the scribe used (for our visual domain). Yes, I  
>> think we absolutely should record the duration implications  
>> separately, because some scribes used "producta" as the standard  
>> sign for "lower" and "same or lower" pitches, while other scribes  
>> used "punctus" as the standard and only used "producta" in special  
>> situations, to indicate lengthened duration. I think Thomas Weber  
>> was considering suggesting the @dur attribute  
>> (data.DURATION.neumes) with the values "longer" and "shorter". 
>>
>> Is there a sign for 'same or higher with longer duration'? Is that  
>> necessary?
>>    
>>   **No, there's no basic sign for that. To show a higher pitch with  
>> longer duration, a scribe would add an episema to the acuta, or add  
>> a significative letter "t" (tenere) next to the acuta. The proposal  
>> from Thomas Weber and me would allow a significative letter element  
>> and using the @dur attribute (longer and shorter duration) to  
>> record the meaning of the scribe's use of episema and significative  
>> letters.
>>
>> Is there a reason the 'neume' element has been replaced with 'ncg'  
>> in the supplied encoding?
>>    
>>   ***Yes! We are trying to make the Neumes Module revision  
>> comfortable for all musicologists. The term neume can mean  
>> different things, depending on the context in which it is used, and  
>> the musicologist. Neume component grouping is clearly a technical  
>> term, specific to the encoding, that will not cause confusion for  
>> chant scholars.
>>
>> Cheers!
>> -Andrew
>>
>>> On 20 Sep 2017, at 16:55, Elaine Stratton Hild  
>>> <elaine.stratton_hild at uni-wuerzburg.de> wrote:
>>>
>>> Dear All,
>>>
>>> Thank you for your work on this.
>>>
>>> I agree completely, Andrew, that the neume names should be able to  
>>> be included in the encoding, but the encoding should not depend on  
>>> them. A quick thought concerning your suggestion below… “neume  
>>> name” (rather than “neume type” would probably be more specific  
>>> and clearer to musicologists (like me!) using the module.
>>>
>>> Just to clarify… the proposal Thomas Weber and I have put forward  
>>> does not rely upon neume names. The designations we recommend  
>>> (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the  
>>> earliest historical designations for notational signs, and—most  
>>> importantly—they are not limited to one notational type. (Perhaps  
>>> this is along the lines of what you meant with "data shapes",  
>>> Andrew?)
>>>
>>> They designate basic shapes that themselves convey basic  
>>> information (acuta = one note with the same or higher pitch;  
>>> gravis = one note with lower pitch; punctus = one note with same  
>>> or lower pitch and normal duration; producta = one note with same  
>>> or lower pitch and longer duration).
>>>
>>> They are especially convenient for encoding because they can be  
>>> combined to create all the notational signs of all types medieval  
>>> notation.
>>>
>>> (Small historical detour... For the writer of the 10th century  
>>> treatise where these terms are first used for musical notation,  
>>> the signs formed binary oppositions to each other: “Acuta” and  
>>> “gravis” were drawn from the study of grammar, with the acuta  
>>> placed over vowels where the voice rose in pitch and the gravis  
>>> placed with syllables where the voice fell in pitch. “Punctus” and  
>>> “producta” are symbols drawn from verse analysis: short syllables  
>>> in Latin were marked with punctus; long syllables were marked with  
>>> producta.)
>>>
>>> We suggest using these designations (as basic "data shapes"),  
>>> rather than the tilt attribute, because the basic meaning conveyed  
>>> by an acuta (the logical domain) remains consistent across all  
>>> medieval notations, but the nuanced tilt of the sign (the visual  
>>> domain, whether it’s written “north” or “northeast”, for example)  
>>> varies with individual scribes.
>>>
>>> Many thanks and all best wishes,
>>> Elaine
>>>
>>>
>>>
>>>
>>>
>>>
>>> Dr. Elaine Stratton Hild
>>> Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters
>>> Julius-Maximilians-Universität Würzburg
>>> Institut für Musikforschung
>>> Domerschulstraße 13
>>> D-97070 Würzburg
>>>
>>>
>>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
>>> Hi Thomas,
>>>
>>> Thanks for this, and spending time putting forward some concrete  
>>> suggestions.
>>>
>>> I'm also of the opinion that the current proposal has a  
>>> significant bias towards the visual component. I believe this has  
>>> emerged largely because the exact musical content of some  
>>> repertoires is unknown, making a system built on a "logical"  
>>> domain approach to musical description difficult to define. (that  
>>> is, when all you have a symbol that is angled, and you don't even  
>>> know what pitch it is, how do you describe it musically?) That  
>>> said, I think it's worthwhile to try and tug the existing proposal  
>>> in the direction of addressing and describing the musical content  
>>> directly.
>>>
>>> I have been under the impression that building a system built on  
>>> explicit naming of neumes as elements would not be a good idea,  
>>> based on critiques I have heard on the existing neume module. The  
>>> same neume can have many names (across styles or languages) and  
>>> building a system on neume names makes it more difficult to  
>>> accurately capture the longer non-standard (i.e., "compound")  
>>> neumes. Thus the reason for building a system based on shape  
>>> contour, rather than shape name.
>>>
>>> That isn't to say that names are not a valuable thing to encode,  
>>> but the idea is that these names would be included in a separate  
>>> taxonomy within the file (or even a separate controlled  
>>> vocabulary) that might be referenced within an encoding. I think  
>>> this will go further towards making a general encoding system for  
>>> all neumed repertoires, instead of narrowing it down to a  
>>> particular style.
>>>
>>> You might imagine something along the lines of:
>>>
>>> <neume type="#clivis">
>>> ...
>>> </neume>
>>>
>>> or
>>>
>>> <neume type="http://example.org/neumevocabulary#clivis">
>>> ...
>>> </neume>
>>>
>>> This would let you use your own controlled vocabulary to name  
>>> things for your own encoding, while maintaining a more general  
>>> 'data shape' for the musical structures, allowing them to be  
>>> compared across repertoires.
>>>
>>> -Andrew
>>>
>>>> On 20 Sep 2017, at 15:26, Thomas Weber  
>>>> <thomas.weber at notengrafik.com> wrote:
>>>>
>>>> Dear group,
>>>>
>>>>
>>>> Elaine and me looked at both the Hildegard example as well as the  
>>>> "standard" neumes table by Cardine and made an attempt at  
>>>> encoding the signs' properties with better separation of domains.  
>>>> We tried to add more logical domain information to the previously  
>>>> mostly graphical domain info.
>>>>
>>>> Our thesis was that the main distinguishing factor between  
>>>> different use cases of the Neumes module is in how much detail  
>>>> the notation should be described. Many projects right now use the  
>>>> Volpiano font to capture only the melodic contour and potentially  
>>>> connection information. For Corpus monodicum, we want to encode  
>>>> more properties of single staff-bound components, mainly whether  
>>>> a component is an oriscus, quilisma or strophicus. Our  
>>>> understanding is that the Old Hispanic project as well as the  
>>>> Optical Neumes Recognition project need even more detailed  
>>>> information to be encodable.
>>>>
>>>> We came to the conclusion that the problem we still need to solve  
>>>> is better separation of visual and logical domains. Our  
>>>> impression is that the visual domain is of primary importance for  
>>>> both of the named projects. That might be the reason why the  
>>>> current draft seems to mainly focus on the visual domain.
>>>>
>>>> We prepared the following table based on Cardine that outlines  
>>>> our suggested encoding.
>>>>
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
>>>>
>>>> The most obvious addition are sub-elements describing each <nc>  
>>>> as one of the seven basic single pitch signs (four basic signs  
>>>> based on Anonymus Vaticanus: acuta, gravis, punctus, producta;  
>>>> three special signs: quilisma, oriscus, strophicus). We chose to  
>>>> make them elements so that each of those can get its specific set  
>>>> of attributes describing them in more detail, like "extended" for  
>>>> acuta/gravis (understood to indicate larger intervals) or "waves"  
>>>> for quilisma. The idea behind that was to make it clearer which  
>>>> attributes are usable in which contexts, but this could also be  
>>>> done by means of Schematron rules when using attributes instead  
>>>> of elements - which we did in our pre-Graz state of ideas:
>>>>
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
>>>>
>>>> We suggest to represent the "angled" property using the @con  
>>>> attribute, as "angularity" is a property of the connection.  
>>>> Depending on the sign, the logical meaning of this would be to  
>>>> lengthen the component before or after the angled connection.  
>>>> This logical domain info could be recorded using @dur on the  
>>>> proper <nc>.
>>>>
>>>> We picked up Ich's encoding of "O splendidissima" and made a  
>>>> modified version here:
>>>>
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
>>>>
>>>> Here we also tried to illustrate how more detailed visual domain  
>>>> information could added, namely the suggested @tilt. As the tilt  
>>>> is in most cases a consistent scribal idiosyncrasy, this might  
>>>> however better be solved using the tables of signs that Stefan  
>>>> Morent reminded us of recently. There, these idiosyncrasies could  
>>>> be described once for an entire file, source or hand. Johannes  
>>>> (hi to Johannes in CC) suggested that these "standard" patterns  
>>>> of writing might be best put in <scoreDef> and to encode  
>>>> deviations where they occur. These tables could also be useful to  
>>>> document variation among tokens.
>>>>
>>>> We suggest to keep the table problem and how to link between the  
>>>> content and the tables (by semi-standardized names, by project  
>>>> specific naming/numbering schemes or by simple XML IDs, or maybe  
>>>> implicitly by characteristic sequence of single pitch signs) for  
>>>> later discussion, together with other topics like how to  
>>>> represent mi signs and rubrics.
>>>>
>>>> We wish you a fruitful workshop in Halifax, and we are looking  
>>>> forward to hearing about any outcome concerning the neumes module!
>>>> Thomas
>>>>
>>>>
>>>> Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>>>>> Here’s what I have for the draft of the proposal for the new MEI  
>>>>> Neumes Module schema.
>>>>> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>>>>>
>>>>> For ease of discussion and efficiency, please discuss one issue  
>>>>> at a time in separate email threads, e.g., Re: @oriscus.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ichiro
>>>>>
>>>>> ==============================
>>>>> MEI Neumes Module Draft, Version 0.2
>>>>>
>>>>> A <neume> element consists of one or more <nc> element(s).
>>>>>
>>>>> A <nc> (neume component) is a single pitched event, although the  
>>>>> exact pitch may not be known.
>>>>>
>>>>> Attributes for <neume>:
>>>>> @intm (interval melodic; relative to the previous <neume>)  
>>>>> {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n =  
>>>>> neutral/unknown, sh = same or higher (but not lower), sl = same  
>>>>> or lower (but not higher))
>>>>> @significative letters
>>>>> @hispanicTick (type1, type2)
>>>>> @hook
>>>>>
>>>>> Attributes for <nc>:
>>>>> @pname
>>>>> @oct
>>>>> @intm (interval melodic; relative to the previous <neume>)  
>>>>> {u|d|s|n|sh|sl} (u = up, d = down, s = same, n =  
>>>>> neutral/unknown, sh = same or higher (but not lower), sl = same  
>>>>> or lower (but not higher))
>>>>> @wavy
>>>>> @significative letters
>>>>> @curved (anticlockwise, clockwise)
>>>>> @angular (plain, v-shaped, staircase) (was @angled)
>>>>> @liquescence
>>>>> @episema
>>>>> @extended
>>>>> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>>>>> @quilisma (2, 3, or 4 curves)
>>>>> @oriscus (curved, flat, jagged)
>>>>> @con (gapped, looped) (connection to the previous <nc> within  
>>>>> the same <neume>)
>>>>>
>>>>> Removed from the previous version: @jagged, @flat, @long,  
>>>>> @diagonalright, and @hispanicLoop from the <neume> level.
>>>>>
>>>>> _______________________________________________
>>>>> mei-neumes-ig mailing list
>>>>>
>>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>>
>>>> --
>>>>
>>>> Notengrafik Berlin GmbH
>>>> HRB 15007
>>>>
>>>> UstID: DE 289234097
>>>> Geschäftsführer:
>>>> Thomas Weber und Werner J. Wolff
>>>>
>>>> fon: +49 30 220661685
>>>>
>>>> Leuschnerdamm 13
>>>> 10999 Berlin
>>>>
>>>> notengrafik.com
>>>>
>>>> _______________________________________________
>>>> mei-neumes-ig mailing list
>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>
>>> _______________________________________________
>>> mei-neumes-ig mailing list
>>> mei-neumes-ig at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>> _______________________________________________
>>> mei-neumes-ig mailing list
>>> mei-neumes-ig at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>
>> _______________________________________________
>> mei-neumes-ig mailing list
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>
> ----- Ende der Nachricht von Elaine Stratton Hild  
> <elaine.stratton_hild at uni-wuerzburg.de> -----



From andrew.hankinson at mail.mcgill.ca  Sat Sep 23 14:43:32 2017
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson)
Date: Sat, 23 Sep 2017 12:43:32 +0000
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <20170923025843.Horde.xA3uieqtWddM-gaOVEnjRVR@webmail.uni-tuebingen.de>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
 <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
 <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>
 <59C3AB11020000E30006742C@gwia01.uni-wuerzburg.de>
 <20170922125651.Horde.KU9pknlFsI5FhW8Rhs1b6Km@webmail.uni-tuebingen.de>
 <20170923025843.Horde.xA3uieqtWddM-gaOVEnjRVR@webmail.uni-tuebingen.de>
Message-ID: <D8B13AB3-0D6C-4C5E-B7B1-5FA1AEBE7A05@mail.mcgill.ca>

Dear Inga, all,

I hope you have all been having a good time in Halifax! I wish I could be there...

I think I will need some clarification about what you wrote, however, and what was discussed. I can't seem to reconcile the two points that you are making, the first being that it will be a description of all types of notation, and the second being that the visual domain should take priority. It seems to me that the most fundamental difference between the different types of notations *are* their shapes, and so to prioritise the visual domain would necessarily bias it towards being more suitable to some notation types over others.

It's important to recognise that MEI is not a paelaeography description language [1], and that the first priority is to describe the musical content, independent of how it looks. Teasing apart the visual and musical dimensions in notation is not a straightforward task, which is why I think we're all struggling with this (and that's OK!).

So what's the way forward?

Perhaps its useful to think of MEI as less a way of stating absolute truth, and more a way of encoding the critical and interpretative decisions made in the process of capturing the notation. It seems to me that the sticking point is a reluctance to make a statement about musical interpretation, since some notation styles are ambiguous and their exact interpretation has been lost. It's a "known unknown" -- we know that we don't know what it is. I think there are two ways that we can address this.

The first is understanding that the process of encoding is always interpretation, that this will necessarily involve getting it wrong, and that its OK. Should you be asked to make a printed edition of an ambiguous source you would need to make decisions that you know are your own interpretation and not shared by everyone. Putting it into the digital domain does not solve that problem. So I don't think we should shy away from understanding that it's an interpretative process.

From a technical angle, MEI allows you to encode ambiguity through the critical encoding apparatus. sic/corr, app/rdg, unclear, choice, orig/reg -- these are all mechanisms through which one can encode ambiguous interpretations and assign interpretative provenance to them. Should these mechanisms not be suitable, additional methods of signalling an interpreters unease can be defined. These are the mechanisms that allows us to make our interpretations explicit.

My two biggest reservations about prioritising the visual domain are: the level of granularity that is necessary to fully represent the notation, and the difficulty in processing the encodings to look for patterns across a corpus. As Elaine mentioned, the difference between "north" and "northeast" in a particular hand may vary. It also may vary depending on other factors, like the precision with which the notation was being written (is it a quick draft copy, or is it a carefully written copy?). Ineveitably, should we go down this route we will likely be asked to accommodate encodings with the precise angle at which a sign is bent. At this point, MEI becomes a graphical representation format more like SVG, and this brings with it a whole slew of other problems, like visual baselines and units of measurement. (If a symbol is angled 'northeast' but the angle at which the musical content is written on the page is not at 90° from the top/bottom, from where is the angle measured from?)

With greater visual accuracy, musical accuracy (and the ability to search for the same musical patterns across a corpus) diminishes. This is because delegating the musical interpretation outside of MEI means it is up to the implementers of software to create the interpretation when it comes time to understand the musical content. It will make writing software for corpus analysis harder since it will necessarily require deeper understanding of musical interpretation on the part of the developer. Imagine only having textual descriptions, provided by multiple people, of neumes with no pictures, and then being asked to reconstruct the musical content -- I would think this would be a difficult task for even the most seasoned neumes expert! Expecting software developers to do this will lead to less-than-satisfactory results.

I think the issues Elaine raises are precisely why efforts on the new Neumes description format have been biased towards visual descriptions, rather than musical content. I'm not qualified to understand historical descriptions within various corpora, so I will have to defer to others in discussing their significance. From a high level, though, it seems that the issue is with levels of granularity and generalization. 

Granularity deals with using a symbol to describe one, and only one, quality of a symbol; the same thing cannot be used to describe both pitch and duration, for example -- those two dimensions need to be described separately. In the case of an unknown interpretation there should be a way of encoding the presence of a symbol without veering either too far to the interpretative side ("heavy", "strong") or to the visual side ("angled", "wavy"). Doing that without using a broadly acceptable name further complicates that. Is there some other way we can reconcile this? For common music notation, for example, we usually just encode the presence of a 'fermata' without making its performance implications or visual appearance explicit (although we could) [2].

Generalization is about how well one set of descriptors applies across different styles. Are there really no fundamental principles of the notation that would allow for comparison and alignment between OH neumes and Corpus Monodicum neumes? If they are fundamentally incompatible then this is something we need to figure out. If there are (and I suspect there are) then what are they?

-Andrew


[1] MEI can be used in a Paleography context through several other mechanisms. One is the ability to align musical contents with digital images through the 'zone' mechanism, which we've been using in the Cantus Ultimus systems for identifying signs on a page. The second is that SVG can be used in tandem with MEI to provide precise shape descriptions, as demonstrated by the Beethovens Werkstatt project. Making contact sheets of neume shapes (e.g., what you can do here: https://ahankinson.github.io/hartker-neume-table/) is possible with existing MEI mechansims. What is not possible, at the moment, is a method of aligning the musical contents across these corpora.

[2] We can encode:

<note fermata="above" />
<fermata />
<fermata shape="angled" />
<fermata shape="angular" form="inv" />
<fermata dur.ges="256p" />

This, I think, accurately separates out the presence of a sign from its particular shape, orientation, and duration.


> On 23 Sep 2017, at 01:58, Inga Behrendt <inga.behrendt at uni-tuebingen.de> wrote:
> 
> 
> Dear Thomas, dear Elaine,
> 
> we talked today about your suggestions during our Cantus Ultimus-Workshop.
> (1) And it ended up saying that we think that terms like "acuta", "gravis", "punctum" fit to SOME notations, but not to ALL. However, we are trying to find a MEI Neumes Module Schema that covers all different kinds of neume notations. For example, Elsa de Luca, our expert in Old Hispanic Neume Notation, said that she cannot use such names for her signs.
> And we all agreed that - if we want to create a Module Schema that we can use for all nematic notations - than we need to be very careful in the choice of names. So, I think, everybody in the Cantus Ultimus group would underline Andrew´s words from his previous mail:
> 
> "I have been under the impression that building a system built on explicit naming of neumes as elements would not be a good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape name."
> 
> (2) Andrew mentioned the other point to your questions ("I'm also of the opinion that the current proposal has a significant bias towards the visual component,"). We are in the moment describing the shape of the notation signs rather than giving names. And long discussions let us think in the end that is better not to include the meaning of the neume sign. We just describe the neume shapes. For example, an episema: if it means a longer duration or if it is a modal indication or if it shows a semitone within a descending line..., all of this we know from different works of colleagues, is not encoded. We KNOW of the different meanings. But in order to not determine already now the meaning we rather describe the shape.
> 
> Herzlich
> Inga
> 
> Zitat von "Prof. Dr. Morent" <stefan.morent at uni-tuebingen.de>:
> 
>> I would agree with the idea to encode the logical concept behind neume signs, considering the individual visual appearance as a "font" used by scribes within various traditions over time and space and within these traditions to express individual meaning.
>> 
>> Even if "producta" sounds probably unfamiliar to most chant scholars as to now it has the advantage to have a historical-theoretical background compared to the (modern invention) "tractulus".
>> 
>> I would however be cautious with terms like "longer", "duration" ... perhaps something like "light"/"heavy", "more emphasized", "strong" ... would be more appropriate?
>> 
>> best Stefan
>> 
>> ----- Nachricht von Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> ---------
>>      Datum: Thu, 21 Sep 2017 14:05:37 +0200
>>        Von: Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de>
>> Antwort an: Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-paderborn.de>
>>    Betreff: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
>>         An: mei-neumes-ig at lists.uni-paderborn.de
>> 
>>> Thanks so much for your time, Andrew (and all!).  My answers are below, marked with *. 
>>> 
>>> All best wishes,
>>> Elaine
>>>  
>>> 
>>>      
>>>   
>>>   
>>>  Dr. Elaine Stratton Hild
>>>  Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
>>>       Julius-Maximilians-Universität Würzburg
>>> Institut für Musikforschung
>>> Domerschulstraße 13
>>> D-97070 Würzburg            
>>>     
>>> 
>>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 9:24 PM >>>
>>> Thank you, Elaine! This clarifies a few things.
>>> 
>>> "Shape" is a term I borrowed from the process of data modelling to mean two objects which share the same properties and values, but which may be completely different instances of something. Two houses with one door and 10 windows could be said to have the same 'data shape', and it doesn't matter if one is a bungalow and one a skinny three-story Dutch house, and one is called a 'house' and another a 'huis'.
>>> 
>>> In this case, it simply means that two things that have a pitch contour of "up-then-down," for example, must be instances of the same class of things regardless of any particular name or identifier attached to them. The thing is defined by its properties, and not by a name that is given to it.
>>>   
>>>  ***Thank you for the explanation!
>>> 
>>> Perhaps you could clarify a few things about the functioning of your proposed elements. It seems that there are properties of these symbols that are non-exclusive, and that a single symbol can carry with it multiple dimensions of description.
>>> 
>>> As an encoder, when would I choose to use a 'gravis' over a 'puncta' if they can both mean 'lower' pitch? 
>>>   
>>>  ***These terms refer to different signs, different visual forms on the page. A gravis looks different than a punctus. (Gravis looks like \ while punctus looks like a period . In O splendidissima, the first notational sign above the syllable "splen" is an acuta connected to a gravis; two punctus are visible above the syllable "di")  A musicologist encoding the notation can record the basic visual forms with the terms gravis, acuta, punctus, producta. The meanings of these signs will need to encoded separately, because the meanings depend, to some extent, on context of the surrounding signs (which a musicologist can interpret). A punctus can mean "lower than preceding pitch" or it could also be slightly more ambiguous--it could mean "same or lower than the preceding pitch." 
>>>   
>>>   I understand that only puncta can be 'same or lower' but it seems, on the face of it, that there might be some confusion about when to use each. It also seems like there are three signs available to encode the 'same' pitch, two for 'lower', and only one for 'higher.' 
>>>   
>>>  ***When choosing which basic sign to encode, the musicologist will follow the scribe's use of the signs. Yes, you're right, different signs were used to convey the same information about pitch content. Conveying information about pitch content was not the only (or even the most important) aspect of notation for many medieval scribes. They used different forms to show different aspects of performance, and that's why it's important for us to be able to encode both the graphic signs (the visual domain) as well as the meanings we can glean from the scribe's use of the signs (the logical domain).  Returning to O splendidissima, the "lower" pitches the scribe wrote with punctus were probably performed shorter, or "lighter" than the the "lower" pitch recorded with the gravis. A musicologist should be able to add as much of this nuanced performance information that she wants, depending on her understanding of the notation and her desire for detail.
>>>   
>>>   Will this cover the range of pitch movements necessary in the repertoires?
>>>   
>>>  ***We need the options of neutral (or unknown), same, lower, same or lower, higher, same or higher. In some cases, a scribe will modify a sign to give additional information concerning pitch content. For instance, a scribe sometimes wrote a gravis longer, visually--extending down further than usual. (The gravis over "splen" happens to be one example.) The information about melodic interval is still "lower than previous pitch", but the musicologist might want to record the additional visual information (extended) and also record the meaning she attributes to the scribe's modification ("lower than the previous pitch by a third or more").  (In the case of O splendidissima, because the scribe used a staff, we can record absolute pitch levels--the descent of "g" to "e".)
>>> 
>>> Both 'puncta' and 'producta' also seem to have an impact on duration, which I think should be clearly separated from pitch. Is there any way to separate the duration implications out from them? If we remove duration from the meaning of the sign (and encode it in a separate attribute), are 'punctus' and 'productus' effectively the same thing? 
>>>   
>>>  ****We would still differentiate between punctus and producta to reflect the sign the scribe used (for our visual domain). Yes, I think we absolutely should record the duration implications separately, because some scribes used "producta" as the standard sign for "lower" and "same or lower" pitches, while other scribes used "punctus" as the standard and only used "producta" in special situations, to indicate lengthened duration. I think Thomas Weber was considering suggesting the @dur attribute (data.DURATION.neumes) with the values "longer" and "shorter". 
>>> 
>>> Is there a sign for 'same or higher with longer duration'? Is that necessary?
>>>   
>>>  **No, there's no basic sign for that. To show a higher pitch with longer duration, a scribe would add an episema to the acuta, or add a significative letter "t" (tenere) next to the acuta. The proposal from Thomas Weber and me would allow a significative letter element and using the @dur attribute (longer and shorter duration) to record the meaning of the scribe's use of episema and significative letters.
>>> 
>>> Is there a reason the 'neume' element has been replaced with 'ncg' in the supplied encoding?
>>>   
>>>  ***Yes! We are trying to make the Neumes Module revision comfortable for all musicologists. The term neume can mean different things, depending on the context in which it is used, and the musicologist. Neume component grouping is clearly a technical term, specific to the encoding, that will not cause confusion for chant scholars.
>>> 
>>> Cheers!
>>> -Andrew
>>> 
>>>> On 20 Sep 2017, at 16:55, Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> wrote:
>>>> 
>>>> Dear All,
>>>> 
>>>> Thank you for your work on this.
>>>> 
>>>> I agree completely, Andrew, that the neume names should be able to be included in the encoding, but the encoding should not depend on them. A quick thought concerning your suggestion below… “neume name” (rather than “neume type” would probably be more specific and clearer to musicologists (like me!) using the module.
>>>> 
>>>> Just to clarify… the proposal Thomas Weber and I have put forward does not rely upon neume names. The designations we recommend (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the earliest historical designations for notational signs, and—most importantly—they are not limited to one notational type. (Perhaps this is along the lines of what you meant with "data shapes", Andrew?)
>>>> 
>>>> They designate basic shapes that themselves convey basic information (acuta = one note with the same or higher pitch; gravis = one note with lower pitch; punctus = one note with same or lower pitch and normal duration; producta = one note with same or lower pitch and longer duration).
>>>> 
>>>> They are especially convenient for encoding because they can be combined to create all the notational signs of all types medieval notation.
>>>> 
>>>> (Small historical detour... For the writer of the 10th century treatise where these terms are first used for musical notation, the signs formed binary oppositions to each other: “Acuta” and “gravis” were drawn from the study of grammar, with the acuta placed over vowels where the voice rose in pitch and the gravis placed with syllables where the voice fell in pitch. “Punctus” and “producta” are symbols drawn from verse analysis: short syllables in Latin were marked with punctus; long syllables were marked with producta.)
>>>> 
>>>> We suggest using these designations (as basic "data shapes"), rather than the tilt attribute, because the basic meaning conveyed by an acuta (the logical domain) remains consistent across all medieval notations, but the nuanced tilt of the sign (the visual domain, whether it’s written “north” or “northeast”, for example) varies with individual scribes.
>>>> 
>>>> Many thanks and all best wishes,
>>>> Elaine
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Dr. Elaine Stratton Hild
>>>> Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters
>>>> Julius-Maximilians-Universität Würzburg
>>>> Institut für Musikforschung
>>>> Domerschulstraße 13
>>>> D-97070 Würzburg
>>>> 
>>>> 
>>>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
>>>> Hi Thomas,
>>>> 
>>>> Thanks for this, and spending time putting forward some concrete suggestions.
>>>> 
>>>> I'm also of the opinion that the current proposal has a significant bias towards the visual component. I believe this has emerged largely because the exact musical content of some repertoires is unknown, making a system built on a "logical" domain approach to musical description difficult to define. (that is, when all you have a symbol that is angled, and you don't even know what pitch it is, how do you describe it musically?) That said, I think it's worthwhile to try and tug the existing proposal in the direction of addressing and describing the musical content directly.
>>>> 
>>>> I have been under the impression that building a system built on explicit naming of neumes as elements would not be a good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape name.
>>>> 
>>>> That isn't to say that names are not a valuable thing to encode, but the idea is that these names would be included in a separate taxonomy within the file (or even a separate controlled vocabulary) that might be referenced within an encoding. I think this will go further towards making a general encoding system for all neumed repertoires, instead of narrowing it down to a particular style.
>>>> 
>>>> You might imagine something along the lines of:
>>>> 
>>>> <neume type="#clivis">
>>>> ...
>>>> </neume>
>>>> 
>>>> or
>>>> 
>>>> <neume type="http://example.org/neumevocabulary#clivis">
>>>> ...
>>>> </neume>
>>>> 
>>>> This would let you use your own controlled vocabulary to name things for your own encoding, while maintaining a more general 'data shape' for the musical structures, allowing them to be compared across repertoires.
>>>> 
>>>> -Andrew
>>>> 
>>>>> On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
>>>>> 
>>>>> Dear group,
>>>>> 
>>>>> 
>>>>> Elaine and me looked at both the Hildegard example as well as the "standard" neumes table by Cardine and made an attempt at encoding the signs' properties with better separation of domains. We tried to add more logical domain information to the previously mostly graphical domain info.
>>>>> 
>>>>> Our thesis was that the main distinguishing factor between different use cases of the Neumes module is in how much detail the notation should be described. Many projects right now use the Volpiano font to capture only the melodic contour and potentially connection information. For Corpus monodicum, we want to encode more properties of single staff-bound components, mainly whether a component is an oriscus, quilisma or strophicus. Our understanding is that the Old Hispanic project as well as the Optical Neumes Recognition project need even more detailed information to be encodable.
>>>>> 
>>>>> We came to the conclusion that the problem we still need to solve is better separation of visual and logical domains. Our impression is that the visual domain is of primary importance for both of the named projects. That might be the reason why the current draft seems to mainly focus on the visual domain.
>>>>> 
>>>>> We prepared the following table based on Cardine that outlines our suggested encoding.
>>>>> 
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
>>>>> 
>>>>> The most obvious addition are sub-elements describing each <nc> as one of the seven basic single pitch signs (four basic signs based on Anonymus Vaticanus: acuta, gravis, punctus, producta; three special signs: quilisma, oriscus, strophicus). We chose to make them elements so that each of those can get its specific set of attributes describing them in more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or "waves" for quilisma. The idea behind that was to make it clearer which attributes are usable in which contexts, but this could also be done by means of Schematron rules when using attributes instead of elements - which we did in our pre-Graz state of ideas:
>>>>> 
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
>>>>> 
>>>>> We suggest to represent the "angled" property using the @con attribute, as "angularity" is a property of the connection. Depending on the sign, the logical meaning of this would be to lengthen the component before or after the angled connection. This logical domain info could be recorded using @dur on the proper <nc>.
>>>>> 
>>>>> We picked up Ich's encoding of "O splendidissima" and made a modified version here:
>>>>> 
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
>>>>> 
>>>>> Here we also tried to illustrate how more detailed visual domain information could added, namely the suggested @tilt. As the tilt is in most cases a consistent scribal idiosyncrasy, this might however better be solved using the tables of signs that Stefan Morent reminded us of recently. There, these idiosyncrasies could be described once for an entire file, source or hand. Johannes (hi to Johannes in CC) suggested that these "standard" patterns of writing might be best put in <scoreDef> and to encode deviations where they occur. These tables could also be useful to document variation among tokens.
>>>>> 
>>>>> We suggest to keep the table problem and how to link between the content and the tables (by semi-standardized names, by project specific naming/numbering schemes or by simple XML IDs, or maybe implicitly by characteristic sequence of single pitch signs) for later discussion, together with other topics like how to represent mi signs and rubrics.
>>>>> 
>>>>> We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about any outcome concerning the neumes module!
>>>>> Thomas
>>>>> 
>>>>> 
>>>>> Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>>>>>> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
>>>>>> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>>>>>> 
>>>>>> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re: @oriscus.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Ichiro
>>>>>> 
>>>>>> ==============================
>>>>>> MEI Neumes Module Draft, Version 0.2
>>>>>> 
>>>>>> A <neume> element consists of one or more <nc> element(s).
>>>>>> 
>>>>>> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
>>>>>> 
>>>>>> Attributes for <neume>:
>>>>>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>>>>>> @significative letters
>>>>>> @hispanicTick (type1, type2)
>>>>>> @hook
>>>>>> 
>>>>>> Attributes for <nc>:
>>>>>> @pname
>>>>>> @oct
>>>>>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>>>>>> @wavy
>>>>>> @significative letters
>>>>>> @curved (anticlockwise, clockwise)
>>>>>> @angular (plain, v-shaped, staircase) (was @angled)
>>>>>> @liquescence
>>>>>> @episema
>>>>>> @extended
>>>>>> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>>>>>> @quilisma (2, 3, or 4 curves)
>>>>>> @oriscus (curved, flat, jagged)
>>>>>> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
>>>>>> 
>>>>>> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume> level.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> mei-neumes-ig mailing list
>>>>>> 
>>>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>>> 
>>>>> --
>>>>> 
>>>>> Notengrafik Berlin GmbH
>>>>> HRB 15007
>>>>> 
>>>>> UstID: DE 289234097
>>>>> Geschäftsführer:
>>>>> Thomas Weber und Werner J. Wolff
>>>>> 
>>>>> fon: +49 30 220661685
>>>>> 
>>>>> Leuschnerdamm 13
>>>>> 10999 Berlin
>>>>> 
>>>>> notengrafik.com
>>>>> 
>>>>> _______________________________________________
>>>>> mei-neumes-ig mailing list
>>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>> 
>>>> _______________________________________________
>>>> mei-neumes-ig mailing list
>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>> _______________________________________________
>>>> mei-neumes-ig mailing list
>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>> 
>>> _______________________________________________
>>> mei-neumes-ig mailing list
>>> mei-neumes-ig at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>> 
>> ----- Ende der Nachricht von Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> -----
> 
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


From elaine.stratton_hild at uni-wuerzburg.de  Mon Sep 25 11:19:53 2017
From: elaine.stratton_hild at uni-wuerzburg.de (Elaine Stratton Hild)
Date: Mon, 25 Sep 2017 11:19:53 +0200
Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
In-Reply-To: <D8B13AB3-0D6C-4C5E-B7B1-5FA1AEBE7A05@mail.mcgill.ca>
References: <3C10F4AD-7CBB-4028-A92E-9976F7877E9C@mcgill.ca>
 <1aa60dc2-ad22-2e2f-0ce0-d7cf98a8411b@notengrafik.com>
 <7D4341E3-2A15-4519-8C76-0D47ACBC24C9@mail.mcgill.ca>
 <59C28F78020000E30006732F@gwia01.uni-wuerzburg.de>
 <D9BFBB34-9BB3-434A-BE2E-086EC88659F6@mail.mcgill.ca>
 <59C3AB11020000E30006742C@gwia01.uni-wuerzburg.de>
 <20170922125651.Horde.KU9pknlFsI5FhW8Rhs1b6Km@webmail.uni-tuebingen.de>
 <20170923025843.Horde.xA3uieqtWddM-gaOVEnjRVR@webmail.uni-tuebingen.de>
 <D8B13AB3-0D6C-4C5E-B7B1-5FA1AEBE7A05@mail.mcgill.ca>
Message-ID: <59C8CA39020000E300067679@gwia01.uni-wuerzburg.de>


















Dear All,


 


Thank you for the dialogue. I think it is just what we need
to establish a considered, broadly useful revision of the neumes module. 


 


In my understanding, we do have content and meaning to
encode, across all notational families. All neumatic notation tells us:



* the number of pitches per syllable (encoded using the neume
component element)
* which pitches the scribe considered to belong to one group (encoded
using the connection attribute and the neume [a.k.a. neume component grouping]
element)
* the melodic contour; the relative pitch content (encoded
using the intm attribute)







 


For our encoding purposes, it’s necessary to move away from
the neume names and instead use the basic elements of the notational signs, so
that we can encode all signs, not just the ten (or so) of the most common that
were given names in the 12th century. Thomas Weber and I took the
terms for the basic elements from Anonymous Vaticanus—because his terms work
(they can be combined to describe any notational sign from all families) and
because they have a historical basis—but in the encoding, these basic elements
could be called anything, really. We just need to be able to encode “the sign
that shows a higher pitch" (acuta), “the sign that shows a lower pitch and is
usually connected with others" (gravis), “the sign that shows a lower pitch and
can stand by itself" (punctus), etc. The terms we’re using for these basic
elements would never need to be used in a musicological publication; they serve
a purpose for encoding that our usual terms cannot.


 


I understand that the Old Hispanic notation does not have a sign that musicologists refer to as “acuta”, but the
notation does
have signs with the same meaning. The acuta is simply a term for the sign that
means “one pitch, usually of higher pitch content than the preceding pitch”. As
of the twelfth century, especially in German-speaking regions, the sign was
called “virga” when it appeared by itself (uncombined with other signs). It
is also the second element of the “pes” and the first of the “clivis”, in Sankt
Gallen’s notation as well as in Old Hispanic.


 


Inga, if you and Elsa could look at the Cardine table that
Thomas and I “encoded” (link below), I think you’ll see that the neumatic signs
are well-described in the encoding—both their visual aspects and their
meaning—and that the system would work well for Old Hispanic neumes, too. The
images of the signs (in the “image column”) would certainly look different if
we replaced Cardine’s Sankt Gallen neumes with Old Hispanic, but the encoding system
would still be able to describe the basic meanings, the basic visual forms,
and—if a musicologist wanted to, using the tilt attributes and others—the more
detailed description of the signs' forms. 
 
http://cm.notengrafik.com/2017-Graz-Cantus-Network/cardine-table/cardine_web.xml


 


Thomas Weber and I tried to keep all notational families in
mind as we worked with the encoding system, so please let us know if there’s a
sign in Old Hispanic notation—or any other notational family—that wouldn’t be
accommodated. Those difficulties provide the perfect opportunities to make
progress.






Many thanks again and
all best wishes,


Elaine


 


P.S. Andrew, your example of the fermata seems
apt, and perhaps could serve a model for our thinking. Chant scholars have generally
established the practice of recording the presence of “quilisma” in our
transcriptions, although the performative meaning of the sign is still—to a
certain extent—open for debate and interpretation. 










Dr. Elaine Stratton Hild
Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
Julius-Maximilians-Universität Würzburg
Institut für Musikforschung
Domerschulstraße 13
D-97070 Würzburg





>>> Andrew Hankinson <andrew.hankinson at mail.mcI hope you have all been having a good time in Halifax! I wish I could be there...

I think I will need some clarification about what you wrote, however, and what was discussed. I can't seem to reconcile
the two points that you are making, the first being that it will be a description of all types of notation, and the
second being that the visual domain should take priority. It seems to me that the most fundamental difference between
the different types of notations *are* their shapes, and so to prioritise the visual domain would necessarily bias it
towards being more suitable to some notation types over others.

It's important to recognise that MEI is not a paelaeography description language [1], and that the first priority is to
describe the musical content, independent of how it looks. Teasing apart the visual and musical dimensions in notation
is not a straightforward task, which is why I think we're all struggling with this (and that's OK!).

So what's the way forward?

Perhaps its useful to think of MEI as less a way of stating absolute truth, and more a way of encoding the critical and
interpretative decisions made in the process of capturing the notation. It seems to me that the sticking point is a
reluctance to make a statement about musical interpretation, since some notation styles are ambiguous and their exact
interpretation has been lost. It's a "known unknown" -- we know that we don't know what it is. I think there are two
ways that we can address this.

The first is understanding that the process of encoding is always interpretation, that this will necessarily involve
getting it wrong, and that its OK. Should you be asked to make a printed edition of an ambiguous source you would need
to make decisions that you know are your own interpretation and not shared by everyone. Putting it into the digital
domain does not solve that problem. So I don't think we should shy away from understanding that it's an interpretative
process.

>From a technical angle, MEI allows you to encode ambiguity through the critical encoding apparatus. sic/corr, app/rdg,
unclear, choice, orig/reg -- these are all mechanisms through which one can encode ambiguous interpretations and assign
interpretative provenance to them. Should these mechanisms not be suitable, additional methods of signalling an
interpreters unease can be defined. These are the mechanisms that allows us to make our interpretations explicit.

My two biggest reservations about prioritising the visual domain are: the level of granularity that is necessary to
fully represent the notation, and the difficulty in processing the encodings to look for patterns across a corpus. As
Elaine mentioned, the difference between "north" and "northeast" in a particular hand may vary. It also may vary
depending on other factors, like the precision with which the notation was being written (is it a quick draft copy, or
is it a carefully written copy?). Ineveitably, should we go down this route we will likely be asked to accommodate
encodings with the precise angle at which a sign is bent. At this point, MEI becomes a graphical representation format
more like SVG, and this brings with it a whole slew of other problems, like visual baselines and units of measurement.
(If a symbol is angled 'northeast' but the angle at which the musical content is written on the page is not at 90° from
the top/bottom, from where is the angle measured from?)

With greater visual accuracy, musical accuracy (and the ability to search for the same musical patterns across a corpus)
diminishes. This is because delegating the musical interpretation outside of MEI means it is up to the implementers of
software to create the interpretation when it comes time to understand the musical content. It will make writing
software for corpus analysis harder since it will necessarily require deeper understanding of musical interpretation on
the part of the developer. Imagine only having textual descriptions, provided by multiple people, of neumes with no
pictures, and then being asked to reconstruct the musical content -- I would think this would be a difficult task for
even the most seasoned neumes expert! Expecting software developers to do this will lead to less-than-satisfactory
results.

I think the issues Elaine raises are precisely why efforts on the new Neumes description format have been biased towards
visual descriptions, rather than musical content. I'm not qualified to understand historical descriptions within various
corpora, so I will have to defer to others in discussing their significance. From a high level, though, it seems that
the issue is with levels of granularity and generalization. 

Granularity deals with using a symbol to describe one, and only one, quality of a symbol; the same thing cannot be used
to describe both pitch and duration, for example -- those two dimensions need to be described separately. In the case of
an unknown interpretation there should be a way of encoding the presence of a symbol without veering either too far to
the interpretative side ("heavy", "strong") or to the visual side ("angled", "wavy"). Doing that without using a broadly
acceptable name further complicates that. Is there some other way we can reconcile this? For common music notation, for
example, we usually just encode the presence of a 'fermata' without making its performance implications or visual
appearance explicit (although we could) [2].

Generalization is about how well one set of descriptors applies across different styles. Are there really no fundamental
principles of the notation that would allow for comparison and alignment between OH neumes and Corpus Monodicum neumes?
If they are fundamentally incompatible then this is something we need to figure out. If there are (and I suspect there
are) then what are they?

-Andrew


[1] MEI can be used in a Paleography context through several other mechanisms. One is the ability to align musical
contents with digital images through the 'zone' mechanism, which we've been using in the Cantus Ultimus systems for
identifying signs on a page. The second is that SVG can be used in tandem with MEI to provide precise shape
descriptions, as demonstrated by the Beethovens Werkstatt project. Making contact sheets of neume shapes (e.g., what you
can do here: https://ahankinson.github.io/hartker-neume-table/) is possible with existing MEI mechansims. What is not
possible, at the moment, is a method of aligning the musical contents across these corpora.

[2] We can encode:

<note fermata="above" />
<fermata />
<fermata shape="angled" />
<fermata shape="angular" form="inv" />
<fermata dur.ges="256p" />

This, I think, accurately separates out the presence of a sign from its particular shape, orientation, and duration.


> On 23 Sep 2017, at 01:58, Inga Behrendt <inga.behrendt at uni-tuebingen.de> wrote:
> 
> 
> Dear Thomas, dear Elaine,
> 
> we talked today about your suggestions during our Cantus Ultimus-Workshop.
> (1) And it ended up saying that we think that terms like "acuta", "gravis", "punctum" fit to SOME notations, but not
to ALL. However, we are trying to find a MEI Neumes Module Schema that covers all different kinds of neume notations.
For example, Elsa de Luca, our expert in Old Hispanic Neume Notation, said that she cannot use such names for her signs.
> And we all agreed that - if we want to create a Module Schema that we can use for all nematic notations - than we need
to be very careful in the choice of names. So, I think, everybody in the Cantus Ultimus group would underline Andrew´s
words from his previous mail:
> 
> "I have been under the impression that building a system built on explicit naming of neumes as elements would not be a
good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across
styles or languages) and building a system on neume names makes it more difficult to accurately capture the longer
non-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape
name."
> 
> (2) Andrew mentioned the other point to your questions ("I'm also of the opisignificant bias towards the visual component,"). We are in the moment describing the shape of the notation signs rather
than giving names. And long discussions let us think in the end that is better not to include the meaning of the neume
sign. We just describe the neume shapes. For example, an episema: if it means a longer duration or if it is a modal
indication or if it shows a semitone within a descending line..., all of this we know from different works of
colleagues, is not encoded. We KNOW of the different meanings. But in order to not determine already now the meaning we
rather describe the shape.
> 
> Herzlich
> Inga
> 
> Zitat von "Prof. Dr. Morent" <stefan.morent at uni-tuebingen.de>:
> 
>> I would agree with the idea to encode the logical concept behind neume signs, considering the individual visual
appearance as a "font" used by scribes within various traditions over time and space and within these traditions to
express individual meaning.
>> 
>> Even if "producta" sounds probably unfamiliar to most chant scholars as to now it has the advantage to have a
historical-theoretical background compared to the (modern invention) "tractulus".
>> 
>> I would however be cautious with terms like "longer", "duration" ... perhaps something like "light"/"heavy", "more
emphasized", "strong" ... would be more appropriate?
>> 
>> best Stefan
>> 
>> ----- Nachricht von Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> ---------
>>      Datum: Thu, 21 Sep 2017 14:05:37 +0200
>>        Von: Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de>
>> Antwort an: Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-paderborn.de>
>>    Betreff: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
>>         An: mei-neumes-ig at lists.uni-paderborn.de
>> 
>>> Thanks so much for your time, Andrew (and all!).  My answers are below, marked with *. 
>>> 
>>> All best wishes,
>>> Elaine
>>>  
>>> 
>>>      
>>>   
>>>   
>>>  Dr. Elaine Stratton Hild
>>>  Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
>>>       Julius-Maximilians-Universität Würzburg
>>> Institut für Musikforschung
>>> Domerschulstraße 13
>>> D-97070 Würzburg            
>>>     
>>> 
>>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 9:24 PM >>>
>>> Thank you, Elaine! This clarifies a few things.
>>> 
>>> "Shape" is a term I borrowed from the process of data modelling to mean two objects which share the same properties
and values, but which may be completely different instances of something. Two houses with one door and 10 windows could
be said to have the same 'data shape', and it doesn't matter if one is a bungalow and one a skinny three-story Dutch
house, and one is called a 'house' and another a 'huis'.
>>> 
>>> In this case, it simply means that two things that have a pitch contour of "up-then-down," for example, must be
instances of the same class of things regardless of any particular name or identifier attached to them. The thing is
defined by its properties, and not by a name that is given to it.
>>>   
>>>  ***Thank you for the explanation!
>>> 
>>> Perhaps you could clarify a few things about the functioning of your proposed elements. It seems that there are
properties of these symbols that are non-exclusive, and that a single symbol can carry with it multiple dimensions of
description.
>>> 
>>> As an encoder, when would I choose to use a 'gravis' over a 'puncta' if they can both mean 'lower' pitch? 
>>>   
>>>  ***These terms refer to different signs, different visual forms on the page. A gravis looks different than a
punctus. (Gravis looks like \ while punctus looks like a period . In O splendidissima, the first notational sign above
the syllable "splen" is an acuta connected to a gravis; two punctus are visible above the syllable "di")  A musicologist
encoding the notation can record the basic visual forms with the terms gravis, acuta, punctus, producta. The meanings of
these signs will need to encoded separately, because the meanings depend, to some extent, on context of the surrounding
signs (which a musicologist can interpret). A punctus can mean "lower than preceding pitch" or it could also be slightly
more ambiguous--it could mean "same or lower than the preceding pitch." 
>>>   
>>>   I understand that only puncta can be 'same or lower' but it seems, on the face of it, that there might be some
confusion about when to use each. It also seems like there are three signs available to encode the 'same' pitch, two for
'lower', and only one for 'higher.' 
>>>   
>>>  ***When choosing which basic sign to encode, the musicologist will follow the scribe's use of the signs. Yes,
you're right, different signs were used to convey the same information about pitch content. Conveying information about
pitch content was not the only (or even the most important) aspect of notation for many medieval scribes. They used
different forms to show different aspects of performance, and that's why it's important for us to be able to encode both
the graphic signs (the visual domain) as well as the meanings we can glean from the scribe's use of the signs (the
logical domain).  Returning to O splendidissima, the "lower" pitches the scribe wrote with punctus were probably
performed shorter, or "lighter" than the the "lower" pitch recorded with the gravis. A musicologist should be able to
add as much of this nuanced performance information that she wants, depending on her understanding of the notation and
her desire for detail.
>>>   
>>>   Will this cover the range of pitch movements necessary in the repertoires?
>>>   
>>>  ***We need the options of neutral (or unknown), same, lower, same or lower, higher, same or higher. In some cases,
a scribe will modify a sign to give additional information concerning pitch content. For instance, a scribe sometimes
wrote a gravis longer, visually--extending down further than usual. (The gravis over "splen" happens to be one example.)
The information about melodic interval is still "lower than previous pitch", but the musicologist might want to record
the additional visual information (extended) and also record the meaning she attributes to the scribe's modification
("lower than the previous pitch by a third or more").  (In the case of O splendidissima, because the scribe used a
staff, we can record absolute pitch levels--the descent of "g" to "e".)
>>> 
>>> Both 'puncta' and 'producta' also seem to have an impact on duration, which I think should be clearly separated from
pitch. Is there any way to separate the duration implications out from them? If we remove duration from the meaning of
the sign (and encode it in a separate attribute), are 'punctus' and 'productus' effectively the same thing? 
>>>   
>>>  ****We would still differentiate between punctus and producta to reflect the sign the scribe used (for our visual
domain). Yes, I think we absolutely should record the duration implications separately, because some scribes used
"producta" as the standard sign for "lower" and "same or lower" pitches, while other scribes used "punctus" as the
standard and only used "producta" in special situations, to indicate lengthened duration. I think Thomas Weber was
considering suggesting the @dur attribute (data.DURATION.neumes) with the values "longer" and "shorter". 
>>> 
>>> Is there a sign for 'same or higher with longer duration'? Is that necessary?
>>>   
>>>  **No, there's no basic sign for that. To show a higher pitch with longer duration, a scribe would add an episema to
the acuta, or add a significative letter "t" (tenere) next to the acuta. The proposal from Thomas Weber and me would
allow a significative letter element and using the @dur attribute (longer and shorter duration) to record the meaning of
the scribe's use of episema and significative letters.
>>> 
>>> Is there a reason the 'neume' element has been replaced with 'ncg' in the supplied encoding?
>>>   
>>>  ***Yes! We are trying to make the Neumes Module revision comfortable for all musicologists. The term neume can mean
different things, depending on the context in which it is used, and the musicologist. Neume component grouping is
clearly a technical term, specific to the encoding, that will not cause confusion for chant scholars.
>>> 
>>> Cheers!
>>> -Andrew
>>> 
>>>> On 20 Sep 2017, at 16:55, Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> wrote:
>>>> 
>>>> Dear All,
>>>> 
>>>> Thank you for your work on this.
>>>> 
>>>> I agree completely, Andrew, that the neume names should be able to be included in the encoding, but the encoding
should not depend on them. A quick thought concerning your suggestion below… “neume name” (rather than “neume type”
would probably be more specific and clearer to musicologists (like me!) using the module.
>>>> 
>>>> Just to clarify… the proposal Thomas Weber and I have put forward does not rely upon neume names. The designations
we recommend (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the earliest historical designations for
notational signs, and—most importantly—they are not limited to one notational type. (Perhaps this is along the lines of
what you meant with "data shapes", Andrew?)
>>>> 
>>>> They designate basic shapes that themselves convey basic information (acuta = one note with the same or higher
pitch; gravis = one note with lower pitch; punctus = one note with same or lower pitch and normal duration; producta =
one note with same or lower pitch and longer duration).
>>>> 
>>>> They are especially convenient for encoding because they can be combined to create all the notational signs of all
types medieval notation.
>>>> 
>>>> (Small historical detour... For the writer of the 10th century treatise where these terms are first used for
musical notation, the signs formed binary oppositions to each other: “Acuta” and “gravis” were drawn from the study of
grammar, with the acuta placed over vowels where the voice rose in pitch and the gravis placed with syllables where the
voice fell in pitch. “Punctus” and “producta” are symbols drawn from verse analysis: short syllables in Latin were
marked with punctus; long syllables were marked with producta.)
>>>> 
>>>> We suggest using these designations (as basic "data shapes"), rather than the tilt attribute, because the basic
meaning conveyed by an acuta (the logical domain) remains consistent across all medieval notations, but the nuanced tilt
of the sign (the visual domain, whether it’s written “north” or “northeast”, for example) varies with individual
scribes.
>>>> 
>>>> Many thanks and all best wishes,
>>>> Elaine
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Dr. Elaine Stratton Hild
>>>> Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters
>>>> Julius-Maximilians-Universität Würzburg
>>>> Institut für Musikforschung
>>>> Domerschulstraße 13
>>>> D-97070 Würzburg
>>>> 
>>>> 
>>>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
>>>> Hi Thomas,
>>>> 
>>>> Thanks for this, and spending time putting forward some concrete suggestions.
>>>> 
>>>> I'm also of the opinion that the current proposal has a significant bias towards the visual component. I believe
this has emerged largely because the exact musical content of some repertoires is unknown, making a system built on a
"logical" domain approach to musical description difficult to define. (that is, when all you have a symbol that is
angled, and you don't even know what pitch it is, how do you describe it musically?) That said, I think it's worthwhile
to try and tug the existing proposal in the direction of addressing and describing the musical content directly.
>>>> 
>>>> I have been under the impression that building a system built on explicit naming of neumes as elements would not be
a good idea, based on critiques I have heard on the existing neume module. The same neume can have many names (across
styles or languages) and building a system on neume names makes it more difficult to accurately capture the longnon-standard (i.e., "compound") neumes. Thus the reason for building a system based on shape contour, rather than shape
name.
>>>> 
>>>> That isn't to say that names are not a valuable thing to encode, but the idea is that these names would be included
in a separate taxonomy within the file (or even a separate controlled vocabulary) that might be referenced within an
encoding. I think this will go further towards making a general encoding system for all neumed repertoires, instead of
narrowing it down to a particular style.
>>>> 
>>>> You might imagine something along the lines of:
>>>> 
>>>> <neume type="#clivis">
>>>> ...
>>>> </neume>
>>>> 
>>>> or
>>>> 
>>>> <neume type="http://example.org/neumevocabulary#clivis">
>>>> ...
>>>> </neume>
>>>> 
>>>> This would let you use your own controlled vocabulary to name things for your own encoding, while maintaining a
more general 'data shape' for the musical structures, allowing them to be compared across repertoires.
>>>> 
>>>> -Andrew
>>>> 
>>>>> On 20 Sep 2017, at 15:26, Thomas Weber <thomas.weber at notengrafik.com> wrote:
>>>>> 
>>>>> Dear group,
>>>>> 
>>>>> 
>>>>> Elaine and me looked at both the Hildegard example as well as the "standard" neumes table by Cardine and made an
attempt at encoding the signs' properties with better separation of domains. We tried to add more logical domain
information to the previously mostly graphical domain info.
>>>>> 
>>>>> Our thesis was that the main distinguishing factor between different use cases of the Neumes module is in how much
detail the notation should be described. Many projects right now use the Volpiano font to capture only the melodic
contour and potentially connection information. For Corpus monodicum, we want to encode more properties of single
staff-bound components, mainly whether a component is an oriscus, quilisma or strophicus. Our understanding is that the
Old Hispanic project as well as the Optical Neumes Recognition project need even more detailed information to be
encodable.
>>>>> 
>>>>> We came to the conclusion that the problem we still need to solve is better separation of visual and logical
domains. Our impression is that the visual domain is of primary importance for both of the named projects. That might be
the reason why the current draft seems to mainly focus on the visual domain.
>>>>> 
>>>>> We prepared the following table based on Cardine that outlines our suggested encoding.
>>>>> 
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
>>>>> 
>>>>> The most obvious addition are sub-elements describing each <nc> as one of the seven basic single pitch signs (four
basic signs based on Anonymus Vaticanus: acuta, gravis, punctus, producta; three special signs: quilisma, oriscus,
strophicus). We chose to make them elements so that each of those can get its specific set of attributes describing them
in more detail, like "extended" for acuta/gravis (understood to indicate larger intervals) or "waves" for quilisma. The
idea behind that was to make it clearer which attributes are usable in which contexts, but this could also be done by
means of Schematron rules when using attributes instead of elements - which we did in our pre-Graz state of ideas:
>>>>> 
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
>>>>> 
>>>>> We suggest to represent the "angled" property using the @con attribute, as "angularity" is a property of the
connection. Depending on the sign, the logical meaning of this would be to lengthen the component before or after the
angled connection. This logical domain info could be recorded using @dur on the proper <nc>.
>>>>> 
>>>>> We picked up Ich's encoding of "O splendidissima" and made a modified version here:
>>>>> 
>>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
>>>>> 
>>>>> Here we also tried to illustrate how more detailed visual domain information could added, namely the suggested
@tilt. As the tilt is in most cases a consistent scribal idiosyncrasy,tables of signs that Stefan Morent reminded us of recently. There, these idiosyncrasies could be described once for an
entire file, source or hand. Johannes (hi to Johannes in CC) suggested that these "standard" patterns of writing might
be best put in <scoreDef> and to encode deviations where they occur. These tables could also be useful to document
variation among tokens.
>>>>> 
>>>>> We suggest to keep the table problem and how to link between the content and the tables (by semi-standardized
names, by project specific naming/numbering schemes or by simple XML IDs, or maybe implicitly by characteristic sequence
of single pitch signs) for later discussion, together with other topics like how to represent mi signs and rubrics.
>>>>> 
>>>>> We wish you a fruitful workshop in Halifax, and we are looking forward to hearing about any outcome concerning the
neumes module!
>>>>> Thomas
>>>>> 
>>>>> 
>>>>> Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>>>>>> Here’s what I have for the draft of the proposal for the new MEI Neumes Module schema.
>>>>>> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>>>>>> 
>>>>>> For ease of discussion and efficiency, please discuss one issue at a time in separate email threads, e.g., Re:
@oriscus.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Ichiro
>>>>>> 
>>>>>> ==============================
>>>>>> MEI Neumes Module Draft, Version 0.2
>>>>>> 
>>>>>> A <neume> element consists of one or more <nc> element(s).
>>>>>> 
>>>>>> A <nc> (neume component) is a single pitched event, although the exact pitch may not be known.
>>>>>> 
>>>>>> Attributes for <neume>:
>>>>>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same,
n = neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>>>>>> @significative letters
>>>>>> @hispanicTick (type1, type2)
>>>>>> @hook
>>>>>> 
>>>>>> Attributes for <nc>:
>>>>>> @pname
>>>>>> @oct
>>>>>> @intm (interval melodic; relative to the previous <neume>) {u|d|s|n|sh|sl} (u = up, d = down, s = same, n =
neutral/unknown, sh = same or higher (but not lower), sl = same or lower (but not higher))
>>>>>> @wavy
>>>>>> @significative letters
>>>>>> @curved (anticlockwise, clockwise)
>>>>>> @angular (plain, v-shaped, staircase) (was @angled)
>>>>>> @liquescence
>>>>>> @episema
>>>>>> @extended
>>>>>> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>>>>>> @quilisma (2, 3, or 4 curves)
>>>>>> @oriscus (curved, flat, jagged)
>>>>>> @con (gapped, looped) (connection to the previous <nc> within the same <neume>)
>>>>>> 
>>>>>> Removed from the previous version: @jagged, @flat, @long, @diagonalright, and @hispanicLoop from the <neume>
level.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> mei-neumes-ig mailing list
>>>>>> 
>>>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>>> 
>>>>> --
>>>>> 
>>>>> Notengrafik Berlin GmbH
>>>>> HRB 15007
>>>>> 
>>>>> UstID: DE 289234097
>>>>> Geschäftsführer:
>>>>> Thomas Weber und Werner J. Wolff
>>>>> 
>>>>> fon: +49 30 220661685
>>>>> 
>>>>> Leuschnerdamm 13
>>>>> 10999 Berlin
>>>>> 
>>>>> notengrafik.com
>>>>> 
>>>>> _______________________________________________
>>>>> mei-neumes-ig mailing list
>>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>> 
>>>> _______________________________________________
>>>> mei-neumes-ig mailing list
>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>> _______________________________________________
>>>> mei-neumes-ig mailing list
>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>> 
>>> _______________________________________________
>>> mei-neumes-ig mailing list
>>> mei-neumes-ig at lists.uni-paderborn.de
>>> https://lists.>> ----- Ende der Nachricht von Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de> -----
> 
> 
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig

_______________________________________________
mei-neumes-ig mailing list
mei-neumes-ig at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170925/05914188/attachment.html>