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

[Anna Plaksin]

There are also cases in mensural notation, where an accidental is not on the
same position as the following note and also not applied to that note but to
the next one, see for example here (first system of Kyrie or second system
of Gloria):
http://archiv.onb.ac.at:1801/webclient/StreamGate?folder_id=200&dvs=14805787
75920~129 
Therefor it is necessary to use accidentals as independent elements in the
layer and in consequence it is necessary to give them any information about
its position.
When I try to compare Donald's and my example, it starts to get really
complex to me: In Donald's example is the visual position independent from
the logical relation. In my example, in the case I'm not totally mistake it,
the visual position is a hint for the logical relation. So, the use of @oloc
and @ploc is clear in Donald's example, whereas my example theoretically
could be also done in both ways, depending on other encoding decisions.

But it seemed always quite consistent to me using @oloc and @ploc, because
an accidental has no pitch but points on a pitch because of its position, I
was rather wondering about @pname and @oct in <keyAccid>.

And unfortunately, my two cents confused me even more than making it clear.
Maybe anyone else could ease my confusion... (thanks in advance)

Anna


-----Ursprüngliche Nachricht-----
Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von
Byrd, Donald A.
Gesendet: Mittwoch, 30. November 2016 16:45
An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
Betreff: Re: [MEI-L] accid/@ploc/@oloc vs. keyAccid/@pname/@oct

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