[MEI-L] Jazz Chords in MEI ?

[Etienne Fréjaville]

Hello Perry,

Thank you very much for the answer.

I don't come back to display the chord labels, that's clear even if using
svg is probably not the ideal solution.

Concerning the harmony, first of all, I hadn't caught that <chordDef> was
to capture information related to the chord tablature grid (and not
harmonic analysis).

If chordDef can be used to encode voicings (in Jazz it's seldom that
voicings are encoded), but I note that it can be achieved through the
chordMember element:

If I wanted for example to encode a C-7 Monk voicing, I'd probably have a
c/b flat or c/b flat/d (an added 9th). That’s perfect!

But aside from voicings, it's harmonic analysis that I'd like to be
encoded for piano for example.

What I don't get clearly is that I don't need to designate with Jazz
chords the exact note that is altered. For instance in D-7b5, I know that
it's "a" that has a diminished 5th. So it would be strange to mark, either
on a <note> or a <chordMember> (by making <chordMember> a member of the
att.harmonicFunction attribute class*) : pname="a" deg="5-".

The simplest way would be to do as it's in MusicXML, say that the kind**
of chord is a half-diminished chord of D (the root note).

Besides, if I want to extract from the score all the chords/notes that
have a half-diminished chord, I'll have to  search for all chordDef that
have a deg="3-", a deg="5-" and deg="7". Then search all notes/chords at
the timestamp specified by the matching chordDef(s).

Probably much more complex than searching all chords that have a <kind>
element whose value is "half-diminished".

Again I hope I was clear.

Thanks.

Etienne

*Don't know how.
** there are about 33 different kinds of jazz chords for a given note.



Le 02/12/2019 20:55, « Roland, Perry D (pdr4h) » <pdr4h at virginia.edu> a
écrit :

>
>Hello Etienne,
>
>Your example should look like this --
>
><score xmlns="http://www.music-encoding.org/ns/mei"
>xmlns:svg="http://www.w3.org/2000/svg">
>  <scoreDef>
>    <chordTable>
>      <chordDef xml:id="DminDom5f">
>        <chordMember pname="g" oct="3"/>
>        <chordMember pname="d" oct="4"/>
>        <chordMember pname="f" oct="4"/>
>        <chordMember pname="a" accid.ges="f" oct="4"/>
>        <chordMember pname="c" oct="4"/>
>      </chordDef>
>      <chordDef xml:id="GDom5s">
>        <chordMember pname="g" oct="4"/>
>        <chordMember pname="b" oct="4"/>
>        <chordMember pname="d" accid.ges="s" oct="4"/>
>        <chordMember pname="f" oct="4"/>
>      </chordDef>
>    </chordTable>
>    <symbolTable>
>      <symbolDef xml:id="mySymbol">
>        <svg:svg>
>          <!-- SVG for the chord label here -->
>        </svg:svg>
>      </symbolDef>
>    </symbolTable>
>    <staffGrp>
>      <staffDef n="1" lines="5" clef.shape="G" clef.line="2"/>
>    </staffGrp>
>  </scoreDef>
>  <section>
>    <measure n="1">
>      <staff n="1">
>        <layer n="1">
>          <note pname="a" dur="2" oct="5"/>
>          <note pname="g" dur="4" oct="5"/>
>          <note pname="g" dur="4" oct="5"/>
>        </layer>
>      </staff>
>      <harm chordref="#DminDom5f" staff="1" tstamp="1"
>rendgrid="gridtext">D<rend rend="sup"
>        >-7b5</rend>/G</harm>
>      <!-- Alternative markup for the preceding harmonic label -->
>      <!-- <harm chordref="#DminDom5f" staff="1" tstamp="1"
>rendgrid="gridtext">
>                <symbol altsym="#mySymbol"/>
>              </harm> -->
>      <harm chordref="#GDom5s" staff="1" tstamp="3"
>rendgrid="gridtext">G<rend rend="sup"
>        >7#5</rend></harm>
>    </measure>
>  </section>
></score>
>
>1. <chordMember> elements must be children of <chordTable>.
>
>2. The bass note of the first chord should be included in the
>spelling-out of the chord tones.  Since the goal of the <chordDef> is to
>capture information related to the chord tablature grid (and not harmonic
>analysis), there's no need to mark the harmonic function of each "note";
>that is, marking the root or any of the other chord tones isn't
>necessary.  If you feel otherwise, you can advocate for making
><chordMember> a member of the att.harmonicFunction attribute class.  This
>would add the @deg attribute, which is where one can record scale degree
>info.
>
>3. The superscripted portion of a label can be marked using the <rend>
>element. However, using markup to get the "G" to be under the "D7b5"
>portion of the label is straying too far from semantic markup.  In any
>case, I don't believe Verovio (the MEI renderer) supports the <stack>
>element yet.  So, if you require a precise rendition of the label that's
>unachievable with <rend>, you can define a symbol (using <symbolTable>
>and <symbolDef> elements) and refer to it inside the <harm> element.  See
>the commented-out <harm> element for an example.
>
>4. I don't quite understand your last comment, but I'll address what I
>think you're getting at.  Please let me know if I miss the mark.  Yes,
>there are innumerable ways in which a given chord (say "D7b5") can be
>performed/voiced on the guitar.  If one doesn't care which is to be
>played, then a simple label can be used; that is, "D7b5".  In this case,
>the performer can choose how/where to play the chord and no chord
>definition is necessary.  However, if a particular voicing is desired,
>then the way to do that is to explicitly encode the chord in a
><chordDef>. But this only has to be done once.  Anywhere in the piece
>where the chord is expected to be played, the <chordDef> can be referred
>to without re-encoding the note-spelling of the chord.  The label
>("D7b5") and/or the chord tab grid can be rendered.  This not only
>reduces the amount of encoding required to represent chord tab grids, but
>it also decouples the label from the grid, meaning that one can use the
>traditional label "Cm7♭5" or "Cm7" with a superscript "o" or any other
>chord labeling scheme which all refer to the same grid.  You can also
>refer to a chord definition outside the current MEI file, which means you
>can put the definition of a chord in a particular inversion/voicing in an
>external file and refer to it from many MEI documents.  So, yes, there
>may be 33 different possibilities for "D7b5", but they only have to be
>captured once.
>
>Hope this helps,
>
>--
>p.
>
>_______________________________________________
>mei-l mailing list
>mei-l at lists.uni-paderborn.de
>https://lists.uni-paderborn.de/mailman/listinfo/mei-l