I don't know much about this but using the site below, would it be pertinent that it looks like a minor key, eg. Bbmin goes to minor chords of Ebmin/Fmin [iv/v] and the A# version goes up to E#min/E#min? This seems to be true of other similar comparisons.
Reference: http://www.guitar-chords.org.uk/chords-k...minor.html
In the world of lead sheets and ChordPro files, we use the enharmonic model, where D# is equal to Eb and so on. Most guitar players will pick whatever comes out handy. For example, I personally prefer Bb over A# while I also prefer C# over Db.
More formally, a piece of music has a key which determines the tonality of the piece. In sheet music, the key is denoted by the signature (see, e.g. https://en.wikipedia.org/wiki/Key_signature). The number of flats/sharps determine the key. C has no sharps nor flats, G has a single sharp (F#), D has two sharps (F# and C#), A has three sharps (F#, C# and G#) -- see a pattern?
Likewise, F has one flat (Bb), Bb has two flats (Bb and Eb), Eb has three flats (Bb, Eb and Ab), and so on. The two series meet at Gb (six flats) and F# (six sharps), both being enharmonically equivalent.
There are two things to note here. First, a key signature only has flats, or sharps, but not both. Second, there's no signature for minor keys, they are considered the same as their major partner (Am -> C, Dm -> F, etc.).
When transposing a piece of music we change its key, for example from G to A. Since A has three sharps, we expect the chords (from G) E, B and F to become F#, C# and G# respectively.
But what about going down, from G to F? E and B become D and A, no problem. F becomes D#? or Eb? The convention is that since key F has one flat, we must use flats for the other chords as well, so chord F becomes a Eb.
The remaining problem is when the destination key is C, with no flats and sharps. For example, going from key A to key C, the F chord could become G# or Ab. AFAIK there's no convention for that.
http://www.transposechords.com/how-to-transpose-chords is very lax and informal (i.e., the average guitar player ). It uses sharps and flats at will, for example, C C# D Eb F ... Also, it sharps E into E# (instead of F) but sharps B into C.
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.
sciurius: Thanks for the explanation. In the example you gave concerning transposing to C, since you're are going to use C, does it really matter which you use, even theoretically, as long as any other similar accidental went the same direction. If it doesn't matter and a user has a preference, then maybe an option to use one or the other would work when transposing to C.
Dell Latitude 13.5" 2-in-1 Ubuntu/Win 11
Samsung Note Pro SM-P900 12.2 Android 5.0.2
Samsung S7+, Android 12
I think most of the problems/confusions are caused by functionality that has been added incrementally and finally got out of balance.
Summary: Forget about key transposition and use step transposition only.
Executive summary: Do not spend too much time on this, there are other, more important issues.
(12-15-2015, 12:07 PM)Zuberman Wrote: 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.
Yes.
Quote: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.
During import only the last occurrence of {key} is added. Wouldn't it be better to add all?
Quote: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.
Bottom line is, and here the problems start, that the song is finally assigned one single key, while in reality it can have multiple keys.
Quote: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.
Correct, but this fails when the song has multiple keys. Transposition by key will use the first key as source, and hence may generate incorrect chords for parts that have different keys.
IMHO when you allow multiple keys, you can no longer perform transpositions simply based on key. For example, if a song has keys C and A, and you transpose C -> F, then the C-parts will become F and get flats while the A part will become E and want sharps.
Quote: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.
Hmm. Maybe it is because in the example I perform a stepwise transposition of +5, not a C -> F transposition?
Quote:I think choosing a source key and then the key to transpose to (which is how it's currently implemented) should be sufficient.
As I tried to point out, performing keywise transposition on a piece that has multiple keys is ill-defined. The only safe way to perform a transposition is stepwise. Most tools that I know do stepwise (pitch-wise) transposition. See e.g. lilypond, denemo, audacity. Musescore has key transposition which is just pitch transposition under the hood.
So my suggestion would be: forget about key transposition and use step transposition only.
12-16-2015, 12:16 PM (This post was last modified: 12-16-2015, 12:17 PM by itsme.)
I really like the transpose UI of Musescore Songbook. It is very fast and intuitive.
A tap on the "##" icon opens that little window shown in the screenshot. Tapping ">" transposes up, tapping "<" transposes down, which is endless, not limited to a number of steps. "Original" returns to the original key. The letters show the main key of the song as given by the key signature (the sharps or flats at the beginning of the first line), the bigger one "D" shows the major key for the sample song (two sharps), the smaller one "B" is the enharmonic minor, "Bm" would be more clear.
Important for me is, that it is topmost in the UI, just one tap away from the current song. In case of a session very fast to be reached in case a different key is requested.
The sliders in MSP are not the best UI element for setting the key, the "Key:" slider can easily be confused with the "Transpose:" slider and the effective key is shown very small and hard to find.
It would be great if such a transposing window would exist and could be configured to the floating toolbar or a touch action.
Musescore transposing steps are
major: C Db D Eb E F Gb G Ab A Bb B C
minor: A Bb B C C# D Eb E F F# G G# A
they use the correct accidentals for the enharmonic minor keys
all flats for the major keys probably are used because they have the smallest total number of accidentals, the only questionable one is Gb with 6 flats or F# with 6 sharps
MSP uses
C C# Db D D# Eb E F F# Gb ....
Both methods have their pros and cons, the MSP method needs more steps to reach a certain destination key.
If having faster access to the transpose feature is critical, I can certainly add a new button that handles just that. I can also look into a faster UI for selecting the target key (whether by selecting a key or steps).
Johan, I'm starting to forget all the history, but I remember there being issues with transposing that were only handled if I considered the key of the song when choosing what chords to use (flat versus sharp). If you believe that following the simpler approach of "transpose up = sharps, transpose down = flats" handles all scenarios, then I'm fine with switching to that. Whether the transpose slider displays steps or the target key (based on the original key of the song), I don't think it matters so long as I'm consistent with how the transformations happen in the code (i.e. only by considering steps up or down).
Switching to the up = sharps, down = flats model means you can always change what you've got by transposing up 1, then down 1 to switch to flats or down 1 and up 1 to switch to sharps. So this might be the simplest and avoid a lot of confusion.
If you do this, it would be nice to have up and down buttons you can keep tapping and be able to see what is happening as you do. You can then keep tapping until you get what you want.
If we can agree that transposition by steps is the way to go, this would simplify things a lot.
Personally, I still think that transposition is not part of the text display settings, it is more like the metronome, deserving its own dialog. To call the dialog a button next to the [A] (top bar) would be appropriate. For example a note symbol with two arrows, up / down.
The transposition dialog would then be quite small, so you can see the effect of each transposition step (currently most of the song is obscured by the text display settings dialog).
Just an up and a down button, an orig button. Default is to use sharps when transposing up, and flats when transposing down. Since this would require 11 steps to go from A to Bb, a 'swap sharp/flat button' would be handy. For other purposes as well.
A slider would be nice, but I think does not add much value anymore.
(12-17-2015, 02:07 AM)sciurius Wrote: Since this would require 11 steps to go from A to Bb, a 'swap sharp/flat button' would be handy.
Only 3 steps. A - Bb - C - Bb would give you Bb with flat chords. And swap would be Bb - C - Bb or Bb - A - Bb depending which way you wanted to swap. So the swap button isn't that necessary, although might be more obvious.
That seems a little odd to me. If you are transposing three steps up, and then you go down one step, why would that change to flats suddenly? It's still +2 up, so shouldn't it be sharps?. If I implement it that way, if you tap past the chord you want, you have to play games with going down and up to get back to it. It also means that I definitely can't provide a slider as there is no concept of a sequential increasing or decreasing value. That's fine if that's how people would prefer it be implemented, but I just want to check before I do anything.
That, indeed, is the drawback of AndyL's suggestion. Each approach has minor pro's and cons...
Staying consistent with up/sharp + down/flats plus a swap sharps/flats would probably be most intuitive.
I'd prefer a solution with buttons like it is in MuseScore over using a slider. To reach a well specified destination key using a slider is a bit fiddly IMHO, furthermore the current destination is often hidden behind the finger that operates the slider.
How about adding buttons (radio buttons) '#' and 'b' to swith between "use flats" and "use sharps". They could also switch the sequence of destination keys from "C Db D Eb E ..." to "C C# D D# E ..." and thus avoid having duplicate enharmonics like Db / C# in the list
). It uses sharps and flats at will, for example, C C# D Eb F ... Also, it sharps E into E# (instead of F) but sharps B into C.