allow unicode flat and sharp as input for chord symbols #3461
Conversation
Jojo-Schmitz
force-pushed
the
chord-symbols
branch
from
8dd5814
to
6599841
Compare
|
I haven't built this to test, but it kind of surprises me that it works to just change this here. Seems that will only catch accidentals used in the chord root (or bass note) but not in the chord extension. |
|
I've toyed with this some 2 years ago, so indeed would need to test this (again?). Doesn't work at all currently, the whole chord symbol rendering seems broken or disabled in master. Changed it to replace them all on input already, which seems the better choice and at least should work in current master too |
Jojo-Schmitz
force-pushed
the
chord-symbols
branch
3 times, most recently
from
a6b0711
to
0a18c72
Compare
|
I don't see how that would work either - as far as I can tell the replacement happens before the text exists. Have you verified this works? |
|
No, not yet. It is carnival here ;-) |
|
OK, I finally tried it, and no, it does not work. To do the replacement, you'd need to treat the keystrokes as they come in (in edit) or when finished (in endEdit) or when parsed (in parseHarmony). A quick test suggests doing it at the very beginning of Harmony::endEdit() seems to work. More testing would still be required to make sure it really works correctly with respect to parts, transposition, etc. |
|
Thanks, I'll move them there, tomorrow ;-) |
|
BTW, another approach is to allow the accidentals but parse them normally. That is, add them to the parser in chordlist.cpp (ParsedChord::configure) as well as convertNote(). This approach would mean they stay Unicode even when the user goes back to edit the chord later. The replace approach means if he edits later, he'll see "b" et al. Maybe that's better, then he'll learn he doesn't need the Unicode characters. |
|
How exactly did you test it in |
|
The parsing in edit() is just for the sake of the "spell check" so it is harmless - and maybe useful - if it fails there. I am not comfortable with replacing on each keystroke - which is how it would with edit() - because I think it would be disorienting and possibly glitchy to have your text changing as you type. Better to do it at the end, just as wedo with "b" and "#", I think. Do the replacement right the very top of Harmony::endEdit(), before even calling Text::endEdit(), since the latter has a bit of a ripple effect the links. At least, that's what makes sense to me at first glance. Still would need more extensive testing with respect to parts and transposition. |
|
How to get at the string there? Got to be from |
Jojo-Schmitz
force-pushed
the
chord-symbols
branch
from
0a18c72
to
ab90eed
Compare
|
What's the status? |
|
"Work in Progress" or "Help needed" ;-) I can't get it to work |
|
_username should indeed work. It also works to user the accessor function hUserName() as you were originally. Seems to work fine in 2.2, except as I mentioned, more testing woud be required. As you observed, master has more severe issues with chord symbols, so I didn't even bother trying that. |
|
Ok, so I'll better switch to 2.2 for this |
libmscore/harmony.cpp
Outdated
| _userName.replace("\u0394", "t"); // Δ | ||
| _userName.replace("\u00d0", "o"); // ° | ||
| _userName.replace("\u00f8", "0"); // ø | ||
| _userName.replace("\u00d8", "0"); // Ø | ||
| TextBase::endEdit(ed); |
There was a problem hiding this comment.
in 2.2 this is Text::endEdit();, guess that might be why the above replacements are not working in master?
There was a problem hiding this comment.
No, it isn't that, stepping thru with a debugger (I really should have done that much earlier) shows that the replacement happens, but gets reverted by the endEdit
There was a problem hiding this comment.
Odd, it worked for me when I tried it. But there is stuff going on with transposition and links that could be complicating this. I'm not worried, this strikes me as extremely low priority. The supported way of entering these symbols is easier.
There was a problem hiding this comment.
I agree. The discussion here shows that it will be hard to add this in 2.2 since we don't know what we will break :)
There was a problem hiding this comment.
Well, the problem is that it doesn't work at all. If it were, it'd be a simple text replacement before any interpretation and only the previously known characters would ever make it into the score file.
@MarcSabatella: I'd really like to see what you had working...
|
Not different in 2.2, it still doesn't work there, the replacement does take place as seen in debugger, but doesn't take any effect or gets reverted by the |
|
Exactly what you have - those same replace statements right at top of Harmony::endEdit(), exceptr for 2.2 instead of master. Worked as expected for me in my test, but again, I recognize results may differ depending on transposition, parts, etc. |
|
very strange, I did the very same stuff in 2.2 and it didn't work there either, see #3475 |
Jojo-Schmitz
force-pushed
the
chord-symbols
branch
from
ab90eed
to
957895a
Compare
libmscore/harmony.cpp
Outdated
| @@ -735,6 +735,14 @@ bool Harmony::edit(EditData& ed) | |||
|
|
|||
| void Harmony::endEdit(EditData& ed) | |||
| { | |||
| _userName.replace("\u1d12b", "bb"); // double-flat | |||
| _userName.replace("\u226d", "b"); // flat | |||
There was a problem hiding this comment.
stupid mistake, it should be \u266d
Jojo-Schmitz
force-pushed
the
chord-symbols
branch
from
957895a
to
97b59b2
Compare
Jojo-Schmitz
force-pushed
the
chord-symbols
branch
from
97b59b2
to
e7af8da
Compare
and also double flat and double sharp, Δ, °, ø and Ø.
Jojo-Schmitz
force-pushed
the
chord-symbols
branch
2 times, most recently
from
654fd20
to
3f094b4
Compare
|
@Jojo-Schmitz as far as I understand, this PR is ready to be merged, isn't it? |
|
Yes, I think so |
also double flat and double sharp, Δ, °, ø and Ø. Comes up at times. last time in https://musescore.org/en/node/269352