The sharp/flat buttons on the transpose dialog seem to switch only the enharmonic equivalent of the destination key. I would expect that it also affects how chords are displayed within the song.
There's a really ugly work-around: if I set a wrong starting key in a way that the (also wrong) destination key has an enharmonic equivalent, then I can tweak that the song is displayed as I want it.
See attached example. If I transpose "What A Wonderful World" (with chords in F within the file) I would like the Db in the 5th measure of the A section to be transposed to Ab, not G#.
If no transposing is set (starting key = destination key) the chords should be displayed unchanged, as written in the file, to allow the rare case of mixed sharps and flats in one song
I'm not sure if that worked as expected before the implementation of the chord localization feature.
I tested with MSP 2.7.3 on Android.
That recalls a discussion we had long ago: imho it is absolutely not necessary to set the starting key manually. The starting key is already specified within the ChordPro file: the setting "Detect Key By" combined with the chords in the file specify the key clearly. If the file contains {key: C} or {meta: key C} that overwrites the result of "Detect Key By".
Why do we need that additional, error-prone and confusing user action?
I define C as a key containing only sharps, and I define F as a key containing only flats. That's just how I implemented the transposing. There is no override for chosing sharp or flat when using the dialog - it's based on the transposed key. If it's confusing having the sharp/flat buttons enabled when a key is selected that has no accidentals, then I will disable them. Those buttons are not meant to override how chords are transposed, and whether sharp or flat chords are chosen when transposing. They just toggle between enharmonic equivalents. If you disagree and think those buttons should provide a way to override the way in which every chord is transposed, that would require changes to all the text file processing and database changes to store the new field to capture that selection. As a side note, if you use the transpose keyword in the chord pro file itself, transposing up (a positive value) will choose sharps whereas transposing down (a negative value) will chose flats.
As for why we have the dialog, it's because the {key:} and {meta} values are not read out of the file every time - only when the song is first created. I could certainly change this to either use what is specified in the file or fall back on the "Detect Key By" setting and recalculate the key every time the file is loaded if you would prefer. This obviously requires extra processing, but it shouldn't slow down the loading a noticeable amount. I still think I should list on that dialog what the starting key is so that users can understand how many steps their chords are being transposed.
"... Those buttons are not meant to override how chords are transposed, and whether sharp or flat chords are chosen when transposing. They just toggle between enharmonic equivalents. If you disagree and think those buttons should provide a way to override the way in which every chord is transposed ..."
Yes, I disagree. The rule "C as a key containing only sharps, and F as a key containing only flats" applies to notes in standard notation, not to chords.
My example "What A Wonderful World" demonstrates that flat keys in C Major definitely make sense. At least I need a possibility to choose if flats or sharps are used. In my case, regarding "What A Wonderful World" I found a workaround. I need it in C and in F. My example was originally in F, the issue came up when I transposed it to C. Now I do it the other way round: the base file in C with the Ab explicitly written in the file. The F version uses the same file, transposed to F. The Ab chord is correctly transposed to Db - fine so far. The issue will be back as soon as somebody asks for playing it in G - the Ab will be transposed to D# but I would expect it to be an Eb.
That the transpose keyword in the chord pro file differentiates between sharps for transposing up (a positive value) and flats for transposing down (a negative value) is another argument that it makes sense to allow this choice.
And another example song: "Dream A Little Dream Of Me" changes the key for the B section. The Mamas & Papas version changes from G to E - that would fit in your "only sharps for G" rule. But the equally wonderful version by Louis Armstrong and Ella Fitzgerald that can be found in many fakebooks changes from G to Eb. If the chords would be written with their enharmonic sharps equivalent it would be very hard to read.
If I would use the ChordPro transpose keyword I would lose the possibilty to use one base ChordPro file for the same song in different keys. And transposing "on the fly" during a session would require editing the file, making it much less convenient.
Regarding the "set starting key" dialog (which is a completely independent topic):
Extra processing to specify the key is not required on every opening of the file. It is enough to do it every time the file has been changed. I think MSP already detects file changes or am I mislead?
A button "(re-)detect starting key" would be also possible. Not very elegant, but it would make sure that the starting key really matches the contents of the file without having to open it in the editor and think about it's starting key.
I've modified MobileSheetsPro so that the starting key is shown below the arrows for transposing but it's not something you can interact with (it's just listed for reference). The key is automatically calculated using either the chord pro directive if it's specified or the approach determined by the "Detect Key By" setting. The processing is fast enough that I just calculate it each time (trying to track file changes all the way down in the chord pro processing would actually be more difficult/problematic). The most important change is now that MobileSheetsPro will respect whatever selection you've made for sharp or flat. It will no longer try to calculate what is best based upon the key shown. So you can decide if all chords should be transposed to their flat or sharp equivalents. Hopefully this will work better for you and give you the control you need.
V2.8.2: Detecting the starting key and applying it on "Reset" works fine now. Applying the sharp / flat buttons to all chords also works fine. Thank you Mike.
There's one thing left: If the song is not transposed, e.g. after tapping "Reset" I'd expect that the song is shown as written in the file. Currently the sharp / flat buttons on the transpose dialog are also applied.
For some songs (like the attached example) it is useful to be able to have sharps and flats in the same song. Those cases require a manually transposed separate song file for every key or accepting the limitations of the transpose feature. But it should be possible.
Sorry, if my request was not clear enough in this detail.
I've modified the logic so that the original chords will be used if sharp/flat has not been selected and the number of steps being transposed is 0. I've tested with your file and it now shows both flats and sharps when nothing is set.
Great. Your fix in 2.8.3 is even better than requested.
I did not exoect that both the reset AND the sharp / flat buttons can be applied. It's excellent how it works now.
Thank you.
