[MEI-L] sounding vs. written pitch, <octave>
Craig Sapp
craigsapp at gmail.com
Mon Mar 13 17:48:44 CET 2017
On 13 March 2017 at 04:08, Thomas Weber <tw at notabit.eu> wrote:
> For <octave> transpositions, it seems to be the convention that the
> written pitches (ignoring the <octave> line) are encoded. I suspect that
> this is not a conscious and well founded decision but "just happened" like
> that because all the exporters/importers (and scorewriters themselves)
> lazily treat ottava lines as if they were generic lines without pitch
> related meaning - similar to hairpins, pedal markings etc.
>
> I think the more useful way of encoding ottava situations would be to
> encode the actual logical pitch with @pname/@oct - that would be equivalent
> to the sounding pitch on non-transposing instruments. In any case, the
> specs should not leave it open what encoding approach to take.
>
Yes, notes encoded under an ottava mark (<octave>) use the written pitch
(SCORE-style encoding). For use in verovio, I also give an optional
@oct.ges to allow proper generation of MIDI files for the music:
<score>
<scoreDef xml:id="scoredef-311854">
<staffGrp xml:id="staffgrp-352709">
<staffDef xml:id="staffdef-922725"
clef.shape="G" clef.line="2" meter.count="4" meter.unit="4" n="1" lines="5"
/>
</staffGrp>
</scoreDef>
<section xml:id="section-0000001991177130">
<measure xml:id="measure-L3" n="1">
<staff xml:id="staff-L3F1N1" n="1">
<layer xml:id="layer-L3F1N1" n="1">
<note xml:id="note-L4F1" dur="4"
oct="5" pname="f" accid.ges="n"/>
<note xml:id="note-L5F1" dur="4"
oct="5" pname="a" accid.ges="n"/>
<note xml:id="note-L6F1" dur="4"
oct="5" pname="c" accid.ges="n"/>
<note xml:id="note-L8F1" dur="4"
oct.ges="6" oct="5" pname="e" accid.ges="n"/>
</layer>
</staff>
<octave xml:id="octave-0000001759794455"
staff="1" startid="#note-L8F1" endid="#note-L13F1" dis="8"
dis.place="above" />
</measure>
<measure xml:id="measure-L9">
<staff xml:id="staff-L9F1N1" n="1">
<layer xml:id="layer-L9F1N1" n="1">
<note xml:id="note-L10F1" dur="4"
oct.ges="6" oct="5" pname="g" accid.ges="n"/>
<note xml:id="note-L11F1" dur="4"
oct.ges="7" oct="6" pname="c" accid.ges="n"/>
<note xml:id="note-L12F1" dur="4"
oct.ges="6" oct="5" pname="g" accid.ges="n"/>
<note xml:id="note-L13F1" dur="4"
oct.ges="6" oct="5" pname="e" accid.ges="n"/>
</layer>
</staff>
</measure>
<measure xml:id="measure-L15" right="end">
<staff xml:id="staff-L15F1N1" n="1">
<layer xml:id="layer-L15F1N1" n="1">
<note xml:id="note-L16F1" dur="4"
oct="6" pname="c" accid.ges="n"/>
<note xml:id="note-L17F1" dur="4"
oct="5" pname="a" accid.ges="n"/>
<note xml:id="note-L18F1" dur="4"
oct="5" pname="f" accid.ges="n"/>
</layer>
</staff>
</measure>
</section>
</score>
Here is the visual rendering (if images are allowed inline in the message):
[image: Inline images 1]
If I did not add @oct.ges to the notes, then the <octave> mark would have
to be processed to calculate @oct.ges on the notes it applies to before the
note's pitch could be converted to MIDI. The current MDI conversion in
verovio does not do that, so that is why I add them myself.
I haven't dealt with transposing instruments and ottavas yet, but I would
expect @oct.ges (and @pname.ges/@accid.ges) to actually work in the logical
written domain rather than the logical sounding domain: the @*.ges for a
transposed part for a clarinet would reference the transposed pitch rather
than the sounding pitch (if there was a transposing directive encoded in
the MEI data for the part). If the true sounding pitch were used in
@*.ges, then <octave> and harmonics, then that would get messy when you
want to change a part from one transposition to another (such as print a
clarinet part in B-flat when the original data was in A).
Scordatura causes interesting problems. This basically changes the
instrument into a partially transposing instrument. And to make it more
complicated is that the same written pitch could be transposed or not
transposed (depending on which string of a violin is playing the written
note, for example). For scordatura, there should be a local transposition
attribute on the <note> level. To get the sounding pitch of a note, and
@*.ges information would be the logical pitch (tied to the written pitch)
which then would be unpacked first by doing the scordatura transposition
local on the note, and then the global transposition for the part.
Brass instrumental parts would add a minor complication (particularly
French horn), since the transposition is not necessarily global for the
<score> but rather for <section>s.
Humdrum **kern data takes the exact opposite approach, always encoding the
sounding pitch. Then modifiers can be added to the data to work backward
to the written pitch. Here is the Humdrum encoding of the same music:
**kern
*M4/4
=1-
4ff
4aa
4cc
*8va
4eee
=2
4ggg
4cccc
4ggg
4eee
*X8va
=3
4ccc
4aa
4ff
==
*-
Where the *8va turns on an octave down transposition for the notes after
it, until canceled by the *X8va mark.
But mixing the Humdrum model (logical sounding pitch ) with the MEI model
(logical written pitch) would probably be messy. Creating MIDI files from
Humdrum data is relatively easy and creating written scores is relatively
hard, while for MEI it is the other way around. Note that lilypond is
closer to Humdrum in this respect. For semantic (transformational)
processing of data, the Humdrum method is easier overall in my opinion. I
am not aware that MusicXML does any semantic treatment of scordatura.
I came across a scordatura example recently which I posted in the
music-encoding issues on Github:
https://github.com/music-encoding/music-encoding/issues/415
In this music any note above G3 is scordatura, except when there is a <dir>
under the music such as "IIa" which means to play the notes on the second
string (which is not scordatura).
Here is some discussion about representing harmonics in MEI which devolved
from a different issue in verovio:
https://github.com/rism-ch/verovio/issues/375#issuecomment-265260544
-=+Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170313/6f29ce92/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-03-13 at 9.04.52 AM.png
Type: image/png
Size: 43092 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170313/6f29ce92/attachment.png>
More information about the mei-l
mailing list