[mei-neumes-ig] A draft for the new Neumes Module schema

[Roland, Perry D. (pdr4h)]

“Unspecified” it is.

@strophicus will get boolean values.

Using <note> inside <nc> doesn’t really add much.  I think it’s pretty easy to understand that both notes and neumes can be pitched things. Adding <note> could actually make it more difficult to process neumes because it would place the pitch information at two different levels in the XML hierarchy depending on whether <note> was inside <nc> or not.

<keySig> is probably the right way to go, but perhaps with an indication that it applies only in the visual domain.  This could be indicated with a special attribute or through the use of @type or @class.  In any case, I’ll refrain from any additional comment at this time and leave you and others in the Interest Group to work up a proposal.

--
p.

From: Thomas Weber [mailto:thomas.weber at notengrafik.com]
Sent: Friday, June 02, 2017 11:29 AM
To: Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-paderborn.de>; Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>
Subject: Re: [mei-neumes-ig] A draft for the new Neumes Module schema

Hi Perry,


Am 25.05.2017 um 18:02 schrieb Roland, Perry D. (pdr4h):

Mixing primitive datatypes; that is, “true|false|2|3”, creates a number of issues that I’d like to avoid.  But there are other options –


1.     creating, as you suggest, two attributes each for quilisma and orisicus: quilisima and quilisma.form and orisicus and oriscus.form,

2.     promoting @quilisma and @oriscus to element status and giving them attributes to describe their visual qualities,

3.     creation of a customization for your project that substitutes “true|false” for “2|3” in the official schema.

We explored the 2nd possibility in Tours, but I’m not convinced that’s the best path because it creates inconsistency by promoting some attributes of <nc> but not others.


I fully agree.  I'd be in favor of something akin to your "unspecified" suggestion.




Adding @strophicus is simple, but what should its values be?  True/false, like oriscus, etc. or something else?


Yes, I meant it should just work like oriscus etc.




To deal with pitch, we decided to add @pname and @oct on <nc>, but I’d like to hear why you think adding <note> inside <nc> is preferable.


My thought was that diastematic neumes might receive better support from tools working with pitch sequences (e.g. for melody search or statistics) if it had <note> just like CMN or mensural.




I’m confused with regard to one of your suggestions about <accid>.  You want <accid> to appear between <neume> elements and that’s exactly where they can currently occur, but that makes them children of <syllable>, which you say you don’t want.  Once you’ve cleared that up, adding <accid> as a child of <neume> isn’t a problem.


Maybe another case of me thinking over-complicatedly.  I'd appreciate some help with this.  We probably need to find a better solution for the pseudo key signatures we need to encode without <accid>.

Those pseudo key signatures are not really used like modern key signatures.  For example, there can be one flat at the beginning of some lines of a chant, but not on others.  This is not related to any changes in "tonality" or so - a line break is just made when the line is full, not when a musically sensible section is over.  Even if pseudo key signatures are present, flats sometimes are still written out explicitly on some, but not necessarily all pitches.  I saw an instance of what to modern eyes looks like a "cancelling" key signature, though there is nothing to cancel.

These pseudo key signatures are not something very unique, they occur in a number of different sources (almost half of the 35 sources from the first volumes we prepared), but we can't be sure about their precise meaning and scope.  A modern <keySig> takes effect until another <keySig> (or <staffDef>/<scoreDef>) occurs.  This means, it implies that the key signature is visually repeated on every line, which is not the case for those pseudo key signatures we're dealing with.

As we wanted to avoid <keySig> for those reasons, I though <accid> might be a more neutral way of saying "there is a flat in the source here, but we can't really say what the precise scope/meaning of this is".  However, that leads to the problem that they can be confused with other <accid>s between neumes.  That idea was probably flawed.

<keySig> is probably more appropriate, but we'd like to find a way that makes clear we're basically encoding the visual domain here and leave the logical interpretation open.


Best
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-neumes-ig/attachments/20170621/84e6bad5/attachment.html>