Octave of note-input example question
Here's a demonstration of D->E->F where F is on a new measure all in bass clef. Instead of the F being in the same domain as the previous notes, the octave jumps up to F4. Was wondering what the logic is behind this since it doesn't make much sense imo:
Comments
As usual, we really need an actual score and precise steps to reproduce the problem in order to investigate. As it is, I'll guess there is an invisible clef or something else going on there.
I can't reproduce using the steps shown in your video
Based on the replies, it seems like the demonstrated behavior isn't supposed to happen so that my lack of understanding the behavior isn't too whacky. I'll try to look into the details in a moment.
Edit: Ironically, I can't reproduce this either after copying from the whole score the area that was giving trouble, pasting it into a fresh score, then attempting the same behavior. Not pulling anyone's leg here: it did indeed occur as shown in the above screen capture, but it seems like a malfunction rather than any intended "logic" in the program. There's something fishy going on, but it sounds like a subtle bug contingent upon certain factors than regular behavior. Will update if can get a precise reproduction in steps
In reply to Precise steps weren't given… by worldwideweary
Has something to do with the original score I'm using, because I can reproduce the problem within it, yet if I copy the system into a new score and re-attempt, there's no problem. Just to demonstrate once again: the first is the attempt within the original score, the second is within a copy-pasted area:
The key signature didn't copy as shown, but that shouldn't be an issue with the problem.
P.S. FWIW, I have had something similar to this happen in the past while transcribing where the octave seems to be unrelated in the bass clef to the previous measures. Wonder if anyone else has attested to this sometime. It's rare, but it has happened, and it seems to be a subtle issue...
In reply to Has something to do with… by worldwideweary
P.P.S: This sounds absurd, but the score has been open for days on this computer (I often don't shut down but only sleep over night). Time and again I could reproduce the problem, and as mentioned, if I copied it into a fresh score, it wouldn't have the issue. I've closed the score and opened it up again, and now the issue doesn't seem to exist with this particular measure. The point then is that some how or another it feels like maybe it has something to do with not the score as a file but as a "configuration" in memory somehow. Weird.
In reply to P.P.S: This sounds absurd,… by worldwideweary
Internally, MuseScore maintains a "map" to keep track of where there are clef changes in the score, so it can quickly figure out what clef is in effect at a given point. Every so often a bug occurs where there maybe once was a clef change at a particular spot but there no longer is - like there was a clef change (or just a new system that repeated the current clef) there once but it was deleted - and somehow the map is not updated properly. Things that occasionally get in the way are multimeasure rests, switching from concert pitch and back, linked parts, etc, since they can involve separate clefs. Mostly this all works, when bugs get reported with steps to reproduce, we can normally track down what has happened and fix it. But if some corner case slips through, you can get weird effects like this one. And since the map is rebuilt on reload, that could explain why it fixed itself.
Anyhow, no doubt there is a bug here, probably involving some combination of those factors.
In reply to Internally, MuseScore… by Marc Sabatella
Bug still exists. For instance in 3.6 (beta/rc now) after having multiple sections and key sig changes/time signatures, on occasion I will get things like this:
In reply to Bug still exists. For… by worldwideweary
It remains the case as always that in order to investigate a problem, an actual score will help us far more than a video.
In reply to It remains the case as… by Marc Sabatella
Of course. Unfortunately when this occurs, if I save and reload the score, the problem doesn't occur. Looks like it will may end up remaining for a while since it seems that the underlying issue isn't known, nor have I found other posts related to the issue. I hit upon it sporadically from time to time with scores having multiple section breaks/time+key changes.
The workaround for now is to save the score, close it, and then reload it when this happens.
In reply to Of course. Unfortunately… by worldwideweary
I mentioned is a couple of years ago but I have the same problem you do, I can't reproduce it over again. It happens randomly. I see the mistake, undo the notes. Save the score, open it and the notes work fine. I use ctrl+arrows to move the notes and keep going.
This is probably irrelevant for MS4 now, but since I still use a customized Musescore based on 3.x for note entry, I figured I'd mention that sometimes a chord's "prev" segment is not correct. Don't know what the cause is, but a work around solution to fixing this issue so far was within cmd.cpp's [Score::cmdAddPitch] function where
a check if a previous segment is of type (seg->isClefType() || seg->isHeaderClefType()
and if so, it uses that to calculate which line of the staff to use as default positioning via:
curPitch = line2pitch(4, clef->clefType(), Key::C);
Catch here is that it "finds" via prev1() a HeaderClef at the same exact tick position as the input cursor which doesn't exist on the score, when it should be checking the "prev" segment from the input position. It happens rarely after multiple clef changes it seems. Merely checking if the current input position tick is the equivalent tick to a "found" clef and then omitting it to continue the while loop while getting previous segments will fix the above issue for the user, but it's old news.