MobileSheets Forums

Full Version: [almost fixed in 1.4.3]Text Editor - transpose does not work as expected
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I have a chordpro file containing chords in C. It is transposed via transpose function to A, 3 semitones down.
When I open it in the new Text Editor, it shows chords in C as written in the file - OK so far.
When I tap "Transpose" in Text Editor, the transpose window shows "F#" (3 semitones down from A), I would expect it to be intialized with "A" like in the original, three semitones down from the displayed "C" chords.
I close the transpose window with "Cancel" and the editor window shows chords in A instead of discarding everything and keeping the "C" chords.
"Transpose" again, the transpose window shows "D#", another three semitones down.
What's going on here?
(03-24-2016, 08:26 AM)itsme Wrote: [ -> ]I have a chordpro file containing chords in C. It is transposed via transpose function to A, 3 semitones down.
When I open it in the new Text Editor, it shows chords in C as written in the file - OK so far.
When I tap "Transpose" in Text Editor, the transpose window shows "F#" (3 semitones down from A), I would expect it to be intialized with "A" like in the original, three semitones down from the displayed "C" chords.

Actually, I would expect to see "C", since the text file being edited is, still, in the key of "C".
The text editor edits the ChordPro text document, so it should use the key the document is in.
That it is displayed in some song window in the key of "A" is not relevant. The same file could easily be related to another song and displayed in yet another key.
Upon save, I'd expect MSPro to perform the equivalent to a "Swap file".
For clarification: I see the C chords in the TextEditor as expected
What's wrong in my opinion is
1.) the initial destination key in the transpose window
When I tap "Transpose" I would expect it either to take over the "3 semitones down" from the original file (starting at the displayed C so that it shows A) or C for "no transposition"
2.) that "Cancel" in the transpose window changes the text
I'll have to take a look at why cancel would modify the text. As for #1, it's because I'm dynamically determining the key using the chord progression as it simplified things, especially when dealing with a new text file that hasn't been assigned a starting key (you can create a new song in the song editor, tap the edit file button in the image preview area and generate a new text file). I'll have to fix the logic to always prefer the starting key from the song if one is available, and track what the current delta is from that starting key (so I can avoid having to determine the key).

Mike
Thank you for fixing this.
"Cancel" now works as expected. The initial key is taken over correctlly.
One issue is still left: when the transposed chords are written into the ChordPro file, the original key should be changed accordingly.
In my previous example:
- open file with chords in C, original key set to C, transposed to A (3 semitones down)
- open MSP text editor, open "Transpose"
- the transpose window shows C as initial key value (correct)
- transpose e.g. to D, 2 semitones up from C, save changes
- the song is displayed in B (3 semitones down from D), correct
- open "Transpose" again
- the song is displayed with keys in D, but the transpose window shows C as starting key
- transposing a second time works, but the keys are confusingly mismatched
Changing the original key in the database by the same number of semitones as the chords in the file would help.
My opinion is unchanged: having to set "original key" manually is the wrong way, the original key should be detected from the chords within the file.
(04-02-2016, 07:06 AM)itsme Wrote: [ -> ]- transpose e.g. to D, 2 semitones up from C, save changes
- the song is displayed in B (3 semitones down from D), correct

Well, it is equally valid to say that this is not correct.
You transposed the song display from C to A.
After changing the source from C to D, the song should still be displayed in A.

This is where key transposition bites interval transposition.

Did you transpose the display to A? Then it should still display in A (fixed key).
Did you transpose the display up 3 semitones? Then it should display in B (fixed transposition).

For example, what I often do: If I have a song in C, transpose the display to A and when the song is settled (rehearsed, ready to be performed) I change the song source to A (and cancel the transposition) since that's how is it going to used.

Having said all that, I personally have no problem with the current (fixed transposition) behaviour.
I can look into updating the starting key for the song if the key is transposed in the editor.
@Zuberman: Thank you. That will fix it & that's what I requested.
@Sciurius: Songs that I play with my permanent bands are in the key that we perform them. But there are some songs that during sessions are requested in a different key for some reasons. In that case it's convenient to have several entries in the library transposed to different keys, but referring to the same file. And, just in case, it's a snap to transpose to any other key if the "original key" is correct. MSP is great, I like using it and enjoy many of its features.