[MEI-L] analysis

Roland, Perry (pdr4h) pdr4h at eservices.virginia.edu
Tue Apr 24 14:31:20 CEST 2012 

Maja,

@inth was intended to carry numeric values (half-steps above the root), even though it seems that intention didn't get expressed properly in the move from the original RNG to ODD.  The datatype of @inth should be a list of numbers, not NMTOKENS.  This is an error that should be corrected even now in the frozen 2012 release.

Though its use would be somewhat rare, @mfunc is allowed on chords because they can have a melodic function as well as a harmonic one, as in the case of so-called "passing chords".  I suppose this could be subsumed into @hfunc, now that I think about it.  That is, a chord's harmonic function could be "non-harmonic".

If @hfunc were allowed on chords, it should have exactly the function (no pun intended) that you describe -- labeling chords with a general label, such as "tonic", "dominant", etc., not with chord labels transcribed from the document, like "Cm7".  I am still conflicted, however, whether "functional harmony" labeled with Roman numerals goes in <harm> or @hfunc.

The answer to your question about choices depends on who's answering.  :-)  Choices are often a good thing, but not when they duplicate each other -- "Would you like vanilla ice or vanilla ice cream?"  There should be a difference between how @hfunc is used and how <harm> is used.  If there's no difference, then we probably don't need both.

--
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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de]
Sent: Tuesday, April 24, 2012 3:32 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] analysis

Hi all,
thanks for the responses.
I understand that we don´t want to make more changes to the schema. I would also use the @hfunc on a note for labels such as "root" or "keynote".
But I think harmonic functions of chords encoded with the @hfunc should
also be possible, because it would allow to describe the chords function in a harmonic context such as "tonic" and so on, without switching to the harm element. In my opinion the <harm> is used to give the chords a name but not a function, or to describe figured bass numbers.
I also think, that it should be the decision of the encoder which way he uses for his analysis. But isn´t it a good thing to have the choice between more than one option?

I would describe the labels "third" and "fifth" etc. with the @inth. Or for what is the use of @inth intended?
The question came up when I was writing the analysis chapter of the guidelines and I would like to avoid any misunderstandings!
Best regards,
Maja

P.S.: And why again is the @mfunc allowed on a chord? :-)


Am 23.04.2012 um 23:41 schrieb Roland, Perry (pdr4h):

> Given the current definition of hfunc one should not "do his analysis" of chords using the hfunc attribute.
>
> The att.harmonicfunction class is for attributes describing the harmonic function *of a single pitch* in a chord.  It was intended for labels such as "root", "third", "fifth", etc.  This is why it's available on note but not on chord.
>
> <classSpec ident="att.harmonicfunction" module="MEI.analysis" type="atts">
>  <desc>Attributes describing the harmonic function of a single pitch</desc>
>  <attList>
>    <attDef ident="hfunc" usage="opt">
>      <desc>describes harmonic function in any convenient typology.</desc>
>      <datatype>
>        <rng:data type="NMTOKEN"/>
>      </datatype>
>    </attDef>
>  </attList>
> </classSpec>
>
> Chord labels, like "Cm7", or indications of harmonic functionality, like "ii7", belong in <harm>, unless we expand the definition of att.harmonicfunction and, in all likelihood, its datatype.
>
> It seems to me that we need right now is better documentation in the Guidelines, not more changes to the schema.  We can consider this topic again at a later date.
>
> --
> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de]
> Sent: Monday, April 23, 2012 4:30 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] analysis
>
> Hi both,
>
> I would argue that for consistency's sake we should add @hfunc to chords. If one does his analysis using this attribute on notes, why should he switch to <harm> on chords?
>
> jo
>
>
> Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h):
>
>> 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 [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
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l


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

More information about the mei-l mailing list