Some notes randomly jumping to top octave when input
Reported version
3.0
Type
Functional
Frequency
Few
Severity
S4 - Minor
Reproducibility
Randomly
Status
needs info
Regression
No
Workaround
No
Project
1) Using a standard keyboard, fill up one measure with notes
2) On the first note of the next measure that is input, the note will occasionally be input as the topmost note of that pitch that the specified instrument can play.
Comments
I've seen this before. I wish I could reproduce it on demand, but I can't. When I've run across this, use undo save the reload the score it no longer does that.
This seems related to #284886: Notes not entered in first measure entered into wrong octave, but I understand the cause of that one, and it wouldn't apply here if I take that initial post literally. So we'd need precise steps to reproduce this problem. From what I know of the code, it's hard for me to see how this could be anything but completely deterministic given the same score and same steps.
As indicated in the Reproducibility field, this is a fleeting issue. I have seen notes suddenly jump to an unexpected octave, deleted that note then entered the note again and it was in the correct octave. I don't know how to reproduce it on demand. Perhaps the other fix will clear this up? We'll have to wait and see and I'll keep an eye out for the issue in the future to see if I can recreate it on demand.
Came up again in https://musescore.org/en/node/286514
Came up again in https://musescore.org/en/node/293887
And this is a random bug, not a suggestion. I really thing the status should be Active, but since it can't be reproduced I guess it will stay in needs info and ignored until someone figures out the cause.
The way I figure it is, MuseScore is a collaborative effort, and non-developers are just as capable of helping figure out how to reproduce the problem as developers. So, feel free to not ignore it and try to find steps to reproduce :-)
A status of Needs information means the bug cannot be reproduced and more information is needed to recreate the bug. No one is even sure a bug exists. In practice, if an issue stays in this status very long, it normally means user error and the user never tells us what they did wrong so the issue remains in Needs info for years until someone decides to go through old issues and close them due to no response. When I look for open issues, I generally ignore "Needs info" issues for this reason and someone looking to fix bugs will not look for a bug that needs info to fix.
This bug is not in that category. At least two of us users/contributors who know enough of what were doing to agree the bug exists, the reproducibility of Randomly tells us there are no clear steps to reproduce the bug while a status of Active tells us that it is a legitimate bug that needs fixed. It tells us nothing about weather the issue can be reproduced.
As you say, "needs info" means " the bug cannot be reproduced and more information is needed to recreate the bug". This bug most definitely is in that category. It means, a developer cannot immediately begin working on a fix, because he lacks the steps to reproduce the bug. A status of "Active" means any developer can immediately sit down and reproduce the bug and therefore begin working on a fix. This bug is not in that category - yet. Since we all agree the bug exists, all it needs is someone to spend the necessary time experimenting to find the steps to reproduce it reliably, but that doesn't need to be a developer - it could be anyone interested in seeing the bug fixed.
The combination of Active but reproducibility "randomly" is indeed an odd thing on the surface that does sort of seem close to "needs info", but to me it's something different. It means we have a precise series of steps that is known to lead to lead to the problem if you repeat that same series of steps enough times. But right now we don't have even that, and realistically, that's not a very common scenario. More often, "randomly" makes sense for bugs that are indeed "needs info" in the sense we don't even know the steps.
Anyhow, the bottom line is, there are many people in this world capable of putting in the work needed to find steps to reproduce this bug, so if this bug stays in "needs info" state for long, it's on all of us.
Instead of fixing this as bug could we add a feature to 1) inobtrusively display what is the current default octave for note entry in the staff 2) make it possible to change that def. octave with a shortcut
Thank you for developing this software it's a joy to use