Lowercase characters are often used to write down single notes for e.g. intros or interludes.
It would be a big improvement if lowercase characters in square brackets would be transposed like chords.
See https://www.chordpro.org/beta/chordpro-chords/
ChordPro Implementation: Notes
If enabled in the config, ChordPro will understand lowercase root-only chords to mean note names. Note names will be treated (shown, transposed) exactly as chords, but will not account for diagrams.
This can be used for example for intro’s that start with some single notes before the chords:
{comment: Intro [f] [g] [a] [E] }
Adding support for this isn't really a big deal, but I need to ask - is it important to make it conditional? Or should I just make it behave that way by default? I would obviously prefer fewer settings if possible.
ChordPro is designed for making professional songbooks and tries to prevent unexpected surprises by limiting what it accepts as chords.
A chord can be
known (built-in or defined, with diagram) or
well-formed (a known root note follwed by a known qualifier and extension).
For special cases, you can select in the config:
a relaxed mode (known root note followed by arbitrary) and
a note mode where lowercase root notes are accepted (and transposable).
For MSPro this would be overkill, I think. An easier approach can be to split the chord into parts is it contains a slash, and transpose each of the parts if it looks transposable, regardless of case.
01-30-2022, 05:10 AM (This post was last modified: 01-30-2022, 05:11 AM by Zubersoft.)
Johan - that's basically how the code is already implemented. I'm mainly asking in this case if I should just handle lowercase chord letters the same way I handle uppercase. I can just convert the letters to uppercase before looking for a valid chord letter and the code should allow those letters in the same way (although when transposing I guess I would have to modify the code to leave the letter as a lowercase letter instead of converting to an uppercase letter). I was just hoping to get some guidance on whether that is the right thing to do or if it could potentially cause unusual behavior for users that might have put non-chord words inside brackets in lowercase letters to avoid having them handled as actual chords. Your last sentence makes me think you believe I should just allow the lowercase letters and handle them like any other chord definition. If so, I'll move forward with making the necessary changes.
I have never encountered users that tried to hide arbitrary words from being interpreted as chords... ChordPro gives a warning if it encounters anything between the [ ] that is not identifyable as a chord. Since we can use [*...] to denote annotations there is no reason to use tricks to hide something from being recognized.
Hello Mike,
I really would appreciate if transposing of chords in lowercase characters could be included into the upcoming ChordPro rework.
For best compatibility with Johan's reference implementation it should be possible to switch it on and off.
Yep, it's on the list of things to do. I may have to release an update sooner that contains bug fixes before rolling out a lot of new chord pro changes. I hadn't planned on making it configurable, but if that's needed, it shouldn't be difficult to add a new setting under Settings->Text File Settings.
I often do this, on paper, to notate the melody line of an intro with lower case letters, not to be confused with the chords in upper case (with "m" for minor, etc).
This will be a big step forward for me. I play the saxophone but I write melodies using both lowercase and UPPERCASE - where lowercase is used for playing the note an octave higher and UPPER for low octave - as melodies usually has jumps. My .txt files also has notes written next to each other for example
AC#edg#Bf# eedC#BA
C#ag#f#
ef#edC#
something like this but a lot of times these melodies get played in a medley in one key so I have to make a mental note of new finger position because I know the melody but not in my muscle so we ll that I can shift keys. (yes one must practice melodies in all 12 keys lol but I don't think I have the time or the will to do it for all the songs.)
basically limitations to transposing only on UPPERCASE and letters that have spacing between them should be optional. This will make my life so easy.
01-28-2024, 08:58 PM (This post was last modified: 01-28-2024, 09:02 PM by itsme.)
Spaces are a must to avoid misunderstandings. Without spaces MobileSheets is not able to decide if e.g. "face" is a word in the lyrics or a melody line.
"babe" could be a word or b a b e or b ab e
(01-28-2024, 08:58 PM)itsme Wrote: Spaces are a must to avoid misunderstandings. Without spaces MobileSheets is not able to decide if e.g. "face" is a word in the lyrics or a melody line.
"babe" could be a word or b a b e or b ab e
Perhaps two added options? One to apply the logic to lowercase and one to ignore no spacing?
01-29-2024, 06:53 AM (This post was last modified: 01-29-2024, 06:55 AM by itsme.)
"ignore no spacing" doesn't make sense. Transposing cannot work correctly without spaces (or, theoretically, another separator), as the "babe" example in my previous post shows clearly. How would you expect "cabbage" to be transposed?
01-29-2024, 09:25 AM (This post was last modified: 01-29-2024, 09:26 AM by Zubersoft.)
I have to agree with itsme on this one - spaces are essential. It really would not make sense to try to implement the parser to be able to handle chords without spaces, as it could get it right some of the time, but not all of the time. The only way it would be 100% reliable is if I only support single letter chords with it, but that seems to add limited value in my mind.