Scalar transposition and accidentals

Development
1

We want to add “scalar transposition” to a plugin. But we allow users to introduce accidentals into a selected Key/Scale setting. So, for example, the user selects C Major as the kay/scale setting, which enables all the white keys on the keyboard.

But suppose they need to introduce an accidental, such as C#. Normally, scalar transposition of two intervals in the key of C Major would transpose C to E and D to F. But what if they have added C# as an accidental (by enabling the C# black key on the keyboard). What should it transpose to, given that the purpose of using the scalar transpose is to keep the results in the key of C Major? Using normal (chromatic) transposition, that would be up four half-steps, to F. But D transposes to F already. What should C# transpose to in this case?

Or say they used the new scalar transpose to go up 1 interval (2 half-steps), so that C goes to D and D goes to E. What would C# transpose to? D#? D? E?

I’ve read some people saying that scalar transpose is simply not allowed if there are accidentals. I’ve read other places that use the staff notation, and simply apply the same accidental “direction” to the accidentals, after adjusting the notes up or down on the staff.

I know that we’re telling the user that this feature keeps the result “in scale”, but if a note didn’t start in scale, should the result also not be in scale? Or should it be mapped to a note that is in the key of C Major? Should accidentals always be preserved, or should the result be that all notes are in the original key of C Major?

In my first example, if preserving accidentals, that would make C# go to E#, which would happen to be the same pitch as F, while in the second example, it would make C# go to D#, even though D# is not in the key of C Major. Is this the proper approach?

I don’t have a strong music theory background, and haven’t been able to find a definitive answer to this question.

2

I don’t have a strong music theory either, so just my 2 cents.
I would consider C# as a C but with a sharp, so I would transpose C then apply a sharp on the transposition.

3

I do a lot of this in my project. This may not be exactly applicable to yours, but…

“Scalar” to me means keeping it in the scale of C Major.

The CMajor scale is:

C - D - E - F - G - A - B - C

Therefore, the idea is to constrain any transpositions to one of those notes. If a transposition does not fit on one of those notes, you must move it up or down (your choice) until it fits.

So in the first case (+4), C# becomes F. This is in the scale, so it’s allowed.

In the second case (+2), C# becomes D#, which is NOT in the scale, so then it must be constrained to either D or E.

I worked with KORG on their arranger series keyboards, and this is typical of how it’s handled.

2 Likes
4

That was my thought as well, @stephenk . We were thinking that to make the decision, which seems arbitrary, we’d move in the direction of the transpose, so if transposing up, we’d move accidentals up a half step, and it transposing down, we’d move it down a half step. Should work ok, but I really wondered if there is an actual rule in music theory related to this that we should follow.

5

Love this sort of question. To me it sounds like a great product/creative question.

Scalar transposition considers a “step” to be “the next valid note in the scale”. From a strict point of view, a diatonic CMajor scale with an added C# adds a step in the scale between C and D: the user has now chosen their scale to be 8 notes instead of 7. So by some literal logic, a 2-step scalar transposition of C would no longer be E, but go C to C# to land at D. But…this doesn’t sound like it would be be desired musically (in the majority of cases).

I guess the point of the new feature is probably to do something like “easily create nice harmonies in a diatonic scale”. So people would want to pick “2 intervals” (which are always a min/maj third in a diatonic scale) and it would be unexpected if C transposed to D (a major second).

So I agree with Stephen, constraining to diatonic is probably what’s expected most of the time! But doing so creates this problem of the dangling accidental.

We were thinking that to make the decision, which seems arbitrary, we’d move in the direction of the transpose, so if transposing up, we’d move accidentals up a half step, and it transposing down, we’d move it down a half step.

Another consideration might be that accidentals in diatonic scales mostly tend to occur as passing tones. They are almost always used as a way to create and resolve tension.

Let’s say I’m ascending C, C#, D. If my goal is to add another voice a third above, in my sequence I probably do not want the C# to transpose to F (which jumps the gun), but to hold onto E. That way, when I “land” on the D, the consonant D (original) and F (transposed) resolve the tension in one go. Likewise, when descending D, C#, C, I might want to “keep the tension” and so the C# should transpose to F so the C (original) and E (transposed) has a strong resolution.

This could be summed up as: “don’t move on passing accidentals”

To complicate things, half the time, the accidental can be transposed. For example, a C Major scale with an added b5 (Gb). In this case, going F, Gb, G with a “2 step” transposition, I would expect (in modern harmony, maybe not bach!) to be accompanied by a transposed A, Bb, B — it preserves the parallel line and sounds great.

Anyway! Sounds like a fun one! Excited to hear how it turns out.

1 Like
6

As Sudara pointed out, it really depends on what your plugin is doing, and the context of the user’s song.

1 Like
7

Does your plugin have any other kind of harmony settings, or internal sense of harmony tracking/structure? If there is an “active chord” then the most obvious choice is to constrain the transposition to the chord tones (even if one of the chord tones is out of the home key).

As far as “clamping to the key” or preserving the accidental, I think that could possibly be a setting. That really comes down to a creative/UX decision: would you rather give the user more detailed control, or fewer options?

8

I think what will work best is to introduce some kind of probability. If one of the two options is a note of the tonic or dominant, it should fall there.

A more advanced system would take into account, which chord was last played and prefer the notes of that one.

All under the premise that the player needs that kind of support, as it is limiting the creativity.

9

A musical solution, from a melodic perspective.
Use “leading” note: the accidental has a fixed relation to the note after it. So that keeps the character of the accidental to the follow up tone the same.
e.g. If in C major you go up 2 scalar degrees, a C# is the leading note to D if a D follows.
The D then becomes F, and therefore the leading note C# becomes E
But If the leading note is downward C#->C
The transposed C => E, the C# => F

If mulitple accidental occur, the cluster is resolved to the first non-accidental

10

The problem we have with any musical analysis is that the only information we have in this case is the setting of the Key and Scale (e.g., A Minor), and any user modifications to that via the keyboard (adding or removing notes from the scale), and the current note being played. We don’t know anything about the notes that may or may not be played at any given time before or after this one, and it’s used only on a mono voice, not a chord. So it really just boils down to: for a given key/scale, and a given note, and a given interval to transpose, what do we do with accidentals? Doesn’t look like there is a simple answer.