beam angles are not consistent
I am making a keyboard edition with 130 pages. Musescore is beaming so unprtedictable and randomly so I have to check and correct all beams. The default beaming angle is already usually to steep (according to different people I show my edition) specially when one eight and to sixteenths are connected.
Here some examples of strange beaming: 
Note the three eight notes in bar 1 and 3 a third compass, the beam angle has to be the same but is not!
Here in the second half of each bar the repeating pattern should have horizontal beams but they go down! In some other places the beams go even in the wrong direction!
Here also repeating patterns: first half of the bar correctly horizontal, second half incorrectly angled and so on...why? I know of course I can manually adjust all these beams (I will have to) but this should not happen.
I think this problem needs to be addressed.
Comments
Do you have a source for what you think the "correct" angle should be in each of these cases? Beaming is an incredibly complex subject with many different cases to consider and a lot of variation between different engravers in how they choose to balance the different considerations - there is no simple "right" and "wrong" about it.
In particular, I don't understand what you are saying is a problem in your first example. I do agree that the repeating patterns should be horizontal, and in general we *do* try to do this, but the heuristic for detecting repeating patterns is not perfect and fails in some cases. Feel free to file a bug rpoet on this issue specifically, with short sample score.
I don't see any cases of "wrong" direction, though. All the beams I see in your example are the standard angle to be expected based on first and last note, as per standard practice (see for example Elaine Gould "Behind Bars" p. 22).
In reply to Do you have a source for what by Marc Sabatella
I don't say that there is a correct angle but in the first example e-flat d c are the same intervals as the next group b-flat a c but the beam slope is 1 space versus ½ space, two bars later same problem.
Beams going wrong direction are not in my examples but trust me that it happens too.
In reply to Do you have a source for what by Marc Sabatella
I do not think we ought to dispute the meaning of "wrong direction". SRH clearly believes that upwards rather than horizontal is the wrong direction, which in the context is not entirely unreasonable.
I am writing to support SRH. I don't know the "official" rules, but it seems to me the beams should point in such a direction as to indicate to the eye of the reader the direction the music is taking. And I find myself correcting an awful lot of them.
It is absolutely clear that this is a very complex issue and I generally try to be patient with these things. But for v. 3 it might be nice to make progress. The problem with repeating patterns occurs extremely often if not almost consistently (there are 2 exception in example 2 above, more than I usually encounter).
It is also worth pointing out that the first example features two instances of straightforward scales where the beams change slope in the middle (beat 2 and 3 in both the first and third measure). This looks weird though the first measure may have to do with the fact that the scale goes below the five staff lines and in the third measure the first group is longer than the second due to two accidentals, such that the two beams rise by the same amount but at different slopes. But I'd still even this out if it were my project because the change of slope appears (wrongly) to indicate a change in musical pattern.
In reply to I do not think we ought to by azumbrunn
In intererpted "wrong direction" in the original as meaning, the wrong direction *even not considering the special case rule for repeating patterns". And it seems he clarified that this is what he meant in his followup where he confirmed there were no cases in the examples posted. So if there are cases where we fail to do this, I would definitely like to know.
The problem is that "the direction the music is taking" is not always objectively clear. A line that contains a change in direction could obviously be seen either eway depending on, well, lots of things. The rule according to Gould is that the outer notes of the group are the only ones to consider in determining direction. She is quite explicit about this, even saying this rule should be obeyed "regardless of the direction of the majority of the notes" and gives some examples, all of which we do correctly. We this rule universally as far as I can tell, and I personally would advise aginst overriding that behavior manually since it *is* standard practice in published literature as well. But we do provide the manual override for the beneift of those who prefer a non-traditional beam angle based on some subjective criteria that seems like it might justify breaking the rule for.
Regarding the repeating patterns, it looks like our algorithm is pretty simplistic for the sake of speed (and speed is something maybe we won't have to worry about so much any more with the "incremental" layout in 3.0). Our algorithm only looks at beams of 4 or 6 notes, and only cases where the pattern breaks down as 2+2 or 3+3. So a six note beam that breaks down as 2+2+2 won't be detected, nor will an eight note beam of 4+4 (or 2+2+2+2, which of course is also 4+4).
In reply to In intererpted "wrong by Marc Sabatella
I think in bar 16 (last 6 ⅛ and 17 (first 12 ⅛) the beams should slope down or be horizontal.
In reply to [inline:bwv 1004 gigue.png] I by SRH
Why would you say that? The last beam group in bar 16 starts on D and ends a third higher, on F. That clearly calls for an upslop beam according to the standard convention I mentioned. Ditto on the beam groups in bar 17 - they both go up a third betwene the first and last note.
In reply to Why would you say that? The by Marc Sabatella
You are right, sorry
In reply to Do you have a source for what by Marc Sabatella
The big problem with the beams is they are quite steep (angle too sharp) in general compared with many good editions and specially too steep for short groups, specially two sixteenth and one eight.
![beams.png]( "beams.png")
When placing high and low notes with the stems pointing towards the middle of the stave, Musescore does not place the end of the stem (the one opposite the notehead) any further higher or lower than the middle line. If the option existed to break this convention either in certain circumstances or via a selection in Inspector then this might make it easier to place runs of beamed notes such as are requested here.
In reply to When placing high and low by underquark
Could you give an example of what you mean?
In reply to Could you give an example of by Marc Sabatella
One convention (that MuseScore adheres to) is to extend the tip of the stem of high or low notes until it reaches the middle line of the stave rather than having the stems all the same length. For individual notes and for small groups of notes this generally looks OK but when you get a few clusters of beamed notes then this stem tip placement takes precedence over the beam angles. If you allowed the stem length rule to be broken (or, at least, over-ridden or de-selected) then the task of getting the beam angles harmonious might be made easier.
In reply to One convention (that by underquark
I'm still having trouble following. Are you suggesting that we default to doing what your second system shows instead of the first? That looks clearly wrong to me - beams are intersecting ledger lines. If you really like this look, you can obviously get it, but I don't know of any established convention that would actually recommend this. In fact Gould specifically insists there always be at leats one full staff space cleareance.
In reply to I'm still having trouble by Marc Sabatella
If you don't like the beam angles forced by the rule that all note stems of ledger line notes have to extend into the staff proper: There is always the octave sign: It will give you the good angle and also avoid the huge distance between note heads and beam (which slows down reading, at least for me).
But moving beams into ledger line space makes reading (especially of course sight-reading) all but impossible. It obscures the number of ledger lines as well as the distance to the staff proper--one of which at least you need to read the note correctly.
You are right Marc, sorry
I'm still unaware whether there's been any progress toward this issue I posted about in May 2015. I'm now using 2.0.3 on Windows 10, and the problem (which is very frustrating) remains the same as I (and other forum members) described it here:
#59946: stem lengths inconsistent in beamed groups of three or more repeated eighth notes
In reply to I'm still unaware whether by [DELETED] 448831
Beaming – specifically angles and stem lengths – is unsatisfactory in MuseScore presently. The evidence is abundant in this thread and especially in the one from one year ago, to which I link in my comment above and to which there has been no response. I have stopped using the program completely due to my frustrations with both these flaws and the way critiques of them have been handled.
Coincidentally, I have stopped playing piano. I hope it's a temporary hiatus, but we'll see. At my age I need customized scores for vision problems, and I don't have the time or energy to tweak manually the beam layout for potentially every beamed group of notes.
It's a bad situation, and it's regrettable and frustrating to see that it is variously defended or unacknowledged. Please revisit the numerous examples that have been provided, especially in the post of May 2015, by me and others.
In reply to Beaming – specifically angles by [DELETED] 448831
exactly:
that is what I mean...
In reply to I'm still unaware whether by [DELETED] 448831
As I have said, beaming is a complex and subjective topic. I am sorry if you perceive that statement to be dismissive, but it's the unfortunate truth. We can't special case every single possible combiantion of notes - we need algorithms to follow. So, in order to make improvements, we really need new and specific guidelines to implement - if X happens, do Y - that sort of thing. Ideally from a known respected authortiy. Anything you can provide to help in this regard would help us make improvements. if you see my comments in the other thread linked, that's exactly what I asked for there as well. I am not trying to say we will never do anything - I am saying we can't do anything until we have a clear vision of what needs to be done, and that is where we need your help.