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

[Craig Sapp]

Hi MEIers,

On Sun, Feb 12, 2012 at 2:22 PM, Johannes Kepper <kepper at edirom.de> wrote:

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

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:
http://www.musedata.org/cgi-bin/mddata?work=beet/bh/sym/no2&file=distrib/pdf/score-hand/work.pdf)

Breitkopf & H\a3rtel, Leipzig, Series 1 No. 2
Beethoven Symphony No. 2 in D Major, Op. 36
Mvt. 1
Clarinetto 1 in A
0 0
Group memberships: sound
sound: part 5 of 18
$  K:-1   Q:24   T:3/4  C:4  X:-11  D:Adagio molto
F5     3        t     d         ff
measure 1
F5    36        q.    d         F
rest  12        e
rest  24        q
measure 2
rest  72
measure 3
rest  72
measure 4
rest  24        q
rest  12        e
G5     9        s.    d  [[     p.

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.

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


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

So you can guess what Perry will say :-)

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

Transposition is fairly trivial and deterministic, so a renderer which has
problems with transposition will most likely have lots of other bugs in
it...

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.

-=+Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120212/fdcd09af/attachment.html>