<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 13 March 2017 at 04:08, Thomas Weber <span dir="ltr"><<a href="mailto:tw@notabit.eu" target="_blank">tw@notabit.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:2wn" class="gmail-a3s gmail-aXjCH gmail-m15ac75d981a5d309">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.<br>
<br>
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.</div></blockquote></div><br>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:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"> <score></div><div class="gmail_extra"> <scoreDef xml:id="scoredef-311854"></div><div class="gmail_extra"> <staffGrp xml:id="staffgrp-352709"></div><div class="gmail_extra"> <staffDef xml:id="staffdef-922725" clef.shape="G" clef.line="2" meter.count="4" meter.unit="4" n="1" lines="5" /></div><div class="gmail_extra"> </staffGrp></div><div class="gmail_extra"> </scoreDef></div><div class="gmail_extra"> <section xml:id="section-0000001991177130"></div><div class="gmail_extra"> <measure xml:id="measure-L3" n="1"></div><div class="gmail_extra"> <staff xml:id="staff-L3F1N1" n="1"></div><div class="gmail_extra"> <layer xml:id="layer-L3F1N1" n="1"></div><div class="gmail_extra"> <note xml:id="note-L4F1" dur="4" oct="5" pname="f" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L5F1" dur="4" oct="5" pname="a" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L6F1" dur="4" oct="5" pname="c" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L8F1" dur="4" oct.ges="6" oct="5" pname="e" accid.ges="n"/></div><div class="gmail_extra"> </layer></div><div class="gmail_extra"> </staff></div><div class="gmail_extra"> <octave xml:id="octave-0000001759794455" staff="1" startid="#note-L8F1" endid="#note-L13F1" dis="8" dis.place="above" /></div><div class="gmail_extra"> </measure></div><div class="gmail_extra"> <measure xml:id="measure-L9"></div><div class="gmail_extra"> <staff xml:id="staff-L9F1N1" n="1"></div><div class="gmail_extra"> <layer xml:id="layer-L9F1N1" n="1"></div><div class="gmail_extra"> <note xml:id="note-L10F1" dur="4" oct.ges="6" oct="5" pname="g" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L11F1" dur="4" oct.ges="7" oct="6" pname="c" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L12F1" dur="4" oct.ges="6" oct="5" pname="g" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L13F1" dur="4" oct.ges="6" oct="5" pname="e" accid.ges="n"/></div><div class="gmail_extra"> </layer></div><div class="gmail_extra"> </staff></div><div class="gmail_extra"> </measure></div><div class="gmail_extra"> <measure xml:id="measure-L15" right="end"></div><div class="gmail_extra"> <staff xml:id="staff-L15F1N1" n="1"></div><div class="gmail_extra"> <layer xml:id="layer-L15F1N1" n="1"></div><div class="gmail_extra"> <note xml:id="note-L16F1" dur="4" oct="6" pname="c" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L17F1" dur="4" oct="5" pname="a" accid.ges="n"/></div><div class="gmail_extra"> <note xml:id="note-L18F1" dur="4" oct="5" pname="f" accid.ges="n"/></div><div class="gmail_extra"> </layer></div><div class="gmail_extra"> </staff></div><div class="gmail_extra"> </measure></div><div class="gmail_extra"> </section></div><div class="gmail_extra"> </score></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Here is the visual rendering (if images are allowed inline in the message):</div><div class="gmail_extra"><br></div><div class="gmail_extra"><img src="cid:ii_15ac86aed587c3f6" alt="Inline images 1" width="517" height="108"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">**kern</div><div class="gmail_extra">*M4/4</div><div class="gmail_extra">=1-</div><div class="gmail_extra">4ff</div><div class="gmail_extra">4aa</div><div class="gmail_extra">4cc</div><div class="gmail_extra">*8va</div><div class="gmail_extra">4eee</div><div class="gmail_extra">=2</div><div class="gmail_extra">4ggg</div><div class="gmail_extra">4cccc</div><div class="gmail_extra">4ggg</div><div class="gmail_extra">4eee</div><div class="gmail_extra">*X8va</div><div class="gmail_extra">=3</div><div class="gmail_extra">4ccc</div><div class="gmail_extra">4aa</div><div class="gmail_extra">4ff</div><div class="gmail_extra">==</div><div class="gmail_extra">*-</div><div><br></div><div>Where the *8va turns on an octave down transposition for the notes after it, until canceled by the *X8va mark. </div><div><br></div><div>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.</div><div><br></div><div>I came across a scordatura example recently which I posted in the music-encoding issues on Github:</div><div> <a href="https://github.com/music-encoding/music-encoding/issues/415">https://github.com/music-encoding/music-encoding/issues/415</a></div><div>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).</div><div><br></div><div>Here is some discussion about representing harmonics in MEI which devolved from a different issue in verovio:</div><div> <a href="https://github.com/rism-ch/verovio/issues/375#issuecomment-265260544">https://github.com/rism-ch/verovio/issues/375#issuecomment-265260544</a><br></div><div><br></div><div><br></div><div>-=+Craig</div><div><br></div><div><br></div></div></div></div>