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

[Craig Sapp]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120211/1927e0c8/attachment.html>