Changing beams
I regularly have difficulty with this despite reading the handbook carefully. It seems to be a topic for which the Musecore approach is counterintuitive for me. The concepts, in particular the meanings of the beam symbols presented in the handbook, are hard for me to grasp.
Perhaps an example will illustrate. I have 4 quavers that have been beamed together. I would like the first and last notes not beamed but the middle two to keep their beams. How can this be done easily? The way I try is: pick the second note and break its beam to the first - this works. Now pick the third and break the beam to the fourth - can't do it. Instead I have to pick the fourth and break its beam. Why?
Suppose I unbeam all 4 notes and now try to beam the middle notes. How can this be done easily? I pick note 2 or note 3 and click the first beam symbol - nothing happens. I need to add beams to notes 2 and 3 successively and I need to remember the beam settings for each note since they are not shown in the score. I find this very hard to do and to remember.
I would really like to see a detailed tutorial on this subject which explains the concepts and procedures better than in the handbook.
Comments
There's https://musescore.org/en/handbook/3/beams and https://musescore.org/en/handbook/3/time-signatures#change-default-beam…
See also https://musescore.org/en/node/284855
My preferred method for what you want it to apply the "no beam" to the first and last notes. I know you didn't mean quarter notes since they don't have beams, but it works for anything with a beam.
What you tried to do is illogical. You have already seen when you select the second note and break the beam (presumably using the "start of beam" icon), it's the beam back to the first that gets broken. The rule to have learned from this is, breaking the beam on a note breaks the beam back, not the beam forward. Which makes sense, because the beam is even called, "start of beam". You said you want to start a beam with the second note, and that's what you got. So, why would you then try to do the same to the third note? That doesn't make sense. If you've now learn the "start of beam" button honors its name and break the beam to the previous note, the correct note to have selected is the fourth note.
Of course, you don't literally want to start a beam there, so probably better to use "no beam" there, but "start of beam" won't actually force a beam to be created if one wouldn't have been otherwise. It merely does what you have already seen it to do - it breaks any beam that existed to the previous note.
Thank you all for the answers, I think I now understand how things are supposed to work. I could do things in a way more natural to me if there was an icon which reverses the first "no beam to the left and offer a beam to the right" icon. I need one which is its mirror image and says "no beam to the right and offer a beam to the left".
In reply to Thank you all for the… by Neil Whitton
As you noted MuseScore does it the other way around. The continued beam is offered to the right with no option to end at the current note. Always keep in mind, if you want to start a new set of beams, select the icon that says Beam Start.
My initial thought was that a "Beam end" icon is not needed, but it does make sense to me and would help with some of the problems I've seen. I'm not sure how MuseScore does this internally so it remembers which beam you have set (this may make it impossible before version 4), but adding this option is a good idea and would eliminate confusion for other users I've seen as well. Feel free to make a suggestion in the issue tracker. Set the severity to S5-Suggestion and leave the other fields to their defaults.
In reply to As you noted MuseScore does… by mike320
Internally, decisions about beaming two notes are not made until seeing the second note, which is why there is only a beam start or no beam - a beam end on the previous note would not accomplish anything you couldn't do with one of those. But, it could indeed be a more intuitive way of specifying the same information (beam end on first note is interpreted as meaning the same as beam start on next). You would have to consider how to handle conflicts (eg, beam end on first note, beam middle on second). Maybe actually the "beam end" icon would be for the palette only, what it would actually do is set "beam start" on the next note. This would also avoid compatibility issues.
In reply to Internally, decisions about… by Marc Sabatella
There are no conflicts having a beam end option that don't exist with the current options. If the user selects beam end, it will never allow a beam to the next note, just like the current beam start (or no beam) will not allow the beam to be extended from the previous note, even if it is set to beam middle. In my tutorial I explain it as a cooperative decision between the two notes weather a beam is allowed. A beam only happens if both notes agree there should be a beam.
As I said my initial thought on the subject was that it is totally unnecessary because it doesn't add any new feature. The intuitive nature of it made me rethink that. When I said I'm not sure how they are internally stored I was thinking about how it ends up being entered into the .mscx file and how MuseScore remembers that the user selected no beam rather than start beam so the last note in a group of 8th notes will not be attached to the previous note. You get the same results in either case, until you make the next note an 8th note, then it gets beamed only if you set that note to start beam and the next note is middle beam (to include subs). It doesn't only remember that it doesn't beam to the previous note, it remembers if it can beam to the next note, even after a save.
The beaming algorithm will absolutely need to be changed if this were implemented but it would not affect previously made scores, only the new scores might confuse older versions of MuseScore 3.x. Which is a great concern.
In reply to There are no conflicts… by mike320
Right, so what about my idea of having the beam end be a new command that actually simply sets beam start on the next note? Then, no compatibility issue. Downside - the beam property is actually attached to the next note, so it gets clobbered if the next note does. But that might be worth it to not break compatibility. Also, it wouldn't work to use this before entering the next note, for the same reason, unless we maybe just remembered you had done that while in note input mode and then applied it when you do enter the next note. Kind of sort of like "slur mode".
In reply to Right, so what about my idea… by Marc Sabatella
simply sets beam start on the next note
The problem with this is that if the user says oops, I meant middle beam not end beam and sets the note to middle beam the next note has already been set to start beam and will not allow a beam to be attached to it. This would be an obvious bug that would have to be addressed or explained repeatedly in these forums. I say the status quo is preferable.
In reply to simply sets beam start on… by mike320
Good point, never mind on my suggestion then :-)
In reply to Good point, never mind on my… by Marc Sabatella
But the real problem is telegraph poleitis. (Sometimes known as the "interval arithmetic" problem.) Really, a beam is something in the interval between two notes, and all you want to do is select a bit of beam (i.e. the interval between a pair of consecutive notes), and set it to be there or not be there. But this requires flexibility in the way that selection words, and in the absence of this flexibility it is always going to be a bit counterintuitive. Just as a time signature goes on a barline, but you have to select the bar [before/after], while a page break also goes on a barline, but you have to select the bar [before/after]. And there is no consistency.
In reply to But the real problem is… by Imaginatorium
It is basic boolean arithmetic to decide if a beam will be present, but that is less clear to most people so I use my cooperation explanation. It doesn't even resemble a time signature or barline in it complexity as to if it is applied to a given space. These are binary - a simple yes or no.
In reply to It is basic boolean… by mike320
For mathematicians (like myself) using the spaces between notes would be the most obvious method but you are right, it is probably not how most musicians see it. Except perhaps in India, since the patterns of rhythms in Konnakol are just all possible shapes. For n notes in a group there are 2^n -1 shapes with beams. Putting 1 or 0 in the spaces and intertpreting as a binary number assigns each shape a unique number between 1 and 2^n -1. The shape with no beams can be assigned n zeroes. (This can be extended to a note-based system but then the note needs two numbers left and right and a combination rule to obtain the numbers in the spaces. So it is more complicated.)
@Neil Whitton... You wrote:
I need to remember the beam settings for each note since they are not shown in the score.
With the 'Beam Properties' palette open, you can click on a notehead and its beam setting will be shown in the palette.
Regards.
In reply to @Neil Whitton... You wrote:… by Jm6stringer
Thanks, right enough.
I have left this topic for a bit in order to think myself about all the possibilities and to have a look at how some other software does beaming. (They all seem to do it differently, some do have beams from the right). While it seems that the current icons are sufficient, the concept (from the left) still seems restrictive. Mirror images (from the right) would be quite natural as well (and would also suffice). So I would still like to see consideration of a more flexible system - obviously provide back-compatibility is retained. This is quite a big issue for vocal music: often an accompaniment has standard beamings while the soloist does not, since they beams may not fit the text. I notate a lot of folk music in which both vocalist and instrumentalist can be rhythmically free and it is good to put beams in or out for each as is helpful. Editing the beams in such pieces is at the moment very time- consuming.
In reply to I have left this topic for a… by Neil Whitton
There are absolutely no restrictions on beaming, it's simply a matter of understanding the beaming.
To add to the flexibility, you can create "Vocal time signatures" if you like in the time signatures palette. These would default to having notes not beamed. You can ctrl+drag the time signature to your vocal parts. If there are more vocal parts than instrument parts you have the option of applying the vocal time signature to the score and then applying a "standard time signature" (not one you created for vocal parts) to only the instruments using the same ctrl+drag method.
The only question then is how to distinguish the two times signatures. Put the vocal ones in a different palette. See https://musescore.org/en/handbook/3/workspaces#create-custom-workspace and https://musescore.org/en/handbook/3/palettes#custom-palettes if you need more info on custom palettes.
One nice thing is that MuseScore will recognize these as the same time signatures and there will be no issues with local time signatures. If this doesn't mean anything to you don't worry about it. If it does mean something you will appreciate this very much.
In reply to There are absolutely no… by mike320
I meant restrictions on the way it is done, but never mind, I appreciate your explanations and have understood. That does sound like a useful workaround.
In reply to I have left this topic for a… by Neil Whitton
For beaming vocal music specifically, have a look at this plugin: https://musescore.org/en/project/traditional-vocal-beaming
In reply to For beaming vocal music… by jeetee
Thank you, looks useful, I will try this out. Good to see that others understand the need. My feeling is that most notation software (except Capella) has the needs of singers and non-classical musicians rather low on their list. Putting in text for songs is usually something of a nightmare - Musescore actually does this pretty well but editing lyrics is really difficult (I understand that this is a diificult problem but if only one could do Copy-and-Paste more easily).
In reply to Thank you, looks useful, I… by Neil Whitton
Feel free to start a new thread explaining the difficulties you are having with copy and paste. That should actually work just fine too.