[2.X->3.0] Incorrect edit barlines markers behavior
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S3 - Major
Status
active
Regression
No
Workaround
Yes
Project
See the attached gif. It is unable to extend barline up. At the same time extending barline down results in random-like jumps. The attached score is from #41961: Bar line span not extending.
| Attachment | Size |
|---|---|
| We_wish_you_a_merry_Christmas.mscz | 14.39 KB |
Comments
It seems it is possible to extend barlines only to the neighboring staves so it should not be probably possible to extend barlines up. Still the UI for this is really misleading.
We may consider removing grips drawing and editing for barlines since there is a new "extend to next system" property.
In reply to We may consider removing… by Anatoly-os
If you're talking about making it so barlines cannot be extended to several staves, this is a very bad idea. It is normal for all instruments in a section in a symphonic orchestra to be connected by bar lines.
In reply to If you're talking about… by mike320
You are able to do that by checking "Span to next staff" checkbox for all barlines in the score.
In reply to You are able to do that by… by Anatoly-os
The barline situation is simply messed up. I just looked at your picture closer. It should not be easy to apply a different barline to a singe staff. Applying it to one staff, should apply it to all staves. Your picture shows the end barline only on the bass clef staff.
I have discovered that if you add a different barline to the score, then add a new instrument, the barline will not be applied.
You can also select the different barline and press delete, it is only removed from the selected staff, not every staff.
The wonderful needless new way to extend barlines has broken them. The version 2 method worked fine and allowed for a great deal of flexibility. The new method just makes too much work if you change your mind about the barlines and makes no improvement.
I agree there are bugs that make the current situation less than ideal, but the question is, once the bugs are fixed, will the new implementation still be lacking any features or flexibility or ease of use? Some time ago dragging barlines to connect staves wasn't supported at all but now it is. That to me was the main thing that needed to be addressed, so I'm happy to see that. It is indeed glitchy though. Seems to work better in scores created from scratch as opposed to imported from 2.x? Separate bug reports should be filed (if they haven't already) for the behavior of deleting double bars and adding instruments not inheriting the double bars.
See https://github.com/musescore/MuseScore/pull/4184
Fixed in branch master, commit a72f8538c1
fix #274437: update limits for dragging barline grips
Fixed in branch master, commit a0118ba8c1
Merge pull request #4184 from dmitrio95/274437-barline-grips
fix #274437: update limits for dragging barline grips
In testing the barlines behavior, I still see no ability to extend barlines using the edit boxes on the end of the lines.
Was that score by chance created in 2.x? I seem to see that barlines extend fine in new scores, not so well in imported ones, just as I said a few responses back.
Yes, this score was imported from version 2.3.2. I'm currently checking out import issues and need to remember that for some reason scores created in an earlier version don't work like version 3 scores. It shouldn't matter though.
The underlying issue is really complex. The markers work correctly for the barlines which are automatically generated. If you change the barline property, it becomes custom, so you need to adjust all properties manually then.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.1.5001, revision: 451cdc1
Same issue (see attached score)? Double click on a barline in the treble staff, drag it down to the tab then release.
Expected result: All barlines extend down to tab.
Actual result: All barlines extend down to tab except the barline that was dragged.