Upon further inspection, the f.b. is present in the mime data, and also added to the destination segment annotation list, but does not appear on the score.
I have created an example score showing the issues.
I have found the following bugs:
I. The first fb is not being loaded. It is present in the score's xml.
II. A range copy only copies the fb if it contains one character.
III. Selecting a single f.b. and copy pasting it causes a crash in FiguredBass::layout.
It looks like f.b. that is longer than one character is not properly created.
1) The first F.b. item in your sample score is not shown because it is empty; in principle, this should not happen (a new F.b. item is/should be removed if its editing is ended with no text entered). So, it would be interesting to know how did you succeed in creating it.
2) I made several tests and copy-paste of ranges always duplicated all the F.b. items in the range, regardless of their structure/contents.
3) Copy and pasting a single F.b. item has indeed problems. I'll check it.
I can reproduce the problem with f.b. elements not loading/rendering even for non-empty f.b. elements. In fact, as far as I can tell, f.b. elements simply *never* appear on load. Create a socre, add some notes, add figured bass, save, reload - the f.b. elements have all disappeared. Obviously, this worked at one time, but seems to have broken.
1. Create new score - instrument violin
2. Add two quarter notes.
3. Add f.b. to first quarter with the text set to fb
4. Add f.b. to second quarter with text set to b
5. Save, close, and open score.
The opened score only contains the second f.b. I would say this only fails for f.b. longer that one character.
For me it fails with one-character f.b. too. Another thing: during entry, the figured bass appears at a reasonable location below staff. but on the first re-layout after completion, it moves up to a place only 1sp at most below the staff.
I have found one more issue. Selecting the 2 character f.b and deselecting it does not fully update the color back to black. It is fixed when the focus is changed and updateAll is set.
Dragging the two character f.b. also does not draw the score correctly.
Regarding #4: "fb" is not a valid F.b. entry, 'b' is a valid entry (as 'b' stands for 'flat' and means 'minor third').
Ideally, invalid F.b. entries should be kept as the user entered them; unfortunately recent changes in the way text styles are handled made this impossible (or at least, I did not find a way to support this behaviour). Invalid entries currently are removed (possibly not completely?). Handling of text items has repeatedly changed recently.
About #5: during data entry, the f.b. entry appears at an UNreasonably low position and with an UNreasonably tall line spacing (dictated by the text editor); upon leaving the entry, it is correctly positioned and formatted according to the f.b. parameters in score style.
About #6: I cannot replicate either issues.
For a general introduction to the figured bass engine and a summary of what it expects as entries, you may look at this handbook page
.
I'm attaching a sample score I just made during the last days which has a full continuo part, just to show that f.b. IS working (I use it regularly).
Confirmed; I was testing using invalid entries as well (using it to double as Roman numeral analysis - I, V6, etc). It's only with these invalid entries that the elements move too high upon relayout, and only with these invalid entires that they disappear upon reload.
@bartlomiej_lewandowski (#9): I believe that a dlg box would be too disruptive of the work flow.
A better solution (possibly the proper solution) would be to keep the text of the invalid entry in some way, without applying the shape substitutions and vertical alignment of a proper f.b. entry. It will be probably necessary, at least at a first stage, to remove any style/formatting from the entered text, though.
It is for this reason that I'm leaving this issue open.
Comments
Upon further inspection, the f.b. is present in the mime data, and also added to the destination segment annotation list, but does not appear on the score.
I have created an example score showing the issues.
I have found the following bugs:
I. The first fb is not being loaded. It is present in the score's xml.
II. A range copy only copies the fb if it contains one character.
III. Selecting a single f.b. and copy pasting it causes a crash in FiguredBass::layout.
It looks like f.b. that is longer than one character is not properly created.
I can only partially confirm your findings.
1) The first F.b. item in your sample score is not shown because it is empty; in principle, this should not happen (a new F.b. item is/should be removed if its editing is ended with no text entered). So, it would be interesting to know how did you succeed in creating it.
2) I made several tests and copy-paste of ranges always duplicated all the F.b. items in the range, regardless of their structure/contents.
3) Copy and pasting a single F.b. item has indeed problems. I'll check it.
Thanks,
M.
I can reproduce the problem with f.b. elements not loading/rendering even for non-empty f.b. elements. In fact, as far as I can tell, f.b. elements simply *never* appear on load. Create a socre, add some notes, add figured bass, save, reload - the f.b. elements have all disappeared. Obviously, this worked at one time, but seems to have broken.
Creating the score:
1. Create new score - instrument violin
2. Add two quarter notes.
3. Add f.b. to first quarter with the text set to fb
4. Add f.b. to second quarter with text set to b
5. Save, close, and open score.
The opened score only contains the second f.b. I would say this only fails for f.b. longer that one character.
For me it fails with one-character f.b. too. Another thing: during entry, the figured bass appears at a reasonable location below staff. but on the first re-layout after completion, it moves up to a place only 1sp at most below the staff.
I have noticed that as well.
I have found one more issue. Selecting the 2 character f.b and deselecting it does not fully update the color back to black. It is fixed when the focus is changed and updateAll is set.
Dragging the two character f.b. also does not draw the score correctly.
Regarding #4: "fb" is not a valid F.b. entry, 'b' is a valid entry (as 'b' stands for 'flat' and means 'minor third').
Ideally, invalid F.b. entries should be kept as the user entered them; unfortunately recent changes in the way text styles are handled made this impossible (or at least, I did not find a way to support this behaviour). Invalid entries currently are removed (possibly not completely?). Handling of text items has repeatedly changed recently.
About #5: during data entry, the f.b. entry appears at an UNreasonably low position and with an UNreasonably tall line spacing (dictated by the text editor); upon leaving the entry, it is correctly positioned and formatted according to the f.b. parameters in score style.
About #6: I cannot replicate either issues.
For a general introduction to the figured bass engine and a summary of what it expects as entries, you may look at this handbook page .
I'm attaching a sample score I just made during the last days which has a full continuo part, just to show that f.b. IS working (I use it regularly).
M.
Confirmed; I was testing using invalid entries as well (using it to double as Roman numeral analysis - I, V6, etc). It's only with these invalid entries that the elements move too high upon relayout, and only with these invalid entires that they disappear upon reload.
That explains a lot, thank you.
One suggestion, could we move the verification of the f.b. input a bit earlier? Maybe some kind of a dialog saying informing about a bad f.b.
@bartlomiej_lewandowski (#9): I believe that a dlg box would be too disruptive of the work flow.
A better solution (possibly the proper solution) would be to keep the text of the invalid entry in some way, without applying the shape substitutions and vertical alignment of a proper f.b. entry. It will be probably necessary, at least at a first stage, to remove any style/formatting from the entered text, though.
It is for this reason that I'm leaving this issue open.
Thanks,
M.
Pull Request pushed to github: https://github.com/musescore/MuseScore/pull/968
M.
Fixed in aeed353dbe
Automatically closed -- issue fixed for 2 weeks with no activity.