[sciurius]

Hi Mike,

Thanks for the explanations. It makes much clear.

I think most of the problems/confusions are caused by functionality that has been added incrementally and finally got out of balance.

Summary: Forget about key transposition and use step transposition only.
Executive summary: Do not spend too much time on this, there are other, more important issues.

It does make sense for a song to have multiple keys if it changes keys partway through the song and you want to track that.

Yes.

If keys are assigned in the chord pro file, only one is used I believe, and it's only used during import for initially setting the text display settings key. If the "Use Text Fields During Song Creation" is set in the text file settings, then the key will be added to the song as well.  The two are really separate though, and I think they should be.

During import only the last occurrence of {key} is added. Wouldn't it be better to add all?

It's important to note that the chord pro key directive overrides any of my logic for trying to determine the actual key of the song. If no key is specified, then MobileSheetsPro will look at which option is specified for the "Detect Key By" setting in the text file settings. By default, "First Chord" is used which means it will assume the whole song is in the key of the first chord. You can also specify Last Chord or Chord progression. Chord progression is the most sophisticated and will actually look at all of the chords used in the song to try and determine its key. This is correct most of the time, but if the song changes keys or has a lot of odd progressions, the key may be detected incorrectly.

Bottom line is, and here the problems start, that the song is finally assigned one single key, while in reality it can have multiple keys.

My current approach to transposing is already based upon choosing a source key and a target key. This is critical for ensuring the correct chords are chosen.

Correct, but this fails when the song has multiple keys. Transposition by key will use the first key as source, and hence may generate incorrect chords for parts that have different keys.

IMHO when you allow multiple keys, you can no longer perform transpositions simply based on key. For example, if a song has keys C and A, and you transpose C -> F, then the C-parts will become F and get flats while the A part will become E and want sharps.

I'm going to have to do more testing with your example by putting Am first instead of C and seeing if I can reproduce the change to A#.  If the destination key is F, I still don't see how a sharp chord was chosen though, as my logic is currently set to choose flat chords for F.

Hmm. Maybe it is because in the example I perform a stepwise transposition of +5, not a C -> F transposition?

I think choosing a source key and then the key to transpose to (which is how it's currently implemented) should be sufficient.

As I tried to point out, performing keywise transposition on a piece that has multiple keys is ill-defined. The only safe way to perform a transposition is stepwise. Most tools that I know do stepwise (pitch-wise) transposition. See e.g. lilypond, denemo, audacity. Musescore has key transposition which is just pitch transposition under the hood.

So my suggestion would be: forget about key transposition and use step transposition only.