Continuous View Navigation Bug

• Oct 22, 2017 - 13:42

I cannot find this in issue tracker:
Navigation shortcuts in scores’ parts sometimes operate erroneously but only in large scores’ parts, in my experience.
Take Arthur Breur’s excellent exciting work as an example (194 bars 27 parts 28 staves):
https://musescore.com/arthurbreur/dance-of-the-monsters-under-the-bed-2…
Procedure
1. Assume that you want to study Arthur’s work in bars #153> and in particular say the Bassoons. So click part tab Bassoon 1.
2. Change to Continuous View.
3. Find bar #153.
4. Having read across my screen, I now want the next page. Oddly Page Down now takes me to bar #1, but abnormally bar #1 is on the extreme RHS of my screen.
5. Find #153 again. End takes me to the same beginning, to bar #1, instead of the end.
6. Find #153 again. Home takes me almost to the beginning and End takes me way past the end.
7. Toggle Multibar rests (M) to OFF, and these navigation errors vanish.
8. Toggle Multibar rests (M) to ON, and these navigation problems return.
9. > and < work correctly, note by note, and in Page View, navigation works correctly.
10. My! What those monsters get up to under the bed! Can anyone exterminate this bed bug?
Operating System:
OS Name Microsoft Windows XP Professional
OS Version 5.1.2600
Service Pack 3.0
871c8ce on Windows XP SP3 on HP Laptop

Comments

• Oct 22, 2017 - 14:05

Clarify step #3.
If you use Ctrl+#F, 153, you should get transported to that measure. If you just scroll there using the horizontal slider or shoft+scrollwheel , the current cursor position remains at measure 1, consequently a page-next works the way you describe. Unless you click into that measure after the scroll.
In a full score, enabling multimeasure rests is quite unusual (and unlikely to even show any), in parts it is normal.

BTW, (and most probably unrelated): Windows XP is unsupported (by Microsoft), since quite a while.

Reply

• Oct 22, 2017 - 15:11

That score has a pickup measure that isn't setup correctly, hence the need to have invisible notes in the 1st measure, so it isn't included in the multimeasure rest in the parts.
See https://musescore.org/en/handbook/measure-operations#other, and use 'Exclude from measure count" rather then using a measure number offset. You now need to do this in score and in all parts, changing in score only doesn't seem to propagate to existing parts (neither does setting 'break multimeasure rests', which you seem to have used in score, after having created the parts), it would have ben copied though on creating them.
This may or may not be related to the display behavoir you're seeing.

Reply

• Oct 22, 2017 - 18:06

With e9287fd / Windows10

" So click part tab Bassoon 1.
2. Change to Continuous View.
3. Find bar #153.
4. Having read across my screen, I now want the next page. Oddly Page Down now takes me to bar #1, but abnormally bar #1 is on the extreme RHS of my screen."

Are we talking about the same thing?
So:
1) Load this file (your file): Dance_of_the_Monsters.mscz
2) View Bassoon 1 Part
3) Toggle in Continuous View
4) Ctrl + F: enter "153"

Result: Not only the display does not reach the measure 153 (it remains at the start), and we also observe a jump to the right.

  • If that's it, we can also show this in main score and from scratch:

1) Load this file (SATB template> 1 page, exactly 20 measures, and parts): 20 mesures.mscz
2) Switch in Continuous View
3) Ctlr + F: Go to measure "20"

Result: the same (?) failure to display the measure 20, and jump to the right.
- EDIT: Note also that parts are not necessary: 20 measures no parts.mscz
jump.jpg

With a score of 19 measures, the behaviour is as expected (with same steps, and Go to measure "19): 19 measures.mscz

It's rather simple to get crash with your file (and mine). And with different ways. Involving mmrests, but not only, far from there.
I could develop that, but not sure that it is really useful at this stage.
So, probably to wait the root cause had be fixed.

Reply

• Oct 23, 2017 - 01:47

This reported issue is specific to 3.0 dev.

I had not seen at the beginning of the message that it was done with 2.1 (and because I had already encountered this kind of "jump" with the 3.0 dev. since several weeks or more, but without going further into the investigation). And so, my point of view was already guided by some memories!

So for 2.1, it's other thing, and I can reproduce also with the score and from scratch.
It's due to mmrests when they are at the end of a part.
Reported soon in the Issue Tracker.

Reply

Do you still have an unanswered question? Please log in first to post your question.