[MEI-L] Jazz Chords in MEI ?

Etienne Fréjaville efreja at wanadoo.fr
Wed Dec 4 23:22:04 CET 2019


Hello Perry,

Thanks again for the answer.
In any case, I think harmonic analysis based on harmonic labels is not a
good idea.
The Jazz harmonic labels aren’t in any case standardized. The Major 7th can
be Maj7 or △ , min can be min or - , the diminished degree can be dim or °
all this can be superscripted or not, that’s the problem…
And it’s even worse if there is a necessity to use SVG for bass chords (I
don’t know how the <stack> element works).

However the @inth on <harm> to encode the intervallic content of the chord
seems to be the best place and I guess it should be able to encode all
possible jazz chords (to check with
https://en.wikipedia.org/wiki/Chord_names_and_symbols_(popular_music))

Agreed also that a @root attribute is missing on the <harm> element.
Keeping the bass note as a chordMember of the scoreDef is acceptable as it’s
an inversion of the chord, thus a voicing, that doesn’t change the harmonic
structure.
The difficulty is to identify that bass note inside the scoreDef.

Converting from/to MusicXML a fragment like this : (G6/D chord)

<harmony>
 <root>
  <root-step>G</root-step>
 </root>
 <kind text="6">major-sixth</kind>
 <bass>
  <bass-step>D</bass-step>
 </bass>
</harmony>

wouldn’t be too easy.

Therefore I think a @bass attribute on <harm> could encode this in a more
efficient manner.

Thanks

Le 03/12/2019 17:13, « Roland, Perry D (pdr4h) » <pdr4h at virginia.edu> a
écrit :

> Hi Etienne,
> 
> Of course using SVG for chord labels is not ideal, but the only other
> possibility is to create a renderer smart enough to handle all the various
> ways in which labels can be presented.  This is not so difficult for your
> "D7b5/G" example; that is, the behavior expected when processing the <stack>
> element could be tweaked, but ultimately there's a limit on how intelligent a
> renderer can be.
> 
> Turning to harmonic analysis based on harmonic labels, the obvious approach is
> to use the content of the <harm> element itself.  That is, the string "D-7b5"
> already conveys the information you're looking to encode -- a chord containing
> a diminished 5th with a root of D -- so there's no need to capture it
> elsewhere.  If you're interested in finding diminished chords with a root
> other than D, then a search for <harm> containing "-7b5" or a regular
> expression that matches the root, such as "[A-G][#-]?7b5", would work.
> 
> Another possibility is to use @inth on <harm> to encode the intervallic
> content of the chord.  For example, <harm inth="m3 d5 m7"> captures the
> intervals of the chord (so really "m3d5m7" is a substitute for
> "half-diminished"), but it doesn't capture the root.  That may be a useful
> feature to add, probably via a @root attribute, especially for those cases
> where the label doesn't indicate the root of the chord.  If that's done, then
> it's not unreasonable to add another attribute to hold a chord quality value,
> like "half-diminished", etc.  However, one could use the @type attribute to
> hold this data or use the @class attribute to point to a value in a formal
> taxonomy.
> 
> To move this discussion toward actualization, I suggest you file an issue in
> the MEI github repo to add @root to <harm>.
> 
> Hope this helps,
> 
> --
> p.
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 


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


More information about the mei-l mailing list