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
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