Manually edited beams won't flip on x keystroke
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 Keeping the same manual… 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 Marc wrote> Keeping the same… 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 What do you mean "flipped… 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 Marc wrote > What do you… 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 What do you mean "flipped… by Marc Sabatella
Marc wrote > If you manually set a custom position on a beam - this indeed locks it.
I think you rightfully changed your opinion on this below.
Here's an example score that illustrates when beams become locked (i.e. won't flip on an x keystroke.)
Beam-Custom position vs. Flipping beam direction with x.mscz
In reply to Marc write > If you manually… 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 I didn't change my opinion;… 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 Marc wrote > I didn't change… 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 No, I don't see a downside… 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 Marc wrote > No, I don't see… by scorster
(Duplicate)
In reply to Marc wrote > No, I don't see… 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 I've never had occasion 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