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

[Byrd, Donald A.]

Hi, everyone. To make a very long story very short, my change of 
careers is at least temporarily on hold, and I again have time to think 
about MEI etc.; beyond that, I can't say, though I've talked to Perry a 
bit about how I might contribute to the MEI effort (by writing a full 
notation editor?)... Anyway, I have a belated comment or two on this 
issue. Please forgive me if I'm repeating what others said while I 
wasn't paying attention, or if I'm just off track and this is 
irrelevant!

My article "Written vs. Sounding Pitch", which is (or was!) in Workshop 
Resources has a lot of examples of the problems here. In general, the 
relationship between written and sounding pitch is so messy that even 
using the word "transposition" to describe it makes me nervous. With 
scordatura, you have to think of different transpositions being in 
effect at the same time, even within a chord, and you have to interpret 
the key signature very carefully (Fig. 6 of my article). Even timpani 
notation of the late 18th and early 19th century, with just two notes, 
is like that: consider the first movement of the Beethoven 4th, in 
B-flat major, where the timpani B-flat's and F's are on a staff with no 
key signature and no accidentals (Fig. 4).

I think Thomas is exactly right in that written pitch must be encoded 
for a lot of information about the appearance of the score to be 
meaningful. However, there are also many cases where you can't reliably 
infer the sounding pitch without giving the "transposition" on a 
note-by-note basis. But in that situation, why think about 
"transposition" at all? It makes more sense to just encode the sounding 
as well as the written pitch.

--Don


On Mon, 13 Feb 2012 12:08:55 +0100, TW <zupftom at googlemail.com> wrote:

> 2012/2/13 Johannes Kepper <kepper at edirom.de>:
>> Am 13.02.2012 um 04:03 schrieb Craig Sapp:
>>
>>
>>>
>>> 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?
>>
>
> From my perspective, written pitch is the way to go.  Transposing has
> a lot of impact on the appearance (stem direction, accidental
> arrangement, placement of beams/slurs, placement of articulation marks
> etc.).  MEI can provide information about all this, but is this
> sensible if sounding pitch rather than visual pitch is recorded?  I'm
> not sure whether it would be a good idea to transform all visual stuff
> to a separate layout tree.
>
> Thomas
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington