Hello,<div><br></div><div>I'm also a supporter of MEI as firstly being a document-oriented format, so the written pitch should be preferred in my opinion. We need to make sure, though, that enough information is provided to compute the transposition for analytical purposes and for exporting to other formats, and it seems that the attributes in question are the place where to express this information.</div>

<div><br></div><div>If I understand correctly, this does not fully solved what Michael pointed out:</div><div><br></div><div><span style>"The issue is that you want to be able to change the transposition for different passages, and I don’t think that changing the Instrument tag is the best approach."</span></div>

<div><span style><br></span></div><div><font face="Calibri, sans-serif">Do we perhaps need a way to specify when and how the transposition rules are supposed to change within a piece? Is re-defining staffDef the best way?</font></div>

<div><font face="Calibri, sans-serif"><br></font></div><div><font face="Calibri, sans-serif">Best,</font></div><div><font face="Calibri, sans-serif">Raffaele</font></div><div><br><div class="gmail_quote">On Mon, Feb 13, 2012 at 11:08 AM, TW <span dir="ltr"><<a href="mailto:zupftom@googlemail.com">zupftom@googlemail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2012/2/13 Johannes Kepper <<a href="mailto:kepper@edirom.de">kepper@edirom.de</a>>:<br>
<div class="im">> Am 13.02.2012 um 04:03 schrieb Craig Sapp:<br>
><br>
><br>
>><br>
</div><div class="im">>> 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>
> Brilliant idea! I haven't spent a thought on the iron for this purpose, but you're absolutely right, that's the ideal place to resolve it. We will put it on the MEIron Todo… But, I would still argue that deciding for one direction is crucial to avoid any confusion about this. The MEIron would then only provide a one-way translation, as this would only be a first step in processing the data and turning them into something else. It would not be an officially supported state of an MEI file that one would save as interchangeable file*. Did I hear correctly that you would prefer written pitch as well? So, any other opinions out there?<br>


><br>
<br>
</div>From my perspective, written pitch is the way to go.  Transposing has<br>
a lot of impact on the appearance (stem direction, accidental<br>
arrangement, placement of beams/slurs, placement of articulation marks<br>
etc.).  MEI can provide information about all this, but is this<br>
sensible if sounding pitch rather than visual pitch is recorded?  I'm<br>
not sure whether it would be a good idea to transform all visual stuff<br>
to a separate layout tree.<br>
<br>
Thomas<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div></div></blockquote></div><br></div>