Hi MEIers,<br><br><div class="gmail_quote">On Sun, Feb 12, 2012 at 2:22 PM, Johannes Kepper <span dir="ltr"><<a href="mailto:kepper@edirom.de">kepper@edirom.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I would like to add some more points to this discussion. In my opinion, allowing both directions of transposition in MEI is the worst decision we could ever make. This would require absolutely every application dealing with MEI files to be capable of calculating the pitches as it needs them.<br>
</blockquote><div><br>It will be less confusing if the transposed parts were stored in the transposed state. And I have looked more closely at a MuseData part and now see that they are stored in the written (transposed) form. Here is the start of the 1st clarinet (in A) which has an F5 of the transposed form (see the score: <a href="http://www.musedata.org/cgi-bin/mddata?work=beet/bh/sym/no2&file=distrib/pdf/score-hand/work.pdf">http://www.musedata.org/cgi-bin/mddata?work=beet/bh/sym/no2&file=distrib/pdf/score-hand/work.pdf</a> )<br>
<br>Breitkopf & H\a3rtel, Leipzig, Series 1 No. 2<br>Beethoven Symphony No. 2 in D Major, Op. 36<br>Mvt. 1<br>Clarinetto 1 in A<br>0 0<br>Group memberships: sound<br>sound: part 5 of 18<br>$ K:-1 Q:24 T:3/4 C:4 X:-11 D:Adagio molto<br>
F5 3 t d ff<br>measure 1<br>F5 36 q. d F<br>rest 12 e<br>rest 24 q<br>measure 2<br>rest 72<br>measure 3<br>rest 72<br>measure 4<br>rest 24 q<br>rest 12 e<br>
G5 9 s. d [[ p.<br><br>The "$.. X:-11" information indicates how to get from the written form to the concert pitch form (-11 means transpose down a minor third). So I think that the original form of the MEI transposition attributes are intended to mean the same thing (likewise MusicXML). B-flat clarinets parts would be encoded in the transposed state, with @trans.diat="-1" and @trans.semit="-2" given to indicate how to get to concert pitch from the written state of the data. <br>
<br>So since both MuseData and MusicXML store transposed parts in transposed form, it is a wise idea to do the same in MEI. (This also explains why I have to fix some transpositions in Haydn symphony data converted from MuseData to Humdrum which does not have the transposition information necessary to get to concert pitch).<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> If MEI stores concert pitch, this would be more natural to sound-focused apps (-> MIDI exporters) and for music analysis. If it keeps written pitch, it would be much easier for renderers, OMR and hand encoders not sure what they're facing.<br>
</blockquote><div><br>So you can guess what Perry will say :-)<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It might be my personal focus to understand MEI as being somewhat document-centric, but there is another argument to choose written pitch: MIR tools are normally operating on simplifications of the original data (n-grams etc.), but not on data as complex as pure MEI. If they're abstracting anyway, adding the step of transposition to their calculations seems less demanding to me than to require a renderer to "misplace" every single note.<br>
</blockquote><div><br>Transposition is fairly trivial and deterministic, so a renderer which has problems with transposition will most likely have lots of other bugs in it... <br><br>MEI Iron is the ideal place to simplify the data to a standardized form. The user/application could specify to MEI Iron that they want transposed data to end up in the written state or the concert-pitch state, then no matter what the original state of the data, the output from MEI Iron is what is desired. When a part-generating program wants the data in transpose form, it asks MEI Iron for the transposed state of the data, when a MIDI-generating program want the data in concert pitch, it asks MEI Iron for data in the untransposed state. When a renderer needs to display the score in concert-pitch, it could alternately ask MEI Iron for data in the concert-pitch state.<br>
<br>-=+Craig<br><br></div></div><br><br>