Perplexed by Join Beams
I would think that—with a single eighth note selected—Join Beams would beam the selected note to adjacent notes (immediately fore and aft) where possible.
Indeed the Handbook seems to suggest this when it says: [The Join Beams] item creates a permissive rule on beam creation connecting the selected note and both of the two adjacent notes.
But then, I'm not sure how to construe the phrase: "on beam creation".
In contrast to my shaky interpretation of Join Beams functionality, the following score demonstrates Join Beams issues I've encountered in MuseScore 3 & 4 and now in MuseScore Studio 4.3:
https://musescore.com/user/35880724/scores/16720552
Perhaps some aspect of the underlying logic is lost on me.
Secondly, I don't think the average user should have to grapple with algorithmic Boolean concepts of permissive and dismissive rules. This seems like developer-speak that leaked into the documentation.
Information from the v4 handbook:
• https://musescore.org/en/handbook/4/beams#change-beaming
• https://musescore.org/en/handbook/4/beams#set-default-beams
scorster
Comments
I agree. Definitely not what I had expected.
I tried exactly the same as you: When I selected only the 2nd note and clicked the Join beams button, nothing happened. Same if I clicked only the 4th, 6th, or 8th notes. If I click only the 3rd, 5th, or 7th notes in that same measure, it joins the one before and the one after. So, if I click the 7th, it beams the 6th, 7th, and last notes.
Up to now, I had believed that Join beams, connected the selected note with the note before it, and made no change to the note following. Obviously I was mistaken.
This belief is somewhat understandable, since the only situation I commonly use Join beams on is to make the whole measure joined when it's in two beam groups of four. So, I'm usually selecting the 5th, which (apparently?) joins it to the 4th and 6th (but since the 6th is already joined, nothing obvious happens there.)
[A few moments later] Okay, now I'm seeing different behavior. When I have unbeamed 8th notes, and have an odd-numbered note selected, sometimes it joins the one before and after, other times it joins only the one after as I had previously expected. Same thing with an octave [not an "octave", dummy: a "measure"!) of unbeamed 16th notes: even-numbered notes don't do anything when I click the Join beams button, odd-numbered notes sometimes join only the following note, other times join both the preceding and following notes.
So, what is the actual logic?????
In reply to I agree. Definitely not what… by TheHutch
Thanks for the feedback and confirmation!
re: "If I click only the 3rd, 5th, or 7th notes in that same measure, it joins the one before and the one after."
I saw behavior like what you described but not consistently, and not on a measure with all notes previously set to No Beams.
Can you offer steps to replicate?
In reply to Thanks for the feedback and… by scorster
After trying more, it was inconsistent in both quarters and 8ths. I have not yet found how to do it repeatedly. I'll keep looking at it, as I have time.
In reply to After trying more, it was… by TheHutch
Quarters and eighths?
In reply to After trying more, it was… by TheHutch
I am not at all surprised that Join Beams does nothing on a single note in a measure of unconnected 8th notes. Why would it? I didn't tell it what notes to connect. What if I only wanted the note before it to beam to. Or only the note after? Just like other procedures in MS, I range select the notes and then hit Join Beams. That works. I'm also not surprised at some of the odd things that happen if I try it with every other note selected.
In reply to I am not at all surprised… by bobjp
The icon on the button would appear to indicate that selecting a single note would connect to both the notes before and after. Instead, it does not behave consistently.
If I have four eighth beamed notes, then four more beamed notes (which I believe is the default beaming pattern, since I've never changed that) and select the note before the beam break, I would expect it to connect after (again, because of the icon on the button). It does not. Only selecting the note after the beam break and then clicking that button joins across the beam break.
We should be surprised if performing a particular action gives different results. As I've said before, this is one of the two primary types of bugs. (The other primary type being that a particular action gives an incorrect result, including no result at all.)
I see now that the Break beam left button occasionally behaves other than I would have expected. It managed to re-join a break to the left that I had just broken with it. ... and I got it to repeat once and twice, but not a third time (as I was trying to actually record what I did :-(
We are not saying that the results should be x or y. (At least, I'm not.) We are asking what the logic is so that we can know what to expect.
This behaves in the same way in MuS 3.
But if I select the whole measure, apply "Beam middle" and then apply "Beam start" on the 3rd, 5th and 7th notes, I get the desired result.
![Beaming.png]( "Beaming.png")
No, the behavior doesn't seem logical ...
"I would think that—with a single eighth note selected—Join Beams would beam the selected note to adjacent notes (immediately fore and aft) where possible."
This is correct. It is incorrect to say, however, that it is "possible" since the notes you set up on your example were explicitly set to force [No Beam]. Whoever wrote the handbook entry stated that it "forces Musescore to use flags rather than beams." Changing one note in-between a bunch of notes that are set to force [No Beam] will only enable it to join to notes that will allow beam connections, such as notes already set to [Beam Start], [Beam Middle], or [Auto]. Seems logical enough, but whatevz. Diff'rent strokes, diff'rent folks... though it does seem like the [permissive/dismissive] thing is kind of not direct enough to the point and could be "cleaner" in thought. What the hell do I know, though...
I’m not crazy about the Handbook wording, but the basic concept is actually not that complicated.
Join beams is, “I am willing to to be joined to the preceding note even if the default says I shouldn’t”
Break beam left is, “I am not willing to be joined to the preceding note even if the default says I should”
No beam is: “I am not willing to be joined to any other note, period”
If someone wants to update the Handbook they would be welcome to.
Remember, these are properties of notes, ones that are persistent. They aren’t standalone commands run once and then forgotten. So if you have one note set to “no beam” and the next set to “join beams”, then of course results might be surprising. You’re asking for two mutually incompatible things at once. One note says “I don’t want to be beamed”, the other says “I want to be beamed”. No matter which one ‘wins”, the other property is going to be ignored and someone who expected it to win will be surprised. The current design is, “no beam” wins. If it were changed so that “join beam” wins, then the result would simply be equally surprising to someone who expected “no beam” to win.
It seems you are thinking of these as “commands” rather than “properties” - so, more like “last command executed wins”. That could be logical as a UI, but somehow that information would need to be recorded into the file so the beaming is the same when you reload the score. There is no way MuseScore could be expected to remember months later which command you executed last - all it has to go on is the information actually stored in the file. So even if such commands were added, they’d still have to have the effect of writing properties to be read later.
There are probably a number of ways such commands could be designed. One might be, a “beam these notes” command where you make a selection of multiple notes, and any beam into or out of that group is broken but a beam is forced within the group. That’s the equivalent of setting the first note to break beam left, all others in the group to “join beams”, and the first note after the group to “break beam left”. Perhaps such a command could be made as a plugin.
In reply to Remember, these are… by Marc Sabatella
Hi Marc,
Thanks for your thoughtful analysis.
• Marc wrote > ... if you have one note set to “no beam” and the next set to “join beams”, then of course results might be surprising. You’re asking for two mutually incompatible things at once. One note says “I don’t want to be beamed”, the other says “I want to be beamed”. No matter which one ‘wins”, the other property is going to be ignored and someone who expected it to win will be surprised. The current design is, “no beam” wins.
I surmised that the Beaming tools were setting properties—a large hint is the palette name: Beam Properties
My concern is that currently its relatively simple to invoke competing underlying properties.
For the record, Beam Properties>Auto actually suits most of my needs when cleaning up edits that have produced undesirable beaming.
Nevertheless, I’d like to see an option of Beam Selected Notes Only. I think that would make perfect sense to the average user.
• Marc wrote > One might be, a “beam these notes” command where you make a selection of multiple notes, and any beam into or out of that group is broken but a beam is forced within the group. That’s the equivalent of setting the first note to break beam left, all others in the group to “join beams”, and the first note after the group to “break beam left”.
Exactly. With Beam Selected Notes Only we'd set three properties (on various notes) in one simple step—and with less mental gymnastics! Presently Join Beams is readily willing to beam across barlines—a result that's rarely wanted.
• Marc wrote > Perhaps such a command could be made as a plugin.
I think Beam Selected Notes Only would provide enough service and simplicity that MuseScore would benefit from building it in. I've posted a Github request that points to this discussion.
• Marc wrote > If someone wants to update the Handbook they would be welcome to.
When a feature or function proves difficult to document sometimes that indicates the underlying structures aren't ideal. So I wonder if there's wisdom in reviewing the current approach.
I’ll sit out on documentation editing … whilst rooting for Beam selected notes only.
Thanks again!
scorster
In reply to Hi Marc, Thanks for your… by scorster
Note that “beam selected notes only” might save a click or two in some cases, but it would be more work in others. Consider, selecting the notes you want beamed would always take two clicks, whereas very often only a single application of “join beams” to a single note is all that is needed currently. In the end, it’s kind of six of one, a half dozen of the other. I wouldn’t be in a hurry to risk breaking compatibility by completely redesigning the system from scratch just to maybe occasionally save a click. I’d be more inclined to see someone improve the Handbook. Of course my online course covers this in more detail also…
Anyhow, since as I explained, under the hood it’s going to have to be based on properties anyhow, implementing new commands to set those properties is certainly possible and not a bad idea. If done well enough that can be proven not to ever make things worse like the “join selected notes” on its own clearly would, I’d be fine with that. But I’d doubt it would happen soon, hence the suggestion the idea be tested and fleshed out via plugin first as proof of concept.
In reply to Remember, these are… by Marc Sabatella
Yes, that makes sense. I guess I was thinking of it as a "command" rather than a "property".
Thanks, Marc. Cogent as always! :-)
I've given a little thought to how a command-based system might look. As I see it, one would want:
Plus of course all the subbeam things, but those can be dealt with later.
Another possibility is for a system not based on commands at all, but one that treats a beam more or less like a line currently, with endpoints you move to lengthen or shorter the beam. This seems like an attractive thought, but it gets weird in some pretty simple cases, like if you try shortening a beam over four eighths to only cover two - that leaves two eighths unbeamed, or a new beam is magically created to cover them? At first glance, I'm not liking this idea as well and it's definitely way more complicated to implement.
To implement something like the command system on top of the current properties:
"Beam selected notes" would operate on a set of notes (list or range) and would set the first note in the group (and potentially the first note after the group) to "break beam left", and all notes within the group to "join". Setting them to join rather than leaving them as auto would mean it is now impervious to future changes you might make to the time signature defaults.
"Beam selected notes" would also work on a single note and just do the same thing that setting the "join beams" property does now.
A "break beam" command could also do pretty much exactly what setting the "break beam left" property does now and be simpler than having to select the sets of notes you want beamed instead.
A command to apply the "no beam" property to a selected note or notes would also remain extremely useful for exactly the same reasons it is now.
So what I end up with is the realization that this is almost exactly the same as the current system, with one important exception: how "join beams" works on a multiple selection. The current system is already problematic in that very often people make the mistake of selecting a full measure and then clicking "join beams" and are surprised that this applies to the first note as well and therefore joins the beam into the previous measure. So even without any new command, there is room for improvement here.
With all that said, I think almost everything one might want would actually be accomplished with one simple enhancement to the current system:
Modify the behavior of the current "join beams" property in the special case where a range is selected instead of setting them all to "join", the first would be set to "break". It could possibly be renamed to "beam selected notes" to make its behavior more clear.
Arguably it could also set the next note to break as I originally suggested above, but I'm not super convinced that's worth it.
Note multiple voices complicate everything further because ranges now include multiple beams at the same beat, and you'd have to be careful using this command.
agreed, updated handbook
"Editing beaming is a puzzle minigame - user cannot select a beam and edit beaming directly, a beam is derived from properties of two Notes/Rests, editing one Note/Rest property can affect two beams."
In reply to agreed, updated handbook … by msfp
That is completely inappropriate. The Handbook is not a place to make sarcastic critical comments on how you about the design. It is simply a place to explain how things work. I’m reverting your change.
In reply to That is completely… by Marc Sabatella
Let me correct the tone, how about this?
Editing beaming is akin to solving a mind puzzle - User cannot select a beam and remove it directly, a beaming is derived from properties of two consecutive Notes/Rests, modifying the properties of one Note/Rest can impact two beams.
In reply to Let me correct the tone, how… by msfp
No, please don’t. I’m in the middle of a more extensive rewrite of this page that I think should help clarify some of the confusion. This is a page I should have given more attention to as one of the primary editors of the Handbook, and it’s my responsibility to make sure it’s understandable.
In reply to No, please don’t. I’m in… by Marc Sabatella
Ok. Thank you very much. The current program design is indirect, but it's in fact not bad, because the simple logic allows creation of something similar to a "rhythmic grouping convention" - beaming of new notes added later are predictable. It is just not easy to explain clearly in short sentence, I think letting readers know about its indirect nature, like a puzzle game, helps set an appropriate expectation.
In reply to Ok. Thank you very much. The… by msfp
I think you are making it far more complex than it is. There is no puzzle, no game, no indirection. You just need to clearly understand what break & join actually do. I have done a first pass at a rewrite, but plan to go back and add images and further cleanup. My current version does have simple short sentences to describe these properties, no “indirect”, no “permissive”, no other strange buzzwords. Just short simple English sentences that’s clearly explain their simple purpose.
In reply to I think you are making it… by Marc Sabatella
I read the new page, wow, that is concise and very clear. Thank you so much for spending time rewriting it.
"To change the beam between two notes, you will normally start by selecting the *second * of the two notes, as most of the beam properties control the beam into a note." Such a insightful advice! I think readers will find the new page very useful.
I was always troubled by beaming as a beginner. Now I've learnt more, I suspect part of the problem may be due to the place where these buttons are displayed. Palettes items are usually understood as one-time commands, such as "clicking this adds a mf symbol" . However, the beaming buttons are not commands, they are properties. Also, both the hb3 and the old hb4 page explained the first button "AUTO" with a verb "reset", it is natural to be mistaken it was, and thus all of them were, one-time commands. These buttons are already present in "Properties panel". Would it be appropriate to suggest removing the palette? (you use "reset" in the rewritten page, I think it does not cause problem because the three bold "Properties" just above it emphasize it is a persistent property )
In reply to I read the new page, wow,… by msfp
Thanks for the comments! FWIW, I agree that it may be time to retire the "Beam properties" palette ("Noteheads", too). In my revision Handbook page, I mention the palette but focus on the Properties panel for the examples. Feel free to submit a GitHub issue requesting the palette be removed. Although I do expect some pushback on that, as people are accustomed to it and some may not realize the functionality is duplicated in the Properties panel.
I'm in the process of adding some images and other cleanup and will followup here when complete.
In reply to Thanks for the comments! … by Marc Sabatella
I am one of those who would push back on it. I know that the functionality is duplicated in the Properties panel, but I use the palattes so much more than the Properties panel that I feel like if the Beam Properties palatte is removed, that's going to result in a lot more back and forth clicks between the Properties panel and the Palattes. And those back and forth clicks waste time that wouldn't be wasted if I just set the beaming directly from the Beam Properties palatte.
The times that I use Properties are:
And relatively speaking, those actions combined are uncommon for me to do, though some are definitely more common than others(the play toggle and offset adjustment for example are more common than the text style)
Whereas I use the palattes for basically everything else that's not immediately done by keyboard shortcuts like dynamics, articulations other than the 4 on the toolbar, beaming, pedal markings, text markings like a2(made a custom palatte for such markings indicating instrument numbers since I quite often run into those, especially a2), arpeggio markings, tempo, time and key signatures, etc.
And this is the vast majority of my clicking action is going from one item in the palatte to another in the same palatte and going between palattes. There are certain palattes that I only open in specific circumstances(for instance, my custom instrument numbers palatte and orchestral scores) and others that I keep open for almost every single score(dynamics, ornaments, grace notes, and beam properties are the big ones here)
I know I might be in the minority here cause the classical music transcription I do is relatively niche among MuseScore users and I often try to match the beaming I'm seeing in the old editions for composers like Mozart for example, leading to me adjusting the beaming a lot more than other MuseScore users do, but that's my feeling about removal of the Beam Properties palatte.
In reply to I am one of those who would… by Caters
Thanks for your comments! I’m not sure the idea of removing the palette would be seriously considered, but I do get that it’s potentially one or two fewer clicks to use the palette if you happen to already have the palettes open. On the other hand, if you are doing this a lot, why would you be clicking at all? Any command you use often enough to care about the efficient of is better done by keyboard shortcut, and shortcuts can be assigned to all of these commands. Assuming you’ve set the defaults in the time signature properties, needing to override for individual notes wouldn’t be that common for most scores, but for the ones where it is, nothing beats keyboard shortcut.
Anyhow, classical music transcription is far from niche - it’s one of the biggest use of MuseScore, actually. So definitely we don’t want to do anything to make it harder. But given that using Properties it’s only harder if you happen to already have the Palettes open instead of Properties, and only if you happen to not actually use this often enough to have a keyboard shortcut defined, and given that most beaming is better handled through time signature properties anyhow, I’m not so sure that efficiency will end up being the deciding factor.
I think the more important consideration is going to be, since having this on the Properties panel is relatively new, many users are accustomed to using the palettes and don’t even know there is an alternative. So if the palette is removed, suddenly millions of users will wonder, where did it go, and we’ll be flooded with supported questions.
But if turns out enough others users express concerns over efficiency, and usability testing shows it truly is less efficient for some common real world use cases, then of course that would be considered as well.
In reply to Thanks for your comments! I… by Marc Sabatella
I actually didn't know you could set keyboard shortcuts for beaming, I thought it had to be done by clicking. I do have some time signatures set to specific atypical beam patterns in my time signatures palatte cause of how often I run into them(such as 3/4 Beam Together where I have all 6 eighth notes in 1 beam) or because specific pieces use that beaming a lot and I want to be prepared in case I run into another piece with the same beaming(5/4 as simple meter(i.e. no 2 + 3 or anything, just 5 pairs of eighth notes)) in Chopin's C minor sonata for instance or 1 + 3 2/4 beaming in Beethoven's Fifth), but even so, I still often have to adjust the beaming to match the score I'm looking at in at least some measures. Especially in 2/2 where I most often see beaming identical to 4/4 in the score regarding composite rhythms of eighths and sixteenths(i.e. breaking the beam at the quarter note), but MuseScore doesn't do that by default.
Another common situation in which the beaming I see in the score is often different from the MuseScore default is sixteenth triplets(in most of the scores I look at, the eighth beam is broken for each triplet) and 32nd note runs(Sometimes seeing the eighth beam broken per group of 4 requiring Break Beam Left and sometimes seeing beaming in groups of 8 at all 3 levels requiring Join Beams).
But yeah, didn't even know that keyboard shortcuts could be assigned to adjust beaming.
I have updated the Handbook page for beams to hopefully clarify the behavior. I also did some reorganization of the page, added new images, etc. Please take a look and see what you think. Let's discuss any further changes here before actually going ahead with editing. When it seems we have enough consensus, I will flag the page for translation.
In reply to I have updated the Handbook… by Marc Sabatella
Very nice work.
Some suggestions :
[A] In the example(s) it would help to have 3 screen captures instead of 1:
1) Score as it is before changing the property with the exact note for which the property will be changed highlighted.
2) Then exact property being set
3) And finally score as it is after changing the property
[B] More info on the fact that property no beam beats any beam property of the right note, so if a note isn't beamed to the one to the left, changing the property of the right note is sometimes not enough
[C] Examples for beam inner 8th and/or inner 16th would be great
In reply to Very nice work. Some… by frfancha
C) makes sense, thanks for the suggestion. You really don’t think the icon itself shows this clearly enough, though?
For A), which other examples do you think are not sufficiently clear that they would be improved by more pictures? I find more pictures just makes the page look more cluttered and more confusing than necessary unless there is something very non-obvious about the single picture.
For B), I don’t understand what you mean. I already state very explicitly that the beam properties mostly affect the beam into the note. i am also very explicit that “no beam” is the exception, in that it also affect the potential beam out, and I reference this fact in the “join beam” command as well which is the only other property specifically affected. What info do you feel is missing?
edit: "Beam middle" on musescore 3.6.2, not "Middle of beam"
I've just backported Mr. Sabatella's brilliant article to handbook3. I noticed ms3 used "Beam middle" wording for the ms4 "Join Beam" item. I think the former probably works better at avoiding confusion.
@Caters You've got a point, palettes definitely got a role in accessibility, esp when toolbar customization is quite lacking.