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

[Johannes Kepper]

Hi all,

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. If we pick one, we can spare at least some tools from this additional effort. 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. 
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. 

After all, I could back a decision for concert pitch, but I think it would be a very bad choice to allow both directions at the same time. We only add unnecessary complexity, processing efforts and a potential source for trouble without a need.

Best regards,
Johannes




Am 11.02.2012 um 23:26 schrieb Roland, Perry (pdr4h):

> Hi, Craig, Mike, everyone,
>  
> Thanks for jumping in.
>  
> It's a good idea to use written pitch in MEI because 1) it's the only thing naive encoders (human and mechanical) know about the notation and 2) MusicXML is often the source of MEI data.  BTW, if I remember correctly, the MusicXML documentation says that pitch should be encoded at sounding pitch, but in practice most implementations use written pitch.
>  
> However, MEI doesn't have to limited to encoding written pitch -- there must to be a way of stating whether the document captures written pitch (with transposition to concert pitch) or vice versa.  So, I propose adding another attribute (trans.method, trans.dir, or similar name) that takes the values "toConcert" or "toWritten" in order to capture the "state of the data" as Craig called it, as well as the target.  The assumption is that "toConcert" means that the data is captured "asWritten" and vice versa.  Even though I agree with Mike that encoding written pitch is a better starting point, the extra attribute permits MuseData-style, concert pitch encodings too.
>  
> With the addition of this new attribute, in the case of the Bb clarinet, trans.diat and trans.semi can accommodate the values "1" and "2" or "-1" and "-2", depending on the pitch-encoding style.
>  
> The presence of any of the @trans* attributes is contextual.  Of course, a non-transposing staff won't use them at all.  If a diatonic transposition is desired, as Craig pointed out, @trans.diat and @trans.semi must both be given.  However, if a base-12 MIDI pitch is enough, only @trans.semi is necessary.  However, if @trans.diat or @trans.semi is present, @trans.dir must be present.  The bottom line is that all these attributes must be optional and the context of their use controlled by schematron.
>  
> --
> p.
> 
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com]
> Sent: Saturday, February 11, 2012 4:33 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] @trans.diat and @trans.semi
> 
> Hi Myke,
> 
> On Sat, Feb 11, 2012 at 12:04 PM, Michael Scott Cuthbert <cuthbert at mit.edu> wrote:
> 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. 
> 
> Yes, there will be cases where the transposition for a transposing instrument may alternate between enharmonic equivalents within the same movement.  A good example is Tchaikovsky's Romeo and Juliet overture-fantasy:
>    http://imslp.org/wiki/Romeo_and_Juliet_%28overture-fantasia%29_%28Tchaikovsky,_Pyotr%29
> In this piece the first two keys are A major and A-flat major.  The Clarinet in A is notated with C major and B major, rather than C major and C-flat major.  
> 
> I just encoded this work via OMR with SharpEye from the parts.  I prepared MuseData files for Walter in written pitch, and then he transposes to concert pitch and adds a transpotion-to-written-pitch code in the MuseData files (similar to Humdrum), since MuseData files for printing are stored in concert pitch with transposition instructions given for generating written pitch spellings.  In measure 1 of the A clarinets, there will be an instruction to transpose up a minor third, while in measure 21 there will be an instruction to transpose up a diminished second (enharmonically equivalent to a minor third).
> 
> Written parts for timpani are complicated--parts are displayed transposed, and there is no key signature notated (invisible key signature :-).
>  
> > And in pieces for band, learning ensembles, etc., individual notes will be written enharmonically.  So that a concert-pitch passage, C, D, D#, E#, F# might be written as D, E, F, G, Ab so as to avoid needing using double sharps or augmented intervals.  Notating the score in written pitch is the better way to avoid this problem. 
> This is a good point, but can also be handled by a constant transposition system.  The enharmonic spelling would be stored in the sounding-pitch spellings, rather than changed afterwards once the written notes are calculated.  In other words the written pitches
>     D E F G Ab
> are represented in concert pitch as:
>     C D Eb F Gb
> and not as
>     C D D# E# F#
> 
> What you would like to have is the clarinet’s notes displaying as “C D  D# E# F#” when the score is viewed in concert pitch (so it matches the rest of the ensemble) and “D E F G Ab” when viewed transposed; the alternate representation (“C D Eb F Gb”) represents a passage that doesn’t appear in either a concert-pitch score or on the performers’ parts. It may be too difficult to encode such things but they’re frequently done instinctively by skilled copyists.
> 
> The key phrase is "skilled copyist" which computers cannot be (not to mention "instictively" :-).  In other words, to use the same data for generating a transposed part and a concert-pitch score, you would probably use variants in MEI.  One variant specifies how to display it in the transposed part, and the other variant for the concert-pitch score.   
> 
> Transposition without enharmonic alteration is deterministic, so the written variant could equally be stored in concert pitch or written pitch.  If you are going to be utilizing enharmonic equivalents, then neither system is better (if you are going to want to display in both written-pitch and concert-pitch).
> 
> Humdrum and MuseData encode parts in concert pitch.  I just checked, and MusicXML does it the other way.  Here is a C-sounding pitch in a B-flat clarinet part which includes a transpose-to-concert-pitch instruction:
> 
>   <part id="P2">
>     <measure number="1" width="913">
>       <attributes>
>         <divisions>1</divisions>
>         <key>
>           <fifths>2</fifths>
>           <mode>major</mode>
>         </key>
>         <time>
>           <beats>4</beats>
>           <beat-type>4</beat-type>
>         </time>
>         <clef>
>           <sign>G</sign>
>           <line>2</line>
>         </clef>
>         <transpose>
>           <diatonic>-1</diatonic>
>           <chromatic>-2</chromatic>
>         </transpose>
>       </attributes>
>       <sound tempo="120"/>
>       <note default-x="126">
>         <pitch>
>           <step>D</step>
>           <octave>4</octave>
>         </pitch>
>         <duration>4</duration>
>         <voice>1</voice>
>         <type>whole</type>
>       </note>
>       <barline location="right">
>         <bar-style>light-heavy</bar-style>
>       </barline>
>     </measure>
>   </part>
> 
> 
> The <transpose> tag is vague, as Perry was pointing out for MEI's equivalent.  It should more verbosely be <how-to-transpose-to-concert-pitch> in contrast to <how-to-transpose-to-written-pitch>.  But it seems that the MusicXML convention is to encode the part already transposed, and then indicate the transpostion from written -> concert pitch.
> 
> It would be useful specify the state of the data (written or concert) and also an explicit direction that the transposition represents (such as written->concert or concert->written).  When going in the opposite direction the transposition interval could be reversed without confusion,  such as concert data with a written->concert transposition could generate the written data by negating the written->concert transposition.
> 
> -=+Craig
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l