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

[Johannes Kepper]

Hi Craig,


Am 13.02.2012 um 04:03 schrieb 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…  

I didn't say that it's rocket science to calculate pitch, I said it's an additional step that could be spared for _some_ applications. 

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

Johannes



* Maybe we should offer the other direction in MEIron as well, but I'm afraid that this would require Perry's additional attribute to indicate the current state. And if we add this to the current model, I suppose it's hard to suppress 'misuse' of this feature… Am I wrong?


> 
> -=+Craig
> 
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l