Can you detail please what you do, step by step, to get what you describe.
EDIT: Ok, I think I understand. You place the fingering one above the other (as a chord). Indeed, it seems to have a problem :(
I check, and I add a new comment.
I think you have find a new bug, alas! :(
In the sense of bass to treble, that's correct.
But in the opposite direction, it's very unexpected.
So, for the first two numbers (15 and 13), it's ok.
But when you enter the third number (14), it removes the second (13)!
And when finally you enter the fourth number (12), the four numbers back, but with a wrong result (15/10/17/12, instead, as expected: 15/13/14/12). What the hell?
I look at other implications associated with linked staves in particular, to see whether the normal priority or critical.
I tried to read the code again, I do not understand much...again! :(
I just hope that this patch does not change the algorithm in its latest update there is about two or three weeks, ie the fact that a note of Voice 2 don't "steals" the place of a same note, entered before into Voice1.
I used it several times to my full and complete satisfaction, and I think that's real progress.
For the other fix you mention, there was not one, but two bugs. It caused a major issue lately, and Marc came just before the beta1 release, almost in urgency (I think I'll remembering this evening for a long time ... I was glued to the screen, and I imagined Marc delve into the code to find the culprit and wring his neck !)
Great moment! :)
After one hour, two bugs were fixed.
An effective response seen the results. Then, I am simply unable to have a relevant opinion on a side effect or not :(
So I wait for now forward to the new patch :)
Comments
Hello,
Can you detail please what you do, step by step, to get what you describe.
EDIT: Ok, I think I understand. You place the fingering one above the other (as a chord). Indeed, it seems to have a problem :(
I check, and I add a new comment.
I think you have find a new bug, alas! :(
In the sense of bass to treble, that's correct.
But in the opposite direction, it's very unexpected.
So, for the first two numbers (15 and 13), it's ok.
But when you enter the third number (14), it removes the second (13)!
And when finally you enter the fourth number (12), the four numbers back, but with a wrong result (15/10/17/12, instead, as expected: 15/13/14/12). What the hell?
I look at other implications associated with linked staves in particular, to see whether the normal priority or critical.
After checking with linked staves, and copy-paste, there is apparently no crash.
Yet the problem is clearly significant, with a bad result and display notes and numbers.
Regarding my first tests, the issue occurs when the numbers involved are equal and above the number 10.
- And only (subject to further checks) in the sense treble to bass.
In this latter example, the number 1 is deleted from the first string from the input of 12 on the second string.
I let normal priority, but I'm not sure of myself: these results are very unexpected.
According to my checks, it seems that this specific issue appeared on August 21.
Nightly, August 21 (8aofd79): correct
Nightly, August 21 (53a33ec): wrong
PR with fix posted on github: https://github.com/musescore/MuseScore/pull/1283
M.
I tried to read the code again, I do not understand much...again! :(
I just hope that this patch does not change the algorithm in its latest update there is about two or three weeks, ie the fact that a note of Voice 2 don't "steals" the place of a same note, entered before into Voice1.
I used it several times to my full and complete satisfaction, and I think that's real progress.
Can you reassure me about this? Thanks :)
@cadiz1, #6: yes, I can reassure you, voice 2 can be still added without 'stealing' the string(s) of voice 1 (here ).
Also, the fix of #25867: Standard staff linked to TAB staff shows wrong notes on some combination of mouse+kbd note entering. is still working as well; in fact, I suspect the current issue has been introduced (or worsened) by that fix...
M.
Thank you to reassure me. Great new :)
For the other fix you mention, there was not one, but two bugs. It caused a major issue lately, and Marc came just before the beta1 release, almost in urgency (I think I'll remembering this evening for a long time ... I was glued to the screen, and I imagined Marc delve into the code to find the culprit and wring his neck !)
Great moment! :)
After one hour, two bugs were fixed.
An effective response seen the results. Then, I am simply unable to have a relevant opinion on a side effect or not :(
So I wait for now forward to the new patch :)
Fixed in 8b47515343
cadiz1 - love your dramatic telling of the story! :-) There *was* a pretty big flurry of fixes in the hours leading to the Beta.
But yeah, I am not terribly surprised to hear that fix might have broken something else. Either way, the new code looks nice and clean :-)
Automatically closed -- issue fixed for 2 weeks with no activity.