12-15-2015, 12:07 PM
Johan,
I think the way I'm handling the key field for songs may be causing confusion with its relation to the key used for the chord pro file. 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. 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.
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.
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. 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. Having said that, I'm starting to wonder if the bug that I fixed with minor chords may be playing a part in this. I will have to test the 1.3.0 release instead of my development build.
Your suggestion for adding a transpose button with a separate dialog doesn't actually change things very much. It does provide an easier way to switch between the transposing by steps versus keys, but at the cost of requiring more taps to accomplish a transpose. I think choosing a source key and then the key to transpose to (which is how it's currently implemented) should be sufficient.
Thanks,
Mike
I think the way I'm handling the key field for songs may be causing confusion with its relation to the key used for the chord pro file. 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. 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.
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.
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. 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. Having said that, I'm starting to wonder if the bug that I fixed with minor chords may be playing a part in this. I will have to test the 1.3.0 release instead of my development build.
Your suggestion for adding a transpose button with a separate dialog doesn't actually change things very much. It does provide an easier way to switch between the transposing by steps versus keys, but at the cost of requiring more taps to accomplish a transpose. I think choosing a source key and then the key to transpose to (which is how it's currently implemented) should be sufficient.
Thanks,
Mike