[MEI-L] analysis

[Roland, Perry (pdr4h)]

Eleanor,



By using multiple <harm> elements, one can assign multiple harmonic labels, even the incorrect, printed ones you refer to.  Using @hfunc, however, (should we add it) one could assign only one.



I think the choice is up to the encoder.  There are many reasons why one would choose an attribute over an element or vice versa.  For some encoders, a simple file structure where only one label can be assigned and/or values can be easily contrained is important.  For others, in order to perform the kind of analysis you mention, multiple labels will be the way to go.



Neither path hinders further development.



--

p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Eleanor Selfridge-Field [esfield at stanford.edu]
Sent: Monday, April 23, 2012 4:56 PM
To: 'Music Encoding Initiative'
Subject: Re: [MEI-L] analysis

I had intended to respond to Maja: I’m so accustomed to Humdrum, which allows multiple labels to be assigned, that I find the either/or question difficult. In the Humdrum files themselves, multiple harmonic labels may be used (and have been very useful in comparative studies).

A single chord can have one function in the designated key but quite another in a modulatory context. That distinction enables Craig to generate keyscapes reconciled to one key (good for comparison between works) or to see key-specific usage (good for understanding how individual composers operate).

There is also chord quality: major/minor/augmented/diminished, plus inversion types, plus extended harmonies (7th, 9th, et al).

How much of all this MEI wants will depend on whether or not it wants to support harmonic analysis, basso continuo realization (let’s say in sound; but don’t stage too much on this—the printed labels are often full of errors and impossibilities), etc.

For now, it could be left fairly simple, provided that nothing interferes with expansion of capabilities later.

Eleanor


Eleanor Selfridge-Field
Consulting Professor, Music (and, by courtesy, Symbolic Systems)
Braun Music Center #129
Stanford University
Stanford, CA 94305-3076, USA
http://www.stanford.edu/~esfield/



From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h)
Sent: Monday, April 23, 2012 12:11 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] analysis


Hi, Maja,



We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels.  I could be wrong though, if <harm> were defined only to be used for transcription and not analysis.  Anyone else have thoughts on this?



--

p.



__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de]
Sent: Thursday, April 19, 2012 3:33 AM
To: Music Encoding Initiative
Subject: [MEI-L] analysis
Dear List,

writing the guidelines of the analysis module, I am wondering about the use of the @hfunc.
It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else.
But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed.
In my opinion it would make sense to use the @hfunc also on chords for describing the function of it
in a musical work, such as a "tonic" or something like that.
So I think the att.chord.anl should be memberOf att.harmonicfunction.
Is it a bug or any other opinions?

Best regards,
Maja


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120423/af10b094/attachment.html>