Automatic renaming of chord symbols when changing the fret number of a fretboard diagram.

@Jojo-Schmitz: Yes, at first glance it is and the solution would be as simple as that if there was no possibility to input the intended fret directly into the fret-number box via keyboard. This makes it a bit more complicated but not so much that there wouldn't be a satisfying solution.

I have an idea for such a solution, but as explanation got a bit lengthy I add it in the form of a winword file. Please be so kind and read through it, nevertheless. Thank you for your interest.

Musesore request_verbessert.docx for some reason the promised file didn#t appear. Now it should be visible.

Discussing the issue with a friend I became aware of a few minor flaws in my pseudo code and that I didn't regard the explicit indication of bass notes within a chord symbol. Although I consider that a marginal problem that could deliberately be ignored I thought about a way to heal that, too, for reasons of completeness. Therefore here is a - hopefully - final version of my description. You can forget all formerly uploaded versions. Now I did it as a PDF at once. I'm willing to learn, you know ;-)

@odelphi231: Thank you. You got my idea right! disregarding the possibility to reuse the same variables for different values (which I do not consider a good programming style for reasons of transparency), I do not exactly see, however, where there is a lot too much logic in the pseudocode than has to be. You might be right, nevertheless. I don't know what already existing functions of Musescore could be reused, or which tricks are provided by musescore's true programming language. If so, it would be still easier to implement this feature, wouldn't it? Please take into account, that there can be an arbitrary number input directly into the fret box greater than 1! That's why you have to calculate a little bit. An array for the possible root names or something similar, you would need anyway. To use two of them spares you the calculation of accidentals and when using long ones you are spared further calculation for wrapping at the end. separating the chord symbol name into 2 or 3 parts can't be circumvented, IMHO ...
Including the supplement of renaming indicated bass notes, it won't be more than about 50 ... 60 lines of code. Considering your objection, even less.

@jojo-Schmitz: No, I think so, as long as you do not consider my proposed code as very difficult. Where do you see difficulties beyond that? Please don't forget, the purpose of the whole feature is not of finding a new fingering pattern when the same chord (the same symbol) is to be played in a different position! That would allow only certain fret numbers, of course, and the diagram would look completely different then. That shall not even be attempted. It is neither to displace fingers along the fretboard (although this corresponds greatly to what we're doing with the diagrams).
No, we're just talking about assigning a template diagram to a particular fret, with the diagram - as a template - not having originally been assigned to that fret. In other words, we so to speak place it right from the template area to any position the user desires. That is what our mind intends. We think of the correct fretboard position and the correct chord name from the beginning. "shifting" the fret is only the method of how to achieve it because the pattern is "pre-assigned" to an unwanted fret. Musescore provides a convenient method for that already. But every template brings along its "pre-assigned" name, too, that corresponds only to the fret as it is stored in the template. When "shifting" the diagram, you sure do not only think of its fret but also of its root letter, don't you? Like in Excel copying a formula from one cell to another you won't want only the line numbers have been adapted automatically but also the column letters. Am I right? It's all about the fret numbers and the letters. As the consecution of root letters is a clearly defined one it is about simply doing a number of steps or only one. The shape of the diagram, which is merely the finger pattern, is of no concern.
The idea behind this is, that the user knows in advance which fingering he wants to use and in which position. And that he finds a diagram in his template section meeting at least the needs for the pattern but not for the position. (This will be much more often the case than meeting both needs because you have to assign the diagram to a certain fret in order to match the name with which it is stored in the template section. The root name is affected for the same reason) There are many possibilities to play a chord on the fretboard. As well it is a realistic concern to be reminded of using a particular structure of the chord, i. e. a particular inversion, and at what position. Now the guitarist is relieved that the symbol already comes along with the diagram. He accepts the fact that he has to adapt the fret number, yet, in order to render the position he thinks of. Otherwise, the diagrams stored in the template section would increase by a factor of 12!!! But then he sheds bitter tears because he still has to adjust the chord name ;-) He asks: "Why hasn't that just been shifted with the diagram at once?" Do you get me?
Your objection is justifiable in a sense, but only for the very special case when using diagrams with open strings, that is, with fret number 1 and some strings indicated by the little open circle left to the diagram. Are you playing the guitar? For me, as a guitarist, this is nothing to waste a thought on. No guitarist that knows more ways to play chords than those few open chords (not meant as an insult, not at all) will ever attempt to play those open chords at another position than the first fret. Therefore he would never change (=shift) the fret of such a diagram. If he did so, he would have to reshape the whole diagram. If he needed that very chord in another position, he would use a completely different diagram. Every guitarist, that uses a capo knows as well, that he can't shift those diagrams without shifting the capo - and then shifting of those chord diagrams would become as legitimate as of any others.
By the way, how ist the use of the capo in musescore regulated regarding diagrams? Let's say you want to use open string chords in Ab-major, Db-major, or E-major (to make it extreme). You would place the capo on the fourth fret, wouldn't you? The fingering patterns you use then would be those with the open strings obviously (E, A or C, and the other chords in the respective key) for that's the reason for the capo at all, isn't it? But which DIAGRAM would you then use for the Ab-, Db- or the E-chord? Hardly that with open strings, but barred ones? I'd do that. Well, I really don't know. I never use a capo. Or do you REALLY use those open diagrams then and indicate the diagram's fret now as one above that where the capo sits? Then anywhere else there would have to be indicated that the capo is set on a particular fret. Your objection then would become needless, for even those basic diagrams could be shifted mechanically from the 1st fret to wherever they are really fingered and again the root letter would have to be adapted the same way.
To dispel the last doubts I also want to point to the abundance of fingering patterns that do not use a barré but are restricted to four fingers. I call them "four-note-chords" and they are widely used. Their diagrams use only four of the guitar's strings, either the upper four, the inner four, or the lower four. Some of them as well mute a string in between. Think of a "C7" on 1st fret using only the inner 4 strings, or a "dm7b5" on the inner 4 strings of the 5th fret or "C9" on 2nd fret or "G7b9" = "Ab°" on 3rd fret (which can be fingered with and without barré) - just to name some more common ones. Usually, such a diagram indicates a string with one or two little x on the left side. All those diagrams can mechanically be shifted as barred chords can, for they use no open string!
Please understand me being so tenacious. I welcome a discussion of the various aspects. But I want to promote the implementation of this feature and do not want it to not even been attempted, for some unnecessary reservations.

@ jojo_Schmitz: Now I got what your worries are. Let me dispel them.
1. Yes, your chord with the question-mark could be named. It is a simple F-major triad if you mute (or just don’t use) the formerly open strings, a full-fledged F-major chord if you consider the saddle as shifted along with the diagram. This corresponds with the intention when increasing the fret number!
2. Musescore does not assist in this intention, because open-string-indicators are preserved, after increasing the fret number. They are neither replaced by mute-string-indicators nor is an additional fret for the barré index finger inserted, as would be necessary to keep the structure of the chord while shifting up.
3. The failure is not by an automatic renaming but by increasing the fret number of that very diagram at all. As well one could blame Musscore for allowing the chord structure to be destroyed when increasing the fret number. But I won't do that. It is the responsibility of the user alone! Automatic renaming would even render that failure less gravely, for it at least would change the name into a halfway correct, intended one.
4. I feel that you hesitate to implement the automatic feature because you have come across some irregular results, you would feel obliged to eliminate in any way. But those irregularities are the status quo of Musescore! They result from shifting a diagram mechanically that has a fixed relation to the first fret. These are the "open chord diagrams". These are simply not allowed to be shifted.
5. Musescore cannot, of course, prevent a user from doing so. But so what? Who has bothered about so far? If a user did so he shows a lack of competence IMHO. He has to live with it then.
6. It makes you very honorable that you try to intercept all boundary conditions cleanly and produce a consistent result. I was into software development myself and have always appreciated such programmers. Often enough, they by their care revealed weaknesses in the concept and thus saved the project. But sometimes they were too focused on preventing unwanted user actions. A certain amount of competence can well be required of a user and if his action won't crash the program or annihilates data or does no other harm, then it is not indicated to invest too much brain into healing his mistakes. Intelligent programs are a good idea, but they should not spare the user his own thinking.
7. The diagram, after all, only represents the actual fingering pattern. Increasing the fret number of the diagram is preceded by the intention or the really performed action of shifting your fingers on the fretboard sideward. The increasing of the fret number then is only the consequence of such an action or intention. And because no one would actually shift his fingers from an open chord pattern or even intend so (he would always place his barré finger, too or chose a completely different pattern for his fingers) no one would either increase the fret number of such a diagram. Hence there is no need to treat open chord diagrams in a special way.

Summary: Your objection is correct - increasing the fret number of "open-chord-diagrams" produces strange, irregular, irritating chord patterns. But this has absolutely nothing to with a possible automatic renaming. The pattern is "wrong", whether the name then is automatically renamed or not. The name is even wrong when no automatic renaming takes place. On the contrary, with automatic renaming, the name becomes even correct in the sense of the intended chord. Musescore can't prevent users from doing wrong or senseless actions in any case. For instance, you can shift the head plus stem of a note via the Y-parameter of the Inspector to a position that makes the note look like a completely different one. Or you can shift a G5 note via the Y-parameter as far above the stave that it's not recognizable which note is meant at all. Is there a need to prevent that? No, it needs not to be prevented, not at all!!! The same is valid for "open chord diagrams". Simply ignore their special features and treat them as any other diagram. In practice, no one will try to offset these diagrams and if doing so nevertheless, would not affect the functionality of the proposed procedure nor of Musescore as a whole.

Concerning your diagram patterns, I still haven't found out, yet, how to include pictures directly into the comment. Therefore I attach my own diagrams as a PDF. concerning open chord diagrams.pdf

What do you think?

@odelphi 231: You mention a "Realize Chord” Tool. I know nothing of it, but that would sure be a great thing! Where could I find it and how do I implement it in Musescore. I’d really like to try it out!

@odelphi 231 & @jojo-Schmitz: Please let us separate three problems.

Problem #1 is that the name of a diagram is no longer valid after shifting the diagram on the fretboard. The true chord of the diagram is different than given by its name. Although its structure is similar, the name is “wrong”. The chord symbol is not “coupled” to the diagram. Both are isolated objects, although the user looks at both of them as a unit! That problem has been present for long in Musescore and still is. It needs the user to become aware of it and manually correct it. It looks as if this approach worked well. No one complained so far (except me ;-). However, the problem can easily be eliminated by automatically rename the symbol of the chord. That is “coupling” the symbol to the diagram again. Musescore already does this by storing a diagram in the template section together with its symbol and bringing along the symbol when moving the diagram from the templates onto a note. But it does that only half-hearted, for it then cuts the connection between diagram and symbol. My initial proposal was to keep that connection intact, which means to adapt the symbol name when shifting the diagram.

Problem #2 is how to find the new name for a shifted diagram /chord. Certain root names of chords can be enharmonically expressed as sharp or flat ones. Which variant shall be realized, then? Shifting a chord/diagram preserves the structure of the chord and the sound. Focussing on the root letter alone when renaming, preserves the structure as well in the chord’s name. This can be done quite mechanically. Only, the decision has to be made, yet, if sharps or flats should be applied. For that, I made my proposal. My pseudo-code is not important. I only wanted to deliver a POSSIBLE solution. It would work, however. If one thinks iteration would be enough, well then be it so. The solution for this problem #2 is handling chord names as bound to a diagram. This approach has nothing to do with the 3rd problem. Or, at least, it just makes the 3rd problem emerging overtly.

What we’re discussing meanwhile, is that problem #3: If “open chord diagrams” are shifted their structure gets distorted! The problem is restricted only to that group of chords/diagrams and in that, they are distinct from all other diagrams! This behavior had been occurring all the time before in Musescore and I suppose it will continue to be for a while. As long as Musescore handled diagrams as isolated objects not knowing of chord symbols that may even did not exist for that note, the problem vanished into thin air. No one cared if shifting an open diagram resulted in a meaningful chord and if that was the intention of the user. "If he does so – well then, he obviously wants it this way." Now, that the diagram brings along its symbol, “suddenly” the mismatch between the resulting chord/diagram and symbol name after shifting becomes overt. But no one does this! Every guitarist knows that shifting an open chord on the fretboard has to be done by applying a different finger pattern. Hence he knows, too, that he has to use a different diagram. Please do not push the discussion in the direction, that under certain (very rare) circumstances a user might possibly intend such a weird chord that results from mechanically shifting an open chord diagram. Well, he can do that, of course. Why not? He just has to adapt the symbol and find a weird name for that weird chord. But how often will this happen? He has to find and manually edit that name even now. If you blame an automatic renaming feature for that difficulty, you are dodging the problem.
There are three ways of how this problem can be solved:

a) you ignore the problem and let the symbol name become wrong after shifting. Leave it to the user to give it a proper name or to replace the diagram with that he intends. Automatic renaming then could be done regardless of open chords. It would NOT worsen the situation - the resulting name would be as wrong as without automatic renaming. even slightly improved IMHO, for it at least gives the intended name.

b) You inhibit shifting of open chord diagrams. The prerequisite is that you are able to realize the character of the diagram as an "open" one. If so, the naming problem doesn’t come into being. Automatic renaming would be no problem. Jojo-Schmitz calls it "cheating”. I say: NO. The user still can create such a weird diagram, just not by shifting but by reshaping another diagram. However, I do not prefer this way. It’s just a thought.

c) When shifting you undertake the difficult task to reshape automatically an "open diagram” into one that preserves the chord structure. The prerequisite here would be, that you are able to recognize the diagram as an “open” one and to automatically increase the quantity of frets and automatically place a full-length bar in it. If so, this would be the only sustainable solution: insert an additional fret left to the finger points and lay a full bar across that empty fret, with the bar representing the former saddle of the fretboard and being now the barring index finger. (Nothing else is the purpose of any barred chord or the capo). It just has to be done automatically. The user would then watch how the pattern reshapes itself in the inspector when increasing the fret number of an open chord diagram. Nevertheless, he could afterwards reshape the pattern himself to his liking.

Variant c) would be the most consequent solution, b) a half-hearted but not so laborious one and a) the most pragmatic one. I suppose, theoretically even variant c) might be possible, because in the inspector all elements of a diagram are separated and can be changed independently and manually. Why not automatically, then? In practice, I guess, this would prove to be an enormous effort, if possible at all. If we don’t want to do so – or cannot do so – we are restricted to variant a), aren’t we? This does not discredit the automatic renaming, though. There are always exceptions that cannot be handled by mere code. They can be intercepted, that is, inhibited at best. But that’s not necessary here.

@odelphi123:
Thanks. I have spent some time with your great tool. I have some annotations that you might like (hopefully) - or not ... They are only restricted to the tool. This may be a bit off-thread. therefore I just include a PDF here and a Musescore MSCZ File to let it not intermingle with the actual discussion. Testing the chord realization tool.docx Testing the chord realization tool.mscz

@odelphi123 Hallo, your recent proposal has a lot of charm! It would open many possibilities and take the initial idea of an automatic renaming to a completely different level. But it is not so simple. Just to give some general hints:
There exist about 40 different chord structures for a single root name. 20 are surely what is more or less common. however, The others are required in certain pieces only (mostly jazz). But would it make sense to exclude them with such a basic approach? There are 12 frets so almost each of the twenty chords could be located on any of the 12 frets. Moreover, for each of those chords there exist 6 to 8 different ways to finger it on the fretboard. this makes it approximately 1500 to 2000 chords (considering only your "20"). And then there are the chords that can be interpreted as belonging to a different root (C6 = am7, E° = G° = Bb° = Db°, C+ = E+ = G#+, em7b5 = hgm6 = C9 (no root) = some more). What about Db enharmonically being equal to C#? The sound may be interchangeable, the name is not, according to some people, who discriminate between those possible names for the same chord, because they correspond to different keys. It depends on the piece on the context. Last not least there are simply the various ways a chord name can be noted. Cmajor7 = Cmaj7 = Cj7 = C#7 = some more which I cannot display here. Altered chord tone digits can be indicated by a "#" or a "b" but as well as by a "+" or a "-" and all that before or after the digit. xm7b5 can be written as xmø, an X7b9 can be written as an X° (with the root disregarded). OK, denotation variants could be reduced to one variant. But if you want to derive a diagram from a look-up table based on the chord name, you have to store all possible names AND all possible diagrams in the table. And you have to assign several diagrams to the same name, assign several names to the same diagram, and split a chord name into several notation variants. That goes even for fewer than 20 chord names. Still, there is the factor 12, even if some of the chords cannot be placed on every fret. The table would get quite huge. It's not a question of how much space it consumed, but who is to fill in all those data? Lastly, you have to present always a series of diagrams for a certain root name where the user can select from. At one time he might prefer one diagram at another time the other one, but you can't constrain him to the only one that you chose.
Instantly I'd say a relational database would help a lot. But do we really want Musescore to be driven so far?
Don't get me wrong, I vote for your approach but it would be an immense effort. The alternative would be programming algorithms which would mean as much effort. In any way, your proposal needs some more thorough and more detailed discussion and above all a programmer who would be interested in taking on that task.
In the meantime, I take my initial idea (including inhibition of shifting open chords) being a pragmatical approach that consumes not so much effort - be it only as an interim solution.

odelphi123, I go for the same aim as you, a pragmatic solution that needs as little effort as possible but has the best result. I don't hang on to an idea, just because it's mine ... Neither do I deny your point at all there would be only 20 relevant chords. He who needs more sophisticated ones can be referred to manually editing and rightly so. Could perhaps even be reduced, slightly. I guess, when you speak of 20 chords you mean chord names, that is, chord structures, not diagrams. That's how I understand it. Still, I maintain, that with 20 different structures you would easily get twice what you assumed. Saying no one knows more than 200 chords (patterns) is saying he does not use more chords (diagrams) actively; probably even fewer. That's not the point, for everyone knows and uses some different chords (diagrams!) than the other ones. And musescore is for everyone! More: It's for "composing". You can't exclude any of the possible 12 keys, how seldom it might be used. I Don't want to become laborious again ;-)
So or so - It is of no importance. 300 or 600 makes no real difference. A relational (and normalized) database would reduce that amount substantially. Only 3 tables would be necessary ("name variants", "archetypical patterns", "actual diagram" - with the diagram-table being a combination of "name.pattern.fret" indexed for all 3 columns). You are speaking of a "database" now - do you really mean that or is it just a slip of tongue? Anyway, I have no clue which possibilities musescore offers for a programmer. You are more experienced, as I acknowledge considering your tool. So I believe you and say, we have consensus. "Ensuring that the name of a diagram is always given correctly, even if it is shifted" could be done well using a look-up table (or database?). This would even eliminate the problem with open chords. Their shifted variants would just not occur in the table. Full stop.
The only thing to do now is to find someone who does the work. Are you able to do that? Are you willing to do that? Do you know someone you could recruit?