How to represent differences between concert scores and transposed parts

[joeberkovitz]

Concert score and transposed parts vary in ways that are not fully determined by any algorithm. How can CWMNX represent these differences? They include spelling, cues, more...

[mogenslundholm]

Sounding or written pitch: It seems to me that there are not only two ways to look at a tone - there are three points of view: The "sounding pitch", the "ink spot" and the "name" of the note.

Sounding and Written pitch in MusicXML:

1. Clefs: e.g. G, G8 etc. The pitch noted is the sounding pitch
2. Transpose: The pitch noted is the written pitch
3. Octava: The pitch noted is the sounding pitch
4. Harmonic: The pitch noted may be the written pitch or sounding pitch depending on the appearence of "natural", "artificial", "base-pitch", "touching-pitch" and "sounding-pitch".

Note the problem that the pitch include "alter values", which are definitely affecting the "sounding pitch" but in MusicXML appearing in the "written pitch". In MNX the alter value is part of the pitch declaration.

When considering Bb-instruments, things are quite clear. But some instruments like oud have several different tunings and may be shown transposed. But since it may be played with different temporaments, should the alter values then be like not transposed or should the transpose value be some fraction e.g. 7.134 according to the used temperament?
(Not easy to define a fraction in MusicXML like <diatonic>-1.1</diatonic>, but MNX could only have <chromatic>-definition).
Shall the transpose scheme allow you to put your fingers on the instrument out from the "ink spots" on the paper no matter what tuning the instrument has?

It seems to me that the only real thing is the sounding pitch. The notation program should provide means to specify transposed instruments and must know how to show this and for which instruments.
/Mogens

[th-we]

@mogenslundholm I believe your comment is off-topic for this issue. Whether to encode written or sounding pitch is to be discussed in #4, right? There will be one encoding - be it sounding or written - from which different renderings need to be created. As @joeberkovitz wrote, this issue is about the aspects that are not fully determined by any algorithm, such as spelling, cues, more....

Problems I see are:

• Accidental choices that are not 1:1 translatable between sounding/transposing
  • when using a different enharmonic for readability reasons (as enharmonic differences don't really matter semantically in chromatic passages or atonal music)
  • choices for cautionary accidentals might differ
  • trumpets/french horns get no key signature in traditional notation, hence the accidental situation can differ greatly between sounding and transposing pitch, be it in a concert pitch score or when used as cues for other instruments in other transpositions (also might be a problem with keyless timpanis).
• Necessity for ottava signs can be very different between sounding and transposing (which is a very good reason for deviating from MusicXML in actually encoding the sounding octave of notes, not the written octave)
• @joeberkovitz mentioned cues that are rendered in parts, but not in the score (independent of whether the score is sounding or transposing)

[mogenslundholm]

If there is a problem - lets solve it. If there is something formal error - lets move the item to anywhere you think is right.

1. I think it should be possible to solve the problem, which is: Find an unambigious transpose algoritm.
   A problem is the three overlapping keys (Db/C#, F#/Gb and H/Cb). You may even have more if you
   continue after C#-major with G# etc..

2. In MusicXML an Ottawa is sounding pitch. The ottawa is a placed in the written score. What is the problem?

3. Cues: About cues: Do you mean cue notes? Where is the problem with pitch?

Could you add a little more information about this?

/Mogens

[joeberkovitz]

I was not clear enough when I filed this... I'll attempt to clarify.

With respect to spelling of key signatures and accidentals in transposed or concert parts, there are at least two facets to the problem. One is to define a standard, unambiguous algorithm for mapping back and forth between the two spelling systems (which the CG might fail to do, if it's deemed something that different applications should be allowed to compete on -- personally, I favor defining one). The other facet is: whether to allow explicit specification of spelling, overriding the defaults provided by the algorithm.

The octava problem exists, but I think it is pretty straightforward as described by @th-we. Note that it is possible that the scope of octave transposition may vary throughout a part.

The business with cue notes has nothing to do with pitch - It has to do with visibility, whether the cues are visible or not. Often these only make sense to show in a transposed part being viewed by the performer, not in a full score being viewed by a conductor or music director.

[joeberkovitz]

I've been moving towards a unified approach to this and a variety of other issues; please let's carry the discussion to #138 (at least for now) and see if that proposal will work! Thanks.

[notator]

According to the current proposal for grouping parts, a full score and its parts can be separately printable objects inside a single <mnx-common> element.

First thoughts about transposed parts:
Transposition is often a matter of taste (like an "arrangement"). So a transposed part should have a separate <part> definition. A score written at concert pitch would use the "untransposed" definition, the part-score would use the "transposed" version. That's a maintenance problem, but maybe there's no way round it.
However: If an application knows that a <part> definition is both untransposed and used in an untransposed <score>, it could make a transposed copy of it (automatically), and then allow the user to tweak it, before saving it in the file and using it in the part-score.

The <mnx-common> element would look something like this:

<mnx-common>
    <!-- like the globals defined in §6.1.7 in the current spec -->
    <globals>...</globals>

    <!-- like the parts defined in §6.1.7 in the current spec -->
    <parts>
        <!-- part definitions -->
        <part id="clarinet1untransposed" name="Clarinet 1 in Bb and A (untransposed)" >...</part>
        <part id="clarinet1transposed" name="Clarinet 1 in Bb and A (transposed)" >...</part>
        <!-- etc. more part definitions -->
    </parts>

    <!-- global systemLayout-definitions (optional) -->
    <systemLayouts>...</systemLayouts>

    <!-- all the scores in this mnx-common element -->
    <scores>
        <!-- full score uses the part with id="clarinet1untransposed" -->
        <score name="Full Score">...</score>

        <!-- part uses the part with id="clarinet1transposed" -->
        <score name="Clarinet 1 part">...</score>

        <!-- etc., all the part "scores" (booklets) -->
    </scores>
</mnx-common>

[begin edit]
A further thought: If the only difference between the transposed and untransposed <part> definitions is the representation of the pitches, maybe there's some way to link the two...
[end edit]

[adrianholovaty]

Marking this closed in favor of #287.