[DTownSMR]

The logic that performs the transpose on a chordPro sheet doesn't follow conventional names when choosing the chord name based on the new key.

For example: key of A with the chords A - E7sus - F#m - D to the key of B I get the chords: B - Gb7sus - G#m - E .

And a related note, probably means being able to select the correct key via slider (eg. both F# & Gb separately) and not a combination selection (eg. F#/Gb) that leaves the key ambiguous.

[sciurius]

For many years I have used (and implemented in numerous tools) the convention: transpose up produces sharps, down produces flats.

So a transposition of +2 of A - E7sus - F#m - D will produce B - F#7sus - G#m - E, while a transposition -10 will produce B - Gb7sus - Abm - E.

This is consistent, easy to implement, and easy to understand/explain.

[DTownSMR]

For many years I have used (and implemented in numerous tools) the convention: transpose up produces sharps, down produces flats.

So a transposition of +2 of A - E7sus - F#m - D will produce B - F#7sus - G#m - E, while a transposition -10 will produce B - Gb7sus - Abm - E.

This is consistent, easy to implement, and easy to understand/explain.

Programatically I get what you're saying but I'm not sure I get WHY? i.e. what is the use case for supporting Gb7sus & Abm in the key of B?!? The "issue" as I see it is that I've selected a new KEY and simply expect the correct chord names to be used. I don't want to have to think, or even know, which is "right". (my two years of theory are long past and I've forgotten most of it anyway! lol)  In other words, If we're all used to seeing chords in the key of X with certain accidentals then why not have the program know that...that's the usefulness of software. :-)

Perhaps the notion of "up for sharp & down for flat" makes sense in picking between the key of F# & Gb but even then I'm not sure that would make the best UI experience. I would have to mock some prototypes up say with any confidence.

[sciurius]

Interesting...

I think most of it stems from the practice of transposing by interval instead of key. When you say "I have a song in A, and I transpose it to B" the process is, indeed, deterministic. However, when you have a bunch of chords and want to transpose up 2 intervals, the case is different.

I'm one of those stupids that transpose by intervals. I also play Bb instead of A# and C# instead of Db...

[akoster]

Interesting...

I think most of it stems from the practice of transposing by interval instead of key. When you say "I have a song in A, and I transpose it to B" the process is, indeed, deterministic. However, when you have a bunch of chords and want to transpose up 2 intervals, the case is different.

I'm one of those stupids that transpose by intervals. I also play Bb instead of A# and C# instead of Db...

While I can see how you're thinking as far as transposing by interval, I have to side with DTown on this. When I transpose, it's from Key X to Key Y, and I expect the correct chords that fit for Key Y.

[Zubersoft]

I can split out the options to make it easier to specify the exact key. That may even simplify some of the logic I'm currently using.

[itsme]

The F#m in the given example is the VIm in the key of A and the VI in A (the sixth tone of the A major scale) is F#, not Gb. That's probably what DTownSMR means with "correct"

[itsme]

fixed in 1.2.6
see http://zubersoft.com/mobilesheets/forum/...1#pid13111

[sciurius]

I have a song in key C, with chords Am F E.
When transposed up 5 semitones, the key becomes F, and I would expect the chords Dm Bes A. However, I get Dm A# A.
Did I misunderstand the new transposition method?

[Zubersoft]

Perhaps someone more knowledgable about transposing chords can chime in here. With a key of C, I just assume all chords are represented as sharps (though the C key signature is neither sharp nor flat) as I had to pick sharp or flat with my current logic. If I need to conditionally transpose each chord of a song when that song is in the key of C, then I'm definitely not handling that correctly.

[itsme]

Whatever logic is applied, it has to be applied to the destination key which is Dm / F in Sciurius' example. I agree with Sciurius that Bb is correct and expected not A#.
The key of the example seems to be Am, not C (major), as E7 is the V7 of Am.
Anyway, transposing from C to F instead of from Am to Dm should also create Bb.
@Sciurius: Is it correct if you check the "Minor" checkbox and set "Key:" to A(m)?
This is what I reported 11-25-2015 as still wrong in 1.2.6 (see link above) and is fixed now.

[Zubersoft]

Now that I think about it, if you transposed to F, it should be choosing Bb based upon my code. Are you using the transpose by key setting or transpose by steps? I just created a song with your exact chords, set the key of the song to C, transposed from C to F, and it worked as you would expect. Dm, F and Bb were used. I also tried it when transposing by steps, and that also worked. What key did you choose for the song?

If you are using a minor chord for the key of the song, there are still bugs present with transposing with minor chords that won't be fixed until the next update is released.

[sciurius]

I think we have some misunderstanding here.
In the case I mentioned, the target key is F, which has one flat (for Bes). So I'd expect source F to become a Bes in the new key, not A#.

[Zubersoft]

Yes, I agree. I transposed the song, which was set with a key of C in the text display settings to a key of F. Chords in the song listed as F were transposed to Bb. I'm not sure why you are seeing A#...

[sciurius]

If MSPro thinks the song is in Am (which is enharmonic with C), it will produce the A#. So if you have a song in C that happens to start with Am, MSPro will assume it's in Am and surprise you.

Actually, I'm afraid the whole key support of MSPro may need rethinking.

First, what does it actually mean?
In the song edit (properties) form, a song can be assigned multiple keys. What does that mean? I don't know.
A chordpro file can have multiple occurrences of {key: XX}. This can be unambiguously interpreted as: the given key applies from here, e.g. a song with a modulation.
When a song is imported, only the last occurrence of {key: XX} is registered in the song properties. When I explicitly specify a key during import, the (last) {key: XX} is added.
In the Text Display Settings, only one key (the last or only {key}) is taken into account. I assume it will use the key specified during import if no {key}s are present in the file. In most cases, the key as displayed here is ambiguous and serves no purpose (read on).

As it comes to transposition the situation becomes even more complex.
I think we can agree that transposition applies to the whole song. So there's only one transposition.
When thinking in terms of semitones it is relatively easy: all chords are transposed the desired number of semitones. However, this leads to ambiguous situations: Should A+1 become A# or Bes?
It is also possible to define a transposition in terms of a source key and a target key. This solves some abiguities (e.g., when transposed to the key of F an A+1 becomes Bes, not A#) but not all of them. As Mike already noticed, when transposing to the key of C, should A+1 become A# or Bes?
Also, when a song has multiple keys, transposing by key becomes confusing.

Are there any better alternatives? I think so, but that would require an overhaul of the current handling of keys and transpositions.

First, the key property of a song becomes for administrative purposes only. It is the collection of keys specified during import plus all {key:XX} that are in the file (if selected in the config). It can be used for sorting and grouping.

In the Text Display Settings, remove the Key part, *or* change it to "Original key(s): " for display purposes only.

Instead of the Transpose slider and its setting in the config, make a button [TRANSPOSE]. This will call a dialog where the user can choose between steps transposition (+/- 11 semitones) and key transposition.
For steps transposition, use sharps when transposing up, and flats when transposing down. This is a well-established convention.
For key transposition, the user must choose a starting key and a target key (no defaults, no minors!). This can then be interpreted as steps transposition. If the target key has sharps, use upward steps. Otherwise, use downward steps. If the target key is C, we still have a problem, though.

I think this may clean up most of the current key/transposition issues.