As you can see in the screenshot below, the right melody staff is offset by one note, so that F aligns with E, G aligns with F#, A aligns with G# etc. I’ve seen this happen quite a few times, but other times it works just fine and I’m not sure why.
Here’s the TheoryTab that I took the screenshot from:
At first I thought maybe the code works by aligning the tonic of the new key with the same note in the previous key, “rounding up” if necessary (so in this case, we look for C#, don’t see it, so align C# with D). But experimenting a little, it seems to be more complicated.
Here’s what C# minor looks like in a project whose key is C major:
But wait, there’s more! Let’s set the project key to F major, then go F major → C major → C# minor:
I can’t make heads or tails of this. It doesn’t seem to work off the tonic of the latest key, or the tonic of the previous key, or even the tonic of the project key (why is the F of F major the E of C# minor but the F# of C# harmonic minor?).
It feels like there’s a conflict between avoiding issues like this (“local”) and maintaining some consistency across an entire project (“global”). If local changes are prioritized too heavily, maybe after a bunch of key changes you could end up with a melody staff that’s entirely different from the one you started with. Doing both well might be difficult, and doing both perfectly might be impossible. It does feel like it could be handled a little more carefully than it is, though.
Also, it doesn’t seem to be totally symmetric. In other words, if you transpose the entire project, you might get different results, so the note names themselves somehow matter.
Here, we start in C major and modulate up a half step every bar:
And here’s the exact same thing, except the project key is A major:
Notice how in the first example, the line that starts on C goes down to B. In the second example, the line that starts on A goes all the way up to B and never goes down to Ab.
There’s also inconsistency in how many lines the staff has: G major lost a line and E major didn’t, and in the F major → C major → C# harmonic minor example, we actually gained a line.
With the C Major to C# Harmonic Minor example, at least there’s a logical explanation for the offset, as the two keys share an enharmonic equivalent (C and B#). Though I don’t think this is the right thing to do when there’s just one enharmonic equivalent, but multiple shared notes (in this case A and E). I think this should only happen when the number of enharmonic equivalents surpasses the number of shared notes, like in Db Major to F# Major:
I also think shared notes should be prioritized over enharmonic equivalents when there’s an equal amount of both, like in C Major to F# Major, which shouldn’t be offset in my opinion:
Interestingly enough, there’s also the reverse case, where the right note staff should be offset, but isn’t, like in F# Major to D Minor, which has two enharmonic equivalents, but no shared notes:
The local vs global issue seems to be a factor for projects with multiple keychanges, but I can’t think of any good reason why this behaviour might be intended in a project with just a single keychange and no enharmonic equivalents between the two keys, which is why I’m assuming it’s just a bug.
Thank you all for taking the time to document this behavior, there might be a few different rules that might make sense most of the time, but perhaps not every time.
My first guess would be this:
I’ll add it to our bug list, but I think this is something rather low priority as it doesn’t break anything. Regards!
Dennis
