Buggy "Line Element" like alta/bassa and slur --> fail for range extension
Reported version
3.5
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
- Placing of elements out of the "Line Pallette" to voices other than no. 1 will not work for all elements correctly:
1) Placing by drag and drop to the notes of voice 2 or higher is not possible (for alta/bassa and slur)
2) Workaround: select note of voice and double click element in "Line Palette" will place correctly
3) Range extension of the line element intervall by pressing SHIFT-RIGHT ARROW or SHIFT-LEFT ARROW doesn't extend correctly to the right-/leftmost note. Instead nearest voice 1 note always is chosen for extension, not the nextmost note of higher voices. - Alta/bassa cannot be extended to notes which have been time extended and connected via slur.
- Accidentals are inserted where they are not necessary and they cannot be deleted (always re-appear).
All mentioned above you can see on the c-es-f-a accord (3rd accord in the first measure) in the example.
I put a workaround with a combination of 8va and a dashed line to have it look-like as it should.
Try to extend the alta line element and you will see the malfunction.
Similar situation can be seen on first accord of measure no. 5.:
1) The 8va alta also cannot be placed by drag and drop, only by note selection and double click.
2) Alta can not be range extended to the rightmost accord, despites it is of the same voice no. 1!
Dash line in the example was manually extended by mouse movement and additional 8va alta as hidden was introduced to have a work-around wich looks-like as it should and also is played as it should.
Both mentioned bugs are still inside the nightly builds of Sept. 14th and were definitively not seen in version 3.4.1 of musescore ore even in 2.3.2.
Please fix this annoying bug!
Many thanks and a big thank you for thegreat MuseScore, I love it and use it since years!
| Attachment | Size |
|---|---|
| Test to show malfunction of line elements.mscz | 26.63 KB |
Comments
3) Range extension of the line element intervall by pressing SHIFT-RIGHT ARROW or SHIFT-LEFT ARROW doesn't extend correctly to the right-/leftmost note. Instead nearest voice 1 note always is chosen for extension, not the nextmost note of higher voices.
To clarify, on all of the items I've tested (which may not be every one) using shift + arrows changes the anchor to the next note or rest regardless of voice. This is used as a trick to put matching hairpins (one cresc, one dim) on a single note. Slurs are an exception to this.
Slurs can be dragged to voice 2, most other lines cannot, but they can be placed the usual way, by simply clicking (double-click hasn't been necessary for several releases) on them in the palette. So the "workaround" is simply to use the more efficient method in the first place, or to use Shift+Left/Right.
I'm not understanding the second point - are you referring to ties or slurs? I have no trouble attaching additional lines in either case.
One thing you might be confused about in your example - extending the line in measure 5 to encompass the chord on beat 2 definitely works, but it's a bit deceiving because that chord overlaps the chord on beat 3 and the octave line is trying to show you this. You can shorten the line to try to convey to the reader that the chord on beat 3 should not be included, but this also creates the misleading impression that one half the duration of the chord on beat two is meant to be up an octave. Probably you can get away with this, but anyhow, the point is, it's a bit of a corner case. I suspect we should shorten the octave line automatically.
Anyhow, I am not aware of any changes in any of this any time in the past few years - can you post a simple examle (score before lines are added, then precise step by step instructions) to illustrate the change you are seeing?
In reply to Slurs can be dragged to… by Marc Sabatella
Dear Marc,
first of all thanks for the very quick response to all of you.
Yes, you are right, double-click is not necessary anymore. I was used to double-click from MuseScore 2.3.2.
I am talking about slurs which I was not able to move to all voices, not the ties.
For some explanation from you I can follow but MuseScore 3.5 definitively has a bug on how it handles 8va line elements and also the other octave rise / lower elements as bassa and 15ma etc.
The slur line element works fine with your hint that SHIFT-UP / DOWN jumps between the voices. This I didn't know so far. Thank you very much for giving this valuable hint.
Also for slur and many other line elements drag and drop works on all voices, but not with the octave lines and crescendo forks etc.
But this also didn't work in MuseScore 2.3.2 and the 3.4 versions. I cross-checked it. So this behaviour (In my functional expectation I would say bug) was there from the beginning.
Coming back to my example of the file uploaded in my initial post. If you have a look on the 3rd accord (the one with the ties) if you remove my octave lines and the additional dashed line I added and insert an 8va line again on the 8th part of that accord, musescore adds the 8va line also covering the last 8th in that measure and inserts an additional b-minor which is not necessary and it cannot be deleted. work-around is to click on the release sign or hide it.
With one SHIFT-LEFT you can correctly cover only the tied 3rd accord by the octave transformation, this is correct. But you don't see any dashed line anymore. Manual extending the line range via its anchor points with the mouse doesn't work as the range anchor points are also changed even at very small movements.
To have the 8va line pretty printed over the whole accord you have to add an additional dashed line as work-around.
I uploaded with this reply also the same two issue measures again, but this time entered with MuseScore 2.3.2.
MuseScore 2.3.2 also shows no dashed line after range shortening for measure 1, but when dragging the anchor points of the text element / the dash line the range anchor points of the note position do not move and you can manually achieve a pretty aligned dash line (see the file example below) The funny thing is, if you import this MuseScore 2.3.2 file into MuseScore 3.5 the correct line position and range is kept, even if you change and re-change it! The unneccessary b-minor sign also is not set by MuseScore 2.3.2
Coming to the second measure no. 5 you are right that the 8va works from palying point of view.
That means if you initially insert at measure 5 the 8va the whole measure is covered including the last quarter note. Pressing SHIFT-LEFT once reduces range to the first quarter note and the second half one, but again dashed line is displayed wrong, only covering the first quarter note.
If you now extend the end of the dashed line via mouse movement to cover the half note, line will be extended, but the range anchor point moves and the half note is not transformed up anymore.
Therefore I added in my work-around a second 8va to that note.
When pressing SHIFT-LEFT twice after initially adding the 8va only the first quarter note is covered correctly.
Compared to MuseScore 2.3.2 (also in file below) this works fine and you can fully cover all notes you want without the range anchor point being moved around.
It seems to me that MuseScore gets confused with the half rest in voice 2 in measure 5.
So it shortens its dash line to fit over the half rest only and not showing the true lenght.
Hope my long and detailed description helps to find and resolve this two bugs.
Many thanks in advance!
Unfrotunately there are enough different things going on here that's quite difficult to follow them all. I would encourage to to start separate threads in the Support forum for each individual issue you are perceiving, each one self-contained with a single example file showing the score before you make the change you feel doesn't work right, then giving precise instructions to reproduce that one particular problem. then we can more easily investigate and respond to each one by one.
Asi it is, though, it still isn't clear what bug you are perceiving, or what you are seeing work differently in 3.5 versus any previous release. So I would suggest starting with that in particular - again, a separate thread in the Support forum focusing on just one specific problem, with one specific example. Then it will be easier to follow.
Related to #311174: [EPIC] UI/UX issues and suggestions