No automatic beaming (for vocal scores)

• Feb 18, 2010 - 15:15


In vocal parts, the notes beaming has to follow pronunciation. In facts, it means most of times that the notes don't to be "beamed" because there's a syllable on each of them.

So, I think automatic beam should be "deactivable" for this kind of use (like "pitch spelling" at score level).

Thanks for this great job !


This is an old style of beaming so I don't think it should be default (modern scores follow instrumental beaming and slur melisma notes). However it would be nice to have a plugin that implemented either style.

For cross reference, here's a similar request on the French forum:

If you have a teacher telling you that vocal scores should be this way, I'd be very skeptical of this person's attitude. That tradition was eliminated long ago. Beaming is far better for indicating rhythmic interpretation and making it visually clear. Slurs are used today for syllables that cover more than one note. It's not just an issue of standards: if you want someone to have the most success at reading your vocal music, it will be best if you beam according to the same standards as instrumental music, period. No professional engraver / publisher today would do the all-un-beamed vocal style.

In reply to by xavierjazz

clear statement for professional. I mean professional singers, who are able to "read the music", which is the case nowadays, at least in classical music.

But, there is a lot of people, especially in choirs who don't "read the music". They read the lyrics, and rely on the choir director, and on the few among them who read the music.

In this case, when I prepare a score, I stick to lyrics, including cutting measures at the end of a system in order to keep unaffected a whole lyrics line. Melismas are given by a long underscore on the lyrics line, Upbeat are clearly shown in the score, and so on......

Maybe I'm not always coherent, because some scores are more "for non-educated people" and others for "educated ones"....and the other sings just by imitation....

So any possibility to freely choose editorial ways will find supporters

In reply to by robert leleu

I agree that it is best for MuseScore to be able to work however people want it to work.

But I mostly disagree with your idea that professionals versus beginners will have really different scores. There are some obvious learning-related things like having note-heads that show the letter name or solfege (a potential font request), but most things are not different. Despite the common standard, you are right that cutting measures to keep phrases clear per line is better, but that's PERIOD. That is arguably better for ALL singers, professionals alike. Melismas are always given by the long underscore in vocal lyrics, so that is standard and there is no difference for professionals or amateurs. While I'm not sure what you mean by "upbeats are clearly shown," BOTH complete beginners and professionals will find rhythms easier to comprehend when they are beamed!

My point is simple: if a choice makes reading easier, it should be done for everyone.

On the other hand, if you think something is easier at first but it is SO different from standard that it would really screw up anyone who already reads well, you shouldn't do that for anyone because it will hamper beginners' ability to learn to read most music. (I'm don't think anything you've mentioned fits this description though).

In reply to by wolftune

I agree with you, and slight discrepancies are probably due to our different native languages (do you speak French?)

Just on the last topic: There is quite a lot of people (generally more than 30 years old), who definitively think that reading notes is not for them, but however are happy to sing. So are, unfortunately for me, most of the people for which I type choir scores.

In reply to by wolftune

I've just got Bach Cantata score released last year (new edition) which uses detached notes on each syllab.
It seems to be usual even nowadays in classical music scores...

Regardless, I think more flexibility is always a good thing (men -even musicians - are so versatile)

In reply to by wolftune

I find that difficule to believe. I have NEVER seen a professionally published vocal score that used beams on the vocal lines the same as the instrumental lines, and I have been singing for over 50 years, and I do read music. But, then, I don't sing much modern music. I hear a lot of people who say that singers generally can't read music, but very few of the singers I have know have been unable to read music. What is true is that very few of them know how to sing by sight... but they can sit at a piano and pick out the melody.

And what in the world do BEAMS have to do with being able to read music. Anyone who can count doesn't need a beam to show him where the beats are.

I would be in favor of being able to disable automatic beaming because I spend a LOT of time undoing it in all of my scores.

In reply to by Casa Erwin

The *option* to remove beams or choose that default is perfectly sensible simply because users should be able to do what they want. That said, yes, *older* scores used to do the *inferior* approach of beaming only for slurs. Anyone *can* learn to be comfortable with the inferior approach, but modern scores recognizing that beaming that fits the meter is superior in that it does in fact make the music clearer. The contemporary standard for vocal music is indeed to have the beams the same as for instrumental music and use slur lines to indicate slurs. I was not saying anything about this particular issue being a matter of

"Anyone who can count doesn't need a beam to show him where the beats are" is a misguided comment. Need is not the same as whether something is better or worse. Hundreds of years ago, multi-part scores didn't space things out so that they vertically lined up. You had to do all the counting to compare the parts and figure out what lined up. You might as well say "anyone who can count doesn't need barlines to show him where the measures are." The fact that multiple approaches can be usable doesn't mean they are all equally good.

This is a case where older music used a certain tradition. Now, the standard has changed. The change itself can be a little harder for people used to the old way to get used to, but it's an improvement, though subtle.

In reply to by Casa Erwin

There are different types of vocal scores. In hymns and certain other choral styles, not beaming is common, but in many other styles of music (pop songbooks, etc) the beams are common and expected.

Beams help with reading rhythms quite a bit if the music is rhythmically complex. Consider a measure with a mixture of sixteenths and eighths. These will be beamed to make each beat clear, so it is obvious at a glance which note falls on which beat. That information is not immediately apparent when beams are absent, meaning if somethng goes wrong early in a measure, you are likely to be off for the rest of the measure rather than being able to correct the error on the next beat. And if you are accustomed to seeing beams, you won't make as many errors in the first place, because there are only eight possible ways to put sixteenths and eighths on a beam - so only eight patterns to learn. Whereas without beams, there is no easy way to reduce things down to those eight basic patterns, meaning you cannot use pattern recognition to help you get the rhythm right. It becomes a more laborious process of counting each sixteenth note rather than immediately recognizing the rhythm. So it really does end up leading to measurably more rhythmic reading errors. Of course, after spending enough time with the music, one will be able to learn the rhythm either way, but the beaming really is very helpful in sight-reading.

Anyhow, as has been explained, if you prefer not to have beams, simply select all and double click the "no beam" icon, or do so in the Time Signature Properties.

In reply to by wolftune

The idea that this style was “eliminated long ago” just simply isn’t true, nor have I ever seen a piece of vocal music from the higher end publishers without syllabic beaming. If I’m being 100% honest, based on what I see in the engraving world, the idea that this is a letter of old or new styles “no longer being in use” seems like nothing more than an excuse not to fiddle with the beaming propers in the engraver to me. That may not be the case at all, but it is what seems apparent from my every experience with vocal music and engravers.

In reply to by James Markham Scott

Indeed, the older convention is still followed when engraving older music specifically, or occasionally modern music in older styles. But if you say you've never seen a piece of vocal music from the higher end publishers that doesn't use syllabic beaming, I'm guessing you are mostly familiar with older music, because the modern style really is more common in modern music. As a random example, here is an excerpt from a modern score from a major composer (Eric Whitacre) and major publisher (Boosey & Hawkes) showing the modern style:

Screenshot 2022-08-14 10.43.59 AM.png

Anyhow, the traditional vocal beaming plugin does work very well in my experience, does the job quite simply and accurately.

Here's an excerpt of a review of Elaine Gould's "Behind Bars" from a leading German music periodical "nmz":

Erfreulicherweise handelt es sich dabei nicht um eine reine Übersetzung aus dem Englischen, sondern vielmehr um eine gekonnte Übertragung des Originals, die [...] auch auf „deutsche“ Notensatztraditionen eingeht [...]. (Beispielsweise die hierzulande in der Vokalmusik traditionelle Verwendung getrennter Fähnchen für jede Silbe und von Balken bei Silben über mehrere Töne.)

Roughly translates to:
Fortunately, it is not a pure translation from English, but rather a skillful interpretation of the original that [...] also deals with "German" music engraving traditions [...]. (For example, the tradition in this country to use separate flags for each syllable and beams for syllables over several notes in vocal music.)

I hope we'll be able to stop this completely useless discussion about what's inferior, and we can just stick with: Different people do it in different ways. Thank you.

In reply to by heuchi

The discussion of which standard is inferior or superior is not 'useless' at all...but it IS misplaced. The question is more of a historico-cultural one than a simple question of production, so it doesn't really belong here, interesting though it might be in another venue.*

A graphic system or program which makes users jump through hoops and devise elaborate work-arounds to realise the graphics the way they want/need (for whatever reasons) is a poor program. MuseScore, we can be thankful, offers a way to turn off automatic beaming and revert to the 'old-style' (or 'German style,' or give it whatever name you like); it also offers, since 2.0, score-wide control of beaming settings, which is a great improvement over the note-by-note control offered in 1.3. That said, I would suggest that the point is moot for the purposes of production. Whether a particular user wants to produce flagged or beamed vocal music, MuseScore allows him to do either.

*Note: There exists NO really definitive standard for this sort of thing in the music publishing industry. The ACDA, in collaboration with the MPA, attempted to resolve this question (and many others) quite a few years ago, but because of differences of opinion among the committee members, consensus (and industry-wide adoption) was never achieved. See… for an interesting 2013 doctoral thesis on the history and results of these efforts.

For anybody interested in this kind of beaming:

I've just created a plugin to set the beaming according to syllables.

I only tested it for a few cases, so there might still be problems. Save your work before trying it.

In reply to by Nicolas

I think so. But I have never added anything to the UI and don't really know how to do that. Is there some hint you can point me to, how to do that? (Specifically how to edit .ui?)

I implemented the actual behaviour in 518ebb42

I think I'd rather not gray out the time signature beaming properties, because the user would still be able to change the grouping.

One more thought:
I'm not so sure this should go into the time signature properties, because one would have to take care of this for every time signature change.
What about putting it in the staff properties. Since it would probably be used throughout the whole score.

In reply to by heuchi

In a score with mixed voice and instruments, it would definitely be for the vocal staves only. So making it a globa style option would not work.

On the other hand, this strikes me as another argument in favor of allowing staff-specific style settings in general. Default position of dynamics and hairpins is the main other case I know where we would often want a staff-specific override - to place the above the staff for vocal staves, or closer to the staff for 1-line staves (eg, percussion), further for 6-line staves (eg, tablature), but I suspect there would be other style settings where someone somewhere might want to override on a per-staff basis. Although I guess some style options don't make sense to be per-staff (eg, the Page options, also Header & Footer, etc).

I suppose rather than trying to allow *all* style settings to be per-staff, though, we could just have specific overrides in Staff Properties. But anyhow, I think we should have a consistent way of dealing with this for whatever options we chosoe to support.

In reply to by Marc Sabatella

So making it a global style option would not work.
Well except if the style property is "use lyrics for beams in staves with lyrics".

Adding styles for staves, on top of the existing staff type properties (no clef, no key sig etc...) would make the UI and the concepts in MuseScore even more complicated. So it needs to be done carefully...

In reply to by Nicolas

@lasconic--Understood about avoiding additional complexity in the UI. A few random ideas have popped into my head which might be worth considering:

I think the simplest way to offer control of beaming for vocal parts would be on the EDIT STYLE>Beams dialogue. Add a checkbox to that dialogue which states, "Disable beams for vocal staves" and then link that instruction to a similar checkbox which would appear by default on the the Staff/Part Properties dialogue of all vocal staves. Checking or unchecking the box in either place would apply it in the other, and would force the use of flags rather than beams on all note values smaller than a quarter. Vocal parts would have to contain a code/flag or something of the sort to tell the program to apply that instruction to them; other instruments would not. The user would not see any additional level of complexity; that would all be below the surface of the UI.

Exception control of beaming--per note group, set manually as a one-off exception to the parameter--could be allowed by using the beam palette in the usual way.

But Marc has pointed out the importance of a wider perspective--the ability to make local/staff-only changes to ANY style parameter--so here are afew thoughts on how that might be put into the UI without making it more complex:

Place a new button ('APPLY TO SELECTED STAFF ONLY') on the EDIT STYLE dialogue panel in the 'execute' group at bottom right. If the user has not previously selected a staff, when he clicks that button he will get a pop-up warning: "No staff selected. Please select a staff or group of staves and re-try the operation.' When this choice is made by the user, a checkbox on the "Staff Properties" dialogue for that staff would be automatically checked.

Or, just use a checkbox on the EDIT STYLE dialogue instead of an 'execute' button. If that is checked when the user clicks APPLY, APPLY TO ALL PARTS, or OK, he gets the same pop-up warning.

With either of these methods, all changes to any style parameter could be applied to one or a selected group of staves. Thus, if a user wished to create one staff with uniformly different offsets for hairpins, voltas, and ottavas, for instance, he could do so. Granted that many elements don't need (or could not reconcile) different settings on different staves in a score, but for those that do/could, this extra level of control would be a boon to the user who currently finds himself manually adjusting things one by one using the inspector.

It would be necessary for this 'apply style locally' instruction to cause the selected staff/staves to be exempted from any subsequent global changes made to the same style parameter, whatever the method used in the UI. A pop-up warning could advise the user that 'These changes will not apply to [instrument/staff name/number]. To apply them globally, please uncheck the "Apply locally" checkbox in "Staff Properties."' (That popup could contain the courtesy option, 'Do not show this message again' or 'Only show this message once after each re-start of MuseScore.')

In reply to by Marc Sabatella

this strikes me as another argument in favor of allowing staff-specific style settings in general.

A big +1 on that. It's convenient to be able to change style settings globally most of the time, but it is very frustrating when one needs to change them locally...and cannot. :o(

In reply to by Marc Sabatella

I'd vote for a score wide but staff dependent solution.
I also strongly support Marc's idea about dynamics and hairpins for vocal staves.

One more note on naming this feature:
I'd not call it something like "No automatic beaming" or "Disable beams for vocal staves" because depending on the lyrics there might still be beamed notes.
Lasconic's "use lyrics for beams in staves with lyrics" is more adequately describing the functionality.

In reply to by heuchi

"use lyrics for beams in staves with lyrics" is more adequately describing the functionality.

I disagree with this approach for two reasons.

First, that would appear to make the beams dependent upon the manner in which the lyrics are input. (I can't imagine any other way the program could distinguish what is a syllable and what is a word....)

But the problem is that there is as little agreement in the music world about whether to flag or beam as there is on what sort of extender to use between what sorts of syllables. Some editions use baselines for everything; some use them only for terminal syllables of words; some use them only for melismata.... So what's a modern editor to do? To paraphrase a fairly well-known writer of some years back:

To Beam, or Not to Beam? That is not the only question
Whether 'tis nobler in the score to suffer
The dashes and baselines of inconsistent editors,
Or to take arms against a sea of discord,
And by opposing end...what?

To think: perchance to create one's proper style: ay, there's the rub


The second reason is that I see this 'use lyrics to define beams' as a much more complex instruction, fraught with exceptions and conflicts, which would probably be a great deal more difficult to realise than just turning off beaming for a selected staff. In my suggestion, I allowed for the possibility (probability, is more like it) of needing to tweak the score manually once it's done to take care of exception-cases, but there should be few exceptions needing tweaking, and that is the sort of thing human editors can do more easily and with better accuracy than a literal-minded program.

In reply to by Recorder485

The reason I wrote this was not to discuss the functionality, but to clarify what my plugin is doing and for which Lasconic was asking if it could be done in the core. To do this, the program does not need to distinguish between a syllable and a word, and it already seems to work fine.
Maybe you want to look at the plugin page for an example.

The problem that has come up now is not about the functionality itself, but rather where to place an option in the UI.

In reply to by heuchi

I apologise, heuchi; I somehow lost track of where this thread had gone and forgot that you had written a plug-in. I was still thinking about a possible modification to the program for a future version. My remarks were based upon that perspective.

Please correct me if I'm mistaken on any of these points, but it seems to me plug-ins are not usually enabled through the properties dialogues in the UI. My understanding is that if I want to use a plug-in, I need to choose to run it (on a completed score) from the Plugins drop-down on the main menu. Is it correct to think that if your plug-in was run from a checkbox or button in the GUI, it would have to be a part of the main code, and not an optional add-on that has to be installed separately from the version of MuseScore the user is running? Not sure I'm using the correct terms here; please bear with my lack of expertise in programming lingo....

I see that there are some default plugins that come with the software in the 'Plugin Manager' drop-down. Is this where you envision seeing your plugin listed?

In reply to by Recorder485

If you wish to use some non-standard beaming, you shoild probably not use the proposed option. But actually, there really is a pretty well-established standard for how this should work, I think. All published references I have seen on the subject agree on the basics of how hyphens and underlines work, even if a few editions here or there use some different approach. We already rely on this common standard to decide which syllables to center and which to left-align. Extending it to also influence beaming is no big new can of worms as far as i can see. Again, if you wish to use some non-standard beaming, simply don't use that option but instead continue to do things manually as you must now.

In reply to by Marc Sabatella

What about closed score SATB, with lyrics between staves and attached to top staff.
As then there are no lyrics attached to bottom staff, this would not beam the same way.
So maybe we'd need some way to mark a staff as being vocal?
What about voices, same Problem there, lyrics are attached to just one voice, so we may end up with different beaming for voice a1 and 2

In reply to by Jojo-Schmitz

About closed SATB: I had hoped for the closed SATB template to consist of only one part, so the plugin could know which staves to look at. But this seems not to be the case.
So we'd really need another option here.

About voices: My current approach does not try to match stanzas to voices. A syllable change in any of the stanzas will affect all voices of the staff. This will of course not always generate the desired result, but it should provide a better start to do some manual tweaking where needed. I thought about the problem, but I think matching stanzas and voices is quite complicated. There are so many different use cases.

Do you still have an unanswered question? Please log in first to post your question.