[MEI-L] accid/@ploc/@oloc vs. keyAccid/@pname/@oct

Byrd, Donald A. donbyrd at indiana.edu
Wed Nov 30 16:44:53 CET 2016


On Nov 30, 2016, at 3:18 AM, Thomas Weber <tw at notabit.eu> wrote:

> Am 30.11.2016 um 01:03 schrieb Roland, Perry D. (pdr4h):
>> @pname and @oct are used to capture "logical" information for a pitched entity, such as a <note>, while @loc, @ploc and @oloc are for recording the "visual" location of an object with respect to the staff.
>> 
>> @loc uses a number-based approach where positive values are used for positions above the bottom line and negative values for the positions below. The value '0' indicates the bottom line of the current staff.  @loc = "4" indicates placement of an object on the middle line of a 5-line staff.
>> 
>> @ploc and @oloc also capture visual location, but in pitch terms.  In this case, the middle line of a 5-line staff using the treble clef is indicated by @ploc = "b" and @oloc = "4".  @pname and @oct could have been used for this purpose, but then it would have been difficult to differentiate between pitched items (those things that make a sound) and those things that don't make a sound by themselves, but need to identify their location in terms of pitch.
>> 
>> Some entities; that is, rests, permit @loc as well as @ploc and @oloc attributes, mostly to make it easier to accommodate translation from other representation systems that use one or the other approach.  Other entities; that is, accid and dot, allow @loc all the time, but @ploc and @oloc only when the MEI.mensural module is activated.  In the mensural repertoire placing these items according to pitch makes sense I'm told.
>> 
>> Since it has all the modules turned on, the mei-all schema is undoubtedly a source of confusion.  My recommendation is to use one of the other customizations instead.  Using mei-CMN for instance makes @ploc and @oloc unavailable on <accid>, thereby somewhat reducing the complexity of specifying a place for <accid>.
> 
> 
> Sorry for causing you going into these details - I could learn most of that in the documentation.  I should have been more specific.
> 
> I'm trying to gain clarity on how to use <accid> (and potentially <keyAccid>) in context of the neumes module - so I'm closer to mensural land here.  I'm ignorant about why and how in the mensural module, @ploc and @oloc are used instead of their logical domain cousins.  Also, in what situations <accid> is used directly inside <layer>.  I couldn't find any example in the sample encodings.
> 
> Because in neumatic notation they are written before an entire group of pitches, accidentals usually are spatially detached from the graphical bit representing the pitch/"note" they apply to (unless they apply to the very first pitch in the group or the "group" only consists of one pitch).  I don't think we can attach the accidentals to the pitches/"notes" themselves.  As there are no modern notes present and definitive pitch information is not a given, encoders might not encode <note> elements with logical @pname and @oct attributes.  But maybe in repertoires where accidentals are used, pitch information is adequately specific and it's clear to which pitch/"note" an accidental applies to.  I'll address that question to the experts on the mei-neumes-ig mailing list.

I'll comment on why "@ploc and @oloc are used instead of their logical domain cousins" in mensural notation. I've been working on mensural notation in Verovio for quite awhile, but I'm certainly not an expert on it, so don't take what I say _too_ seriously. 

Attached are a simple MEI file and the Verovio output for it. In the original manuscript, the note is clearly a C, but the sharp preceding it is clearly a half-space lower, i.e., it's positioned for the B below. In the mensural repertoire, pitch information is specific, and it _is_ clear to what note an accidental applies. So, for one thing, the positioning of the sharp here is obviously a graphical feature, conveying no logical information; for another, describing its position in the same terms as the note it belongs to makes more sense than describing it in the very different terms of  @pname and @oct.

Would mensural (or neumatic or other) experts care to comment further?

--Don


> 
> Thanks for supporting me thinking aloud,
> Thomas
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

---
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington





-------------- next part --------------
A non-text attachment was scrubbed...
Name: CH-E689_007v.mei
Type: application/octet-stream
Size: 2034 bytes
Desc: CH-E689_007v.mei
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20161130/6411a690/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CH-E689_007v.svg
Type: image/svg+xml
Size: 6690 bytes
Desc: CH-E689_007v.svg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20161130/6411a690/attachment.svg>


More information about the mei-l mailing list