[MEI-L] @trans.diat and @trans.semi

[TW]

2012/2/13 Johannes Kepper <kepper at edirom.de>:
> Am 13.02.2012 um 04:03 schrieb Craig Sapp:
>
>
>>
>> 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.
>
> 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?
>

>From my perspective, written pitch is the way to go.  Transposing has
a lot of impact on the appearance (stem direction, accidental
arrangement, placement of beams/slurs, placement of articulation marks
etc.).  MEI can provide information about all this, but is this
sensible if sounding pitch rather than visual pitch is recorded?  I'm
not sure whether it would be a good idea to transform all visual stuff
to a separate layout tree.

Thomas