[sciurius]

Usually a feature request is about adding new stuff. This is a request for simplification and removing stuff.

A song can have one or more keys associated. Usually there is just one, but occasionally parts of a song can be in a different key. For example, when a part of the song is modulated. Keys are great for reference and catalogues.

ChordPro songs can have one or more {key} directives, but upon import only the key from the first {key} directive is stored in the Keys metadata. This may be considered a (low priority) bug.

When it comes to transposing, there are two forms: by key and by interval. For example, a song in the key of C can be transposed to the key of D, which would change all occurrences of e.g. a G chord into an A chord. Likewise, a song can be transposed up two chromatic intervals, which would change all occurrences of e.g. the G chord into an A chord.

So, at first sight, both transpositions are the same. But complications quickly arise when a song has multiple keys, and when accidentals come into play.

When a song has a single key, say C, and we transpose it to D, it is clear that all chords will be transposed up two chromatic intervals. Or ten intervals down. But if there is a second key involved, say D, what does "transposition to D" mean for that part of the song? No transposition since it is already in the key of D? Or transposition to E, since that is two chromatic intervals up?

And what will happen with e.g. an E chord? Will it become a F# or Gb chord? A widely accepted convention dictates that the accidentals must fit the transposed key. Since the key of D has sharps, the result of transposing the E chord will be F#. But if the song had a part in the key of E, would that also become F#? Why?

The point I try to make clear is that transposition by key is cumbersome and ambiguous. Transposition by intervals doesn't have these problems. There is, however, a catch. It is no longer determined whether an E chord will become F# or Gb. One convention is to use sharps when transposing up, and flats when transposing down. Transposing up 5 intervals is enharmonically identical to transposing 7 intervals down.

My proposal is to elimintate the "transpose by key" functionality and use "transpose by interval" instead. This also plays nice with the use of a capo.

[itsme]

@Sciurius: thank you for bringing this up again. I agree that some improvements of the transpose feature would be helpful.

I do not see the issue with multiple keys. I always thought of transposing by counting semitones up or down for all chords in a song. With the number of semitones detected from (a single) starting key and destination key.
I find both transposing "by key" and "by semitone" useful.
The decision if sharps or flats are used is definitely an open issue.

[itsme]

My proposals for improvements
1.) allow switching between "by key" and "by semitone"
This can easily be achieved by changing the labels on the existing "Transpose" window: replacing C ... B with 0 ... 11 and labelling the buttons "b" with "-" and "#" with "+" would fulfill Sciurius' request.
Alternative: a slider -11 ... 0 ... +11, no buttons "b" and "#"
Close to transposing would be better than in the general settings, e.g. a button in the "Transpose" window or two items to select either "by key" or "by semitone"

2.) decision if sharps or flats are used
A decision by MSP is only required if transposing is activated. I think it is wrong that MSP in the key of C displays always e.g. D# when Eb is found in a song file. With no transpose it should show what is found in the file. 
When transposing is activated, it is required to decide if sharps or flats are used. MSP (and probably all other ChordPro readers) can only decide this per song, not per individual chord. Currently the destination key specifies the usage of sharps or flats in MSP. That is ok in many cases, but not for all. I agree with Sciurius that it would be far better and easier to read if I could specify my preference for flats or sharps per song. That happens more often for destination key C, but is also useful for other keys. Note: we are talking about the chords, not about single notes.

3.) detect the starting key
To know the starting key is mainly required for transposing "by key".
The UI to specify the starting key is unnecessary and confusing. That should be removed. The starting key should be detected only by the content of the file. We have "Detect Key By" in "Text File Settings" to start with. If the file contains a "key:" tag that shall overwrite the result of "Detect Key By". That's fully sufficient.

[Zubersoft]

1) I'll have to think through the ramifications of the changes, along with what information I will need to store, and how to propogate that information through my current architecture.

2) I'll see if can change the logic so that if the detected number of steps for the transpose is 0, it won't change any of the chords. I thought I was already doing this, but if it's changing the chords when C is the starting key and C is the transposed key, then there is obviously a problem.

3) And what do you do if the detected starting key is not what you want? I don't re-read that "key" tag in the file every time I open it. If the suggestion is that I start doing this, then sure, that solves the case for when the key directive is available, but what about in the cases where it is not? Also, what do I do with text files? Many people are still using those instead of chord pro files. If I don't provide a way to change the starting key, that means that I have to change my logic to recalculate the starting key every time the file is read. This is not a huge deal, but it does mean that if someone changes the text file settings for how to detect the starting key, all of their files could suddenly be transposed differently the next time they open them. It also means that if you have one file whose starting key doesn't play nicely with the method you have selected for "Detect Key By", you have no control over how to change it. With chord pro files, you could then add the key preprocessor directive, but with text files, your only option would be to modify the file itself. That may also not even work if the key detection method is set to "Chord Progression", as it will consider every chord in the file. Of course, all of this doesn't apply if the transposing is done with intervals instead of keys. So one option would be to default to transposing by intervals, but when transposing by key, it's up to the user to ensure that the starting key will be detected properly. I could also add supporting for looking for a "key:" field in text files so that even text file users would have a way of controlling the starting key if required.

Mike

[itsme]

Find attached the sample that made me report 2.): DerHuberUndSeiLena.pro
The song is in the key of C with a B section that modulates to F.

If I specify the starting key correctly as C and set transposing to C (0 semitones) it shows as Huber_Err.png with a confusing A# chord.
If I specify the starting key as F and set transposing to F (also 0 semitones) it shows as Huber_OK.png with the Bb chord that I want to see there.

Great that I found a workaround now, but not as it should be.

Edit: if I import the song for the first time, it looks correct. The issue is shown as soon as I transpose somewhere and remove the transposing later. No matter if I use the up/down arrows or the "Reset" button.

[itsme]

to 2.)
When the issue with "no transpose" as reported above  is fixed it is probably possible to find workarounds with writing a certain key in the file and transpose so that relevant keys are displayed as desired. But it would be far more convenient to allow specifying the usage of sharps or flats per song. Sciurius' proposal for using up/down as criteria is one possibility to specify that, but there are certainly other, maybe better, possibilities to specify that.
I think itis not only relevant when the destination key is C.

[itsme]

to 3.)
The starting key that is set by the current key is stored per song in the database, correct? Why not keeping that database field as it is, just fill it when the file is imported (or re-imported after a change of the file)?
If "Detect Key By" does not detect what I want I add a "{key:" directive to my ChordPro file. It is not required to read the key directive every time when the file is opened. It is sufficient to read it, when the file has been changed. I think this is already the case.
The "Detect Key By" setting is in my opinion a decision that is not changed frequently. If it is meant to be used just for the very first import of text and ChordPro files, it should better be placed in the "Import Settings" dialog than in the general settings.
I do not use "Detect Key By: Chord Progression". It is not transparent for me how it works and could be affected by any chord change within a file.
If detecting the starting key of a text file detects something unexpected, the user can use "transpose by semitone", supposed it is available.