Posts: 1,231
Threads: 194
Joined: May 2015
Reputation:
13
When you click the [#] button in this situation, the key changes to C# and all flat chords in the song become sharp. That's the nature of the key.
However, when the key is C, F, ..., the chords are always displayed according to the nature of the key and you cannot switch sharps/flats. If I have a song in C and I want a chord to show as Bb, I cannot do this.
There's been a long discussion already whether this is a bug or a feature.
Johan
johanvromans.nl — hetgeluidvanseptember.nl — mojore.nl -- howsagoin.nl
Samsung Galaxy Note S7FE (T733) 12.4", Android 13.0, AirTurn Duo & Digit (Gigs).
Samsung Galaxy Note S4 (T830) 10.5", Android 10.0 (maintenance and backup).
Samsung A3 (A320FL), Android 8.0.0 (emergency).
Posts: 41
Threads: 14
Joined: Mar 2016
Reputation:
0
(11-06-2016, 07:09 PM)sciurius Wrote: When you click the [#] button in this situation, the key changes to C# and all flat chords in the song become sharp. That's the nature of the key.
However, when the key is C, F, ..., the chords are always displayed according to the nature of the key and you cannot switch sharps/flats. If I have a song in C and I want a chord to show as Bb, I cannot do this.
There's been a long discussion already whether this is a bug or a feature.
Your description of the way MobileSheets works is not what I am talking about at all. If a song is in C# or G# or F#, the app should be able to change those keys to Db, Ab, and Gb, respectively. AS far as I can tell, it works. However, see below....
I have a song that changes keys from C to Db on the last chorus. That last chorus refuses to show in Db. It shows C# and refuses to change. I have been talking to Mike via email and he is looking at the problem. We aren't even sure it is a problem, as it could be something about the song file.
Posts: 13,284
Threads: 301
Joined: Apr 2012
Reputation:
234
11-07-2016, 02:18 AM
(This post was last modified: 11-07-2016, 02:21 AM by Zubersoft.)
What you are describing makes sense with how my application works. You basically aren't transposing, as you are leaving the song in the key of C, but you are wanting my app to change existing chords from sharp to flat, which it won't do (as C is always treated as sharp). The only thing the sharp/flat buttons do is toggle what chords are shown in the transpose dialog (and thereby changes whether the transposed chords will be flat or sharp).
The correct thing to do in this case is edit the chord pro file itself and change the chords from C# to Db. This can be done in MS Pro by tapping the "A" at the top right of the overlay and selecting "Edit File".
Having said all that, if people would like me to add code so that my application will change chords (even if not changing the key of the song), I can do that. I can also try to see if I can support having C be handled as sharp or flat, depending upon whether the flat/sharp button is toggled, but I have a feeling this will cause some really annoying issues in my code.
Mike
Posts: 1,858
Threads: 287
Joined: Sep 2014
Reputation:
31
I like Sciurius` idea of applying the '#' / `b` button to the chords within the song in case the current key (after applying transposition) is C. This should not be too difficult and would probably solve the issues of LD Jackson and Sciurius. I think I also came across a situation where I wanted to see a Bb chord within a song in C. On the other hand C C#dim Dm G7 is a common turnaround in C. So it really makes sense for the key of C to allow specifying if sharps or flats shall be used.
Editing the chordpro file is just a workaround that fails as soon as a song is transposed to C from a base key other than C.
For other keys I doubt that this is required. F is clearly a 'flat' key, G is a 'sharp' key. I can't imagine a situation where I would want to see an A# chord instead of a Bb within a song in F.
What will remain an open issue is the case when a song changes the key within the song. The base key remains unchanged, but a b-section or a bridge modulates to a different key. Or it modulates every verse a semitone up. I'm afraid there will always be exceptions that automatic transposition cannot handle correctly.
Posts: 13,284
Threads: 301
Joined: Apr 2012
Reputation:
234
11-07-2016, 03:50 AM
(This post was last modified: 11-07-2016, 03:52 AM by Zubersoft.)
It's not quite that simple for me to apply the # or b to C because I don't currently store the value of that toggle anywhere. If you bring up the transpose dialog with a key of C, change the toggle to flat, tap OK, then bring up the dialog again, you will see the toggle switch go right back to sharp again, as I dynamically determine whether to select sharp or flat based upon the currently selected transpose key. All of my logic is optimized using lookup tables so that I can very quickly figure out what keys to use when transposing based upon the number of steps. I also have a lookup table for determining if a given transpose key should use sharps or flats. That lookup table assumes each key has just one index, so that makes it impossible for C to be both sharp and flat when I perform my lookup. So in order to handle this special case for the key of C, I need to add a new flag to the database which determines if the song should use sharps or flats while transposing, and that flag will be driven by the toggle switch on the transpose dialog. I then need to pass that flag down into the sections of code that actually transform the chords while transposing so that I can either just use that flag to determine sharp versus flat, or add a special case for C that uses the flag instead of the lookup table (using the flag for every transformation probably makes sense).
Changing the database like that means I need to update both the tablet, companion app and Windows 10 version, and every user will be required to update both the tablet and companion app at the same time. I'm fine with doing all this, I just wanted to explain why it's not a 30 second fix
Posts: 1,858
Threads: 287
Joined: Sep 2014
Reputation:
31
OK, I see. From outside it looked simpler.
Posts: 1,231
Threads: 194
Joined: May 2015
Reputation:
13
There are more issues with keys and transposition, so I would advice to not make changes until there is time to rethink it.
For example, consider this (test) file:
Code: {title: Keys}
{key: G}
[G]This part [A#]is in the [F]key of G
{key: F}
[G]This part [Bb]is in the [F]key of F
When imported, MSPro only considers one key, the last one seen. So this piece will be registered as having the key of F.
When viewed, the chords read G A# F // G Bb F. Correct.
When transposed up one step and down one step, the chords read G Bb F // G Bb F.
I still haven't found a way to get the original chords again, except for song delete / re-import.
Johan
johanvromans.nl — hetgeluidvanseptember.nl — mojore.nl -- howsagoin.nl
Samsung Galaxy Note S7FE (T733) 12.4", Android 13.0, AirTurn Duo & Digit (Gigs).
Samsung Galaxy Note S4 (T830) 10.5", Android 10.0 (maintenance and backup).
Samsung A3 (A320FL), Android 8.0.0 (emergency).
Posts: 874
Threads: 87
Joined: Dec 2013
Reputation:
10
Why not make a copy before editing to eliminate re-importing?
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
Posts: 1,858
Threads: 287
Joined: Sep 2014
Reputation:
31
Manual editing does not help: even if I write explicitly [Bb] into a song in C it is displayed as A#!
|