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

[Raffaele Viglianti]

Hello,

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.

If I understand correctly, this does not fully solved what Michael pointed
out:

"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."

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?

Best,
Raffaele

On Mon, Feb 13, 2012 at 11:08 AM, TW <zupftom at googlemail.com> wrote:

> 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
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120213/2bf5db41/attachment.html>