[MEI-L] analysis

Tue Apr 24 19:36:46 CEST 2012

Hi,
ok that clarifies the issue with the @inth and the @mfunc.

Isn´t it difference enough to encode harmonic function on the one hand with an attribute and on the other to have the possibility to encode it with the harm element? We have this opportunity with other elements/attributes, too.
I still think the @hfunc would make sense on chords when it would be used for describing functions. Another difference might be, that using the @hfunc is only intended for analytical purposes.

But I know, the schema is still frozen!

Maja

P.S.: Yes, I really like vanilla ice cream...:-)

-------- Original-Nachricht --------
> Datum: Tue, 24 Apr 2012 12:31:20 +0000
> Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>
> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
> Betreff: Re: [MEI-L] analysis

> 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
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a