Incorrect drop anchor displayed while dragging a Volta

• Jun 27, 2019 - 22:22
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

See brief forum post: https://musescore.org/en/node/291265

The problem arises because earlier versions of musescore, specifically 2.0.0, would have voltas be dropped to the nearest measure start, e.g.:

MS2-volta.gif

Sometime between 2.0.0 and 3.0, the displayed anchor line got changed to point to the start of the current measure the mouse is in, however the resulting drop was still operating on the old behavior to drop to the nearest start measure. Hence if your mouse was in the right half of the measure when releasing mouse, the volta would get dropped to the next measure even though the anchor line gave the expectation that the volta would be dropped to measure the mouse was in.

There was some debate on https://github.com/musescore/MuseScore/pull/5167 about how exactly the best way to deal with this is. The best guess now is that lines 313-4 in Score::cmdAddSpanner():

if (pos.x() >= (b.x() + b.width() * .5) && m != lastMeasureMM())
      m = m->nextMeasure();

should simply be deleted as they are no longer wanted. They are in the else block:

{      // Anchor::MEASURE, Anchor::CHORD, Anchor::NOTE

and it doesn't seem like any other possible spanners with those anchors would want to drop to the next measure.

I'm marking as a regression since volta dropping made sense in 2.0.0, but just no longer make sense. And marked as workaround because can always drop in first half of a measure correctly.

Comments

• Jun 28, 2019 - 00:06
Title Voltas dropped with mouse should drop to mouse's current measure, never the next measure ⇒ Incorrect drop anchor displayed while dragging a Volta

I am finishing up a solution to this issue that involves returning to the behavior of 2.0.0 while retaining the ability to drop voltas on a per-staff basis if desired. I had to rename the title of this issue because it incorrectly stated the problem and contradicted the solution.

Reply

• Jun 28, 2019 - 01:51
Status PR created ⇒ active

The fundamental problematic behavior is that the anchor line and the actual drop do not always correspond to each other. Two ways to correct MuseScore's problematic behavior are:

  1. Change the drop behavior to drop to the current measure that the mouse is in, to correspond with how the anchor line is currently drawn.
    -OR-
  2. Change the anchor line to point to the closest measure start, to correspond with how the drop actually occurs and how the anchor lines were draw in much earlier versions of MuseScore.

My description corresponds with (1) and that is how I would propose to fix it. That shouldn't be characterized as "incorrectly stated the problem" or as "contradicted the solution". It is just a different approach that what you suggest. I actually think (1) is better because the volta gets applied to the measure where the mouse is currently in. But I wouldn't say that (2) is necessarily incorrect, either.

Reply

• Jun 28, 2019 - 01:58

I meant no disrespect. In saying "the anchor line and the actual drop do not always correspond to each other", you have correctly stated the problem. Solution 2 solves the problem, but not the way it was originally stated.

Reply

• Jun 28, 2019 - 02:16

For a while I was torn between (1) and (2). The difference between the two is a matter of keeping or removing those two lines in Score::cmdAddSlur() and the corresponding lines in ScoreView::dragMeasureAnchorElement(). I eventually decided to go with (2), but I could have gone either way. I even considered the notion of changing the point at which the anchor moves to the next measure, but I ended up leaving it alone.

Reply

Fix version
3.3.0