Implement better automatic placement of tuplet when avoiding the staff

• Jul 9, 2019 - 11:17
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

As tilted with attached score and capture, the second tuplet text has an obvious bigger distance to note beams by default entry, it can be adjusted in Inspector with "Y", but could it be better that automatic placement just keep the same distance as 1 and 3 by default?
Capture.JPG


Comments

Further found: for the second note with best visual position Y=-0.95, MD=-999.00 comes out and after save and reopen, this position can not be kept, bug?
Before Save:
Capture.JPG
Save and reopen:
2.JPG

Title 3.2.3.7735 Tuplet text to beam automatic placement distance? Tuplet text to beam automatic placement distance inconsistent and not saving?
Frequency Many Once
Type Performance Functional

Been that way ever since (read: at least in 2.3.2). I guess Elaine Gould wants tuplet numbers outside staves?

It's a style setting, see Format / Style / Tuplets / Avoid staves. Looks like you've deliberately altered the stem lengths in your last example, at the defaults, it doesn't look so wrong. In cases like that, though, you are probably better off flipping the number/bracket to the notehead side.

So as far as I can tell, this is by design, unless I am missing something. However, I'd certainly consider the possibility we could improve the algorithm for choosing which side to place the number/bracket so that it goes to the notehead side in cases where the beam is deep within the staff like that. Perhaps "avoid staves" could notice when it is offsetting more than, say, 1 sp, and flip if so. Also, I note Gould says it's OK to overlap the staff partially, so maybe we just allow 0.5 sp overlap.

Title Tuplet text to beam automatic placement distance inconsistent and not saving? Implement better automatic placement of tuplet when avoiding the staff
Severity S3 - Major S5 - Suggestion
Status needs info active

Well, sure, everything I describe is correct, including the fact that we should consider in the future enhancing the design to add a new feature where we automatically flip the tuplet to the opposite side of the staff than normal in those specific cases. That's why I said I'm leaving this open. as a Suggestion for just such a feature.

In reply to by Marc Sabatella

A few cases:

One, current Automatic Placement:
1.JPG

Two, current Automatic Placement Flipped:
6.JPG

Three, text next to beam, no flipping:
3.JPG

Which one is best way of notation it?

OR:
Four, your future plan explained please?
5.JPG

THis tuplet text is such a basic simple entry, even with Musescore 3 now, still under development?

As I said, this case is subjective, the rules of notation allow different options, and different editors choose different ways of doing it. MuseScore allows you to choose your favorite. And yes,, MuseScore is indeed still in development, so we're always open to making further improvements, and as I said, someday we might implement a feature where we make a different choice than the default in this special case. Feel free to start a discussion in the forum to collect opinions on which we should eventually implement.

Well, as I said above, I don't have a plan yet, I'm waiting for you or someone else who is sufficiently motivated to start a discussion int he forum to get a consensus on the best way to handle it. Right now I'd lean toward adding a couple of other style settings that would be looked at when using the "avoid staves" option. One to specify a "maximum distance from beam" to allow, the other would specify what to do in those cases: either partially overlap the staff, or flip the number to the opposite side. The latter is actually a bit more complicated - we'd have to start laying it out on one side, then realize it's a problem, then start over. And you'd find the number flipping back and forth as you edit the beam angle. So it's possible all I'd really want to do is do the partial overlap. But again, I don't plan to do anything until a forum discussion produces some consensus.