Manually edited beams won't flip on x keystroke

• Jul 5, 2021 - 17:53

If I manually adjust a beam’s height or angle I can no longer flip its direction with an x keystroke. Nor will Musescore’s Transpose function flip manually edited beams where appropriate.

I regularly want to flip an “edited” beam—naturally with the same height and angle. But Musescore won’t allow. What is the rational for this? It seems that Musescore oversealously wants to protect me from myself, when no protection is warranted. I didn’t like the flipped result I could easily unflip, undo, or manually edit.

Regarding Transpose ... I'd certainly like to see Automatically Flip Beams in the Transpose dialog.

scorster


Comments

Keeping the same manual adjustment would make little mathematical or visual sense upon a flip operation. is there some sort of real world problem you are trying to solve here? If so, best to attach a score and describe in more detail.

As for transpose, as mentioned elsewhere,e beams are automatically flipped unless you previously locked them.

In reply to by Marc Sabatella

Marc wrote> Keeping the same manual adjustment would make little mathematical or visual sense upon a flip operation.

Flipped are almost always ideal for my purposes, so I strongly disagree,

> best to attach a score and describe in more detail.

Sure. Just don't dis my manually set beam angle!

      Beam angle Beam Flip example.mscz

> As for transpose, as mentioned elsewhere, beams are automatically flipped unless you previously locked them.

Manually editing a beam checks its "Custom position" property in the Inspector. If the user notices the property change, they're suppose to equate "Custom" with "Locked?"

A beam with a Custom property is certainly not locked with respect to further manual editing. But as we've both said, it's "locked" to the Transpose function.

Why?

Why not allow the user the choice to "Update stem direction"? If they don't like the result they can undo and transpose without "Update stem direction" unchecked.

scorster

In reply to by scorster

What do you mean "flipped are almost always ideal for my purposes"? Are you saying you find the default stem direction almost always wrong? I assume you this is not the case. So it seems you must mean something else, but it isn't clear what Are you guessing that if MuseScore did apply the some mathematical adjustments to flipped stems, you believe the results would be to your liking? If so, what do you are this guess on, since MuseScore doesn't actually do that? I'm not following how your examples relates to this. Best to attach a score with a single example and then give precise steps to reproduce the perceived problem here in your comment.

If you manually adjusting a stem - setting it Up or Down, or set a custom position on a beam - this indeed locks it That's the whole point of their being a separate Auto" setting. If you want MsueScore to manage it for you, leave it at the default. But if you override the default, MuseScore assmes you are doing this for a reason and doens't mess with your overrides.

What you are calling "update stem direction" is exactly what museScore does by default if you haven't overrided this. If you now change you mind abotu the override and wish MuseScore to manage the stem direction for you, simply resert your manual adjustments with Ctrl+R. No need for a separate command to do that the reset command already does.

In reply to by Marc Sabatella

Marc wrote > What do you mean "flipped are almost always ideal for my purposes"? Are you saying you find the default stem direction almost always wrong?

Sorry if I was unclear, Marc.

No, I don't think Musescore's default beam/stem direction is in error.

I was trying to say that when Musescore blocks me from flipping a beam/stem I resort to manually dragging the beam, up or down, while maintaining its current angle. Thus, once I've set my preferred beam height and angle, that's when the flipped result is "almost always ideal for my purposes."

Marc wrote > But if you override the default, MuseScore assmes you are doing this for a reason and doens't mess with your overrides

I'll restate my position.

I'd prefer that Musescore allow flipping via an x keystroke when one or more selected beams are in a manually edited/flipped state. When I want to flip beam direction in a selected range of measures, and some of those beams bear a "custom" property, I can uncheck Custom—but then I lose all my custom height and angle edits, when my goal is to simply flip beam/stem orientation.

An "Allow beam flip" in Beam>Custom property would resolve this while preserving the other properties that Musescore wisely doesn't want to mess with.

Are you guessing that if MuseScore did apply the some mathematical adjustments to flipped stems, you believe the results would be to your liking?

I'm not wanting Musescore to "apply some mathematical adjustments to flipped stems" ... just to flip the stems with the height and angle I've manually set.

scorster

In reply to by scorster

The height and angle you set is relative to the existing stem direction. Consider, it's not one height, each stem has its own individual height. There is simply no way to preserve this on flipping - its physically and mathematically impossible. The stem lengths would be all wrong and wouldn't meet up with the beam. It absolutely needs to be different stem lengths. Best you could hope for is some sort of AI algorithm to attempt to calculate new values that somehow capture the essence of whatever you were trying to achieve with your original adjustment.

The "X" command does flip beams that are manually adjusted, however. I guess what your posted example shows is that is for some reason you actually drag the beam all the way from one side of the notes to the other - so the beam is technically "down" already but only appears to be "up" because of your adjustment - that flipping it "up" won't have any effect. Not sure why that would be surprising. If you want it back down, simply reset your manual adjustment.

In reply to by scorster

I didn't change my opinion; just my understanding of what you are actually talking about. Again, yes, I agree that if you change a beam's position in the specific way you did - where it's technically still "down" but has been moved above - you've successfully created a scenario in which flipping can not have any effect - the beam is already in the position flipping would have moved it to. So again, simply reset that customization.

In reply to by Marc Sabatella

Marc wrote > I didn't change my opinion; just my understanding of what you are actually talking about.

Thanks for the discussion. I think we've reached the understanding:

An active (i.e. checked) Beam>Custom Position does not alone prevent a beam from flipping on pressing x.

Marc wrote > *I agree that if you change a beam's position - in the specific way you did - where it's technically still "down" but has been moved above [or visa versa, then attempts to flip it with an x keystroke will fail.]

I'd think potential confusion, and the x keystroke's temporary loss of impact, could be easily avoided—for instance if the user drags a beam below all the beamed notes Musescore automatically changes Direction = Down. Would you predict detrimental side effects to that?

scorster

In reply to by scorster

No, I don't see a downside to a proposed change, because my guess it's exceedingly rare for anyone to ever get themselves into this situation to begin with. Why drag a beam to the wrong side in the first place? Only reason i can think is if you don't know about the "X" command - and in that case, you won't notice it doesn't work :-)

In reply to by Marc Sabatella

Marc wrote > No, I don't see a downside to a proposed change,

Makes sense to me. If the suggestion were adopted then dragging a beam to the opposite side of the notes would work like dragging Staff Text to the opposite side of the staff, by updating the Direction property in the Inspector

• if one drags Staff text below the staff Musescore sets Placement = Below
• If one drags Staff text back above the staff Musescore sets Placement = Above

If beam-drags similarly updated the Direction property nobody would ever get locked out of using x to flip beams.

Shall I make a formal request in the Issue Tracker?

scorster

In reply to by scorster

The complication is that it isn't just the beam that has direction, it's also all the stems, and they aren't necessarily the same. So there's actually an extremely complex set of algorithms that happen to determine the position in several different passes. It's not likely to be easy to make the change. To me, the fact that it's trivial to reset the beam with Ctrl+R makes it hard to justify the effort. But harmless to put in the request. And hopefully at some point this will all be rewritten. it's some of the same code that makes it problematic to solve the issue of beaming across system breaks.

I've never had occasion to edit beams. I might flip them first, however. Sure, you can't always know ahead of time.

Remember that when I reproduced your original problem from your score, I got the same results. The beams did not flip and where smashed up against the text above. What text style is that? Recall that when I moved the text out of the way, the beams did flip. Also, if I placed the same text in staff text format, the beams also flipped. That says to me that it's not a transpose problem as much as it is a text style problem.

In reply to by bobjp

bobjp wrte> Remember that when I reproduced your original problem from your score, I got the same results. The beams did not flip and where smashed up against the text above. What text style is that?

The provenance of that score was MusicXML. I noticed that Musescore set the text type property as Staff Text, which is what I would expect and choose.

bobjp wrte> Recall that when I moved the text out of the way, the beams did flip. Also, if I placed the same text in staff text format, the beams also flipped. That says to me that it's not a transpose problem as much as it is a text style problem.

I recall that you cited the text as the source of the flip issue, but that did not text out true here.

I think I may have gotten to the root of the problem in the attached score— which is the same as the score I attached in my reply to Marc:

Beam angle Beam Flip example.mscz

Thanks for your interest and comments on this.

scorster

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