Perplexed by Join Beams

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?????

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.
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.

I've given a little thought to how a command-based system might look. As I see it, one would want:

• a command to say "beam these selected notes", breaking any existing beams into or out of the group
• a command to simply join a beam, so you don't need to select a whole range just to do that common simple thing that the current system handles well
• a command to simply break a beam, same reason
• a command to ensure a given note or group of notes is not beamed at all

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."

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.