Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change allowed values for transposition #975

Merged

Conversation

rettinghaus
Copy link
Member

This PR changes the allowed values for transposition information from decimal values to integer values.

fixes #972

@github-actions github-actions bot added the Component: Core Schema changes to source/modules/* (assigned automatically) label Jun 14, 2022
@rettinghaus rettinghaus added this to 2022-07-29 ODD Friday in ODD Meetings Jul 29, 2022
musicEnfanthen
musicEnfanthen previously approved these changes Jul 29, 2022
Copy link
Member

@musicEnfanthen musicEnfanthen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks plausible to me. Exisiting attribute descriptions only use integer values, and a transposition by diatone or semitone via 0,5 (or other decimal values) does not seem to be appropriate. If other transposition steps would be needed in the future (quarter-tone, microtonal, etc.), additional attributes could be used.

@musicEnfanthen musicEnfanthen moved this from 2022-07-29 ODD Friday to 2022-09-30: ODD Friday in ODD Meetings Jul 29, 2022
@musicEnfanthen
Copy link
Member

@ahankinson Would you have time to have a look at this PR until this Thursday (next ODD meeting, September 23)?

@ahankinson
Copy link
Member

What is the consensus on whether we want to support quarter-tone transposition? Wouldn’t that necessitate trans.semi=0.5?

I know this isn’t common in Western repertoires, but based on my limited conversations with people working in Eastern repertoires, non-whole semitones are common, at least as accidentals.

Anyone with more experience out there?

@rettinghaus
Copy link
Member Author

The question is where you want to go with this. I'm not aware of instruments that transpose beyond the western chromatic spectrum. But let's assume there are: what about Turkish makam, where the octave is divided into 53 equal intervals. But what information would you gain from a trans.semi="0.452830188769245"? Shouldn't this be trans.semi="0.452830188679245"?

The need for setting this clearly comes from a CMN perspective (where you always have 'whole' semitones for transpositions). If there is the real need for something beyond this, we should think of additional trans.* attributes that can handle values that are more precise.

@ahankinson
Copy link
Member

ahankinson commented Sep 22, 2022

I think it can also be a challenge in certain (specialized) Western music. The Schola Cantorum in Basel has a project on the Vincentino archicembalo and archiorgano. See: https://www.projektstudio31.com/blog/spielen-auf-der-fokker-orgel. This uses notation that does not conform to a common understanding of "semitones".

I think the issue lies with whether you think of a semitone as being a fixed number of units per octave. I don't know that we have the ability to express how many semitones-per-octave, so the only way to do non-12-tone semitones is to use decimal numbers. So what is probably missing, but would be needed to make trans.semi a whole number, is the number of semitones per octave.

@trans.semiPerOctave=53 (bad name, but you get my drift) would mean we could then use @trans.semi=1 for the octave of 53 intervals. Thus the width of each semitone would be 1/53 instead of 1/12.

In combination with @tune.temper you could then derive the actual "width" of individual semitones if you needed to.

I think we have to keep in mind that the description of trans.semi is that it is there because it is "necessary to calculate the sounded pitch from the written one."

So at some point, some actual math would be expected so that we can calculate just what frequency the sounded pitch is. We can either do that with decimals to map the idea of an equal "semitone" (100 cents) onto non-12-tone scales, or we need to provide the number of semitones per octave so that we can derive the appropriate ratio.

@bwbohl
Copy link
Member

bwbohl commented Sep 22, 2022

@ahankinson that's a very interesting organ project you're pointing to! Nevertheless, the organ is not a transposing instrument although it has a differentiation between enharmonic equivalents, meaning E-flat is not the same sounding pitch as D-sharp. But the intention behind the trans.semi and trans.diat – @pe-ro please correct me – is not to calculate the sounding Hz but the name of the sounding diatonic pitch.
Perhaps, @ahankinson, you could start a discussion to collect sample music that needs different values? An yes, if it'S a feasible solution to have an attribute to define the number scale steps but also I think this might better be in the context of tuning or scale definitions at some other place in MEI.

In short: I'm pro integer and pro collecting repertoire that might have instruments with other steps between notated and sounding pitches ;-)

@ahankinson
Copy link
Member

ahankinson commented Sep 22, 2022

Most instruments can be transposing instruments, if you can change their tuning fundamental. I know of trombone players who play in 440, but think in 466, so when they see a note, they play a note half a step lower.

There is a note in the wikipedia article about the use of transposing keyboard instruments to reconcile pitch standards: https://en.wikipedia.org/wiki/Transposing_instrument#Reconciling_pitch_standards

We currently have a clavichord in our house where you can shift the keyboard over to adapt it to different concert fundamentals without re-tuning the strings. In this way the player can play a C key, but have a Bb sounded, when compared to another instrument at a different fundamental. I know this setup is common in places where the Grand Orgue is tuned to one fundamental, but the ensemble wants to play with it in another.

Electronic instruments can do whatever they like. I wouldn't make any assumptions about their behaviour, because someone will immediately break your assumptions just because they can.

I'm not saying it's common -- I'm also pro-integer, but I want to make sure we're not simply tying our understanding of transposition, and transposing instruments, to an assumption of 12-pitches-to-the-octave, fixed concert pitch.

I think where I'm most hung up is the definition of a "semitone" -- I get trans.diat but not trans.semi. A semitone could be "C" to "C#", but could it be "C" to "Cb#", if the next chromatic step on the instrument is halfway between a C and a C#? Again, appealing to wikipedia, it says the semitone is defined as "the interval between two adjacent notes in a 12-tone scale." With that definition, it seems that we're stuck assuming that there can be only 12 semitones to the octave on any given instrument?

If the instrument doesn't use the 12-tone octave, and we remove our assumptions about what is, and what isn't, a transposing instrument, what does @trans.semi=1 mean? Perhaps it should be trans.chromatic which would then be simply "the next pitch in whatever scale you're using"?

That would mean that @trans.chromatic=1 @trans.diat=0 @trans.semiPerOctave=24 could accurately describe an instrument that played a quarter tone higher than written (C -> Cb#), and would contain only whole numbers. (I may be getting my numbers wrong, it's the end of the day... but hopefully you get my drift). Otherwise, we actually cannot describe transposing instruments without building in the assumption that there are 12 semitones to the octave.

That's fundamentally why I'm wondering about the change to @trans.semi. If we leave it as a decimal, then we can sorta hack this, if we need to, and bumble along. If we change it to an integer, then we lose that capacity. If we add the number of semitones per octave then we bring back this capability.

I think the most elegant solution is to add the attribute describing the number of semitones per octave. It doesn't change an existing attribute, and fills in a small hole in lost functionality that we currently do have (even if it's not actively used).

@ahankinson
Copy link
Member

Or maybe a different way of looking at it: how would you define a clarinet in Bb in a piece that uses 53 notes to the octave?

@pe-ro
Copy link
Contributor

pe-ro commented Sep 23, 2022

I don't think there's a standard way in traditional notation of dealing with transposition / transposing instruments in music using non-traditional divisions of the octave. When Western notation is used in these cases, the notation is written "at pitch" (where the written pitches are general approximations) and directions are provided per note, per part, per score, etc. for producing the desired outcome. So, as @rettinghaus said before, transposition outside of Western traditions isn't a thing.

In the distant past; that is, in 1999, when we all rode around on dinosaurs, trans.diat and trans.semi used only integers. I don't remember why decimal values were introduced. It was probably at the urging of @craigsapp. 😉 Given the discussion here, decimal values seem to cause more confusion than they resolve, so I'd recommend returning to integers.

Yes, @bwbohl , you're correct -- A precise sounding frequency, say A439.01237892, isn't the goal of trans.diat and trans.semi. They are intended to indicate how to get from the current written pitch to a nominal (written/sounding) pitch in a different key. Obviously, "key" is a Western notation concept that may or may not apply in atonal music, and doesn't apply at all in quarter-tone and other non-Western tuning systems.

@ahankinson
Copy link
Member

OK; we can leave it as-is. Since it will have three approvals, I'll merge.

@ahankinson ahankinson merged commit 650951e into music-encoding:develop Sep 23, 2022
@rettinghaus rettinghaus deleted the develop-transposition branch September 23, 2022 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Core Schema changes to source/modules/* (assigned automatically)
Projects
No open projects
ODD Meetings
  
2022-09-23: ODD Friday
Development

Successfully merging this pull request may close these issues.

Allowed values in att.transposition
5 participants