Beam properties

• Feb 21, 2019 - 19:27

Can anyone understand the logic to beam properties who don't, like me, just click and get frustrated and then somehow we get what we want?


Comments

In reply to by Jojo-Schmitz

Thanks but the manual does not match experience. A have a 6/4 bar and need to group 12 quavers in three groups of four. According to the manual, I should be able to say which of those quavers start a beamed-group, are in the middle of a beamed-group, and end a beamed-group, but it just doesn't work. Any help would be much appreciated.

Beaming is a cooperative effort between notes and rests. Yes, beams can be applied to rests. The word "Note" below applies equally to notes and rests.

No Beam - The note will not connect to any other note
Start beam - The note is willing to attach itself only to the next note. It will not connect to the note before it.
Middle beam - The note is willing to attach itself to either the note before or after. This applies to Beam 16th sub and Beam 32 sub as well.

If the two consecutive notes are willing to connect to each other they will beam, if one of them is not willing, the two notes will not beam.

Auto - The beaming pattern defined in the time signature will be applied to the note.

By default, all rests are set to no beam, so they will not beam to notes. If you change the beaming on a rest to auto the rest will follow the definition in the time signature as though it were a note.

Thee are three bugs I'm aware of that are important. In version 3.x up to 3.0.2 you cannot have a beam cross a bar line. Also in version 3.x, if you use cross-staff notation on a group of beamed notes, the beam will be displaced vertically (up or down). In version 2.x, a beam that crosses a system break will be will be displaced to the beginning of the system.

In reply to by mike320

Thank you. I had to select all, then turn them all to Middle Beams, then select the first of each four and set those to Start Beam. What I was failing to do was to select all notes in the chord that started the four, rather than just the one of the notes. Got there in the end. Thank you to everyone for such a fast and supportive set of responses.

In reply to by julianpinn

Also, Mike, your description is far superior to the one in the manual where the description for Middle beam is incorrect. Yours is correct. Thank you again.

Beam start: Start a beam at this note (or rest).
Middle of beam: Do not end a beam at this note (or rest).
No beam: Do not beam this note.
16th sub beam: Start a second level beam at this note.
32nd sub beam: Start a third level beam at this note.
Automatic mode: Apply default beaming as determined by the current time signature.
Feathered beam, slower: Start feathered beam to indicate gradually slower tempo.
Feathered beam, faster: Start feathered beam to indicate gradually faster tempo.

In reply to by Jojo-Schmitz

That's not my experience of how Beam middle behaves. I had a 6/4 bar (measure) full of quavers (1/8th notes), so 12 of them that were not behaving as I wished. I simply selected them all, made them all Beam Middle, which joined them all up, then selected the first of each desired group sequentially and made each of them Beam Start. That was the only way I could get that 6/4 bar to behave and that was against the description in the manual and perfectly as described by Mike320, "Middle beam - The note is willing to attach itself to either the note before or after. This applies to Beam 16th sub and Beam 32 sub as well."

In reply to by Jojo-Schmitz

A beam can start on a note with a middle beam if there is no beamable note before it. This actually happens quite a bit when you have a 4/4 song with two groups of 4 8th notes defined like the default, then start the measure with an 8th rest followed by consecutive 8th notes.

In reply to by julianpinn

The description in the manual before it was "fixed" by Jojo was concise and accurate. Perhaps there needs to be a comment that indicates that beaming is determined by two consecutive notes/rests.

See what you think about the change I made to the manual.

I would add to this my experience that if a score was imported from XML, even long ago before it was imported into MS2 and then MS3, beamings and stem directions are imported will be assigned to notes, and will resist your subsequent attempts to deal with their surroundings. In specific, all "auto" beaming will be defeated. If beamings and stem directions seem not to concur with the wonderful belongs-in-handbook stuff just posted here, that may be the reason. The solution to that is to "erase" all explicit beamings by marking the whole score and clicking "auto", and then begin again imposing your specific needs.

I have opposite problem. I laboriously copied a score in an old book that had all sixteenth notes individually rather than beamed together. Now I want to beam it by beats. I want to get groups of 4 sixteenth notes to make reading easier. I selected 4 separate notes and double-clicked the appropriate beam on palette, but nothing happened!

In reply to by julianpinn

No, that is not the same
You can open a MuseScore 2 score with MuseScore 2 and 3 and even at the same time.
You can't open a MuseScore 3 score with MuseScore 2 though.

I have MuseScore 1.3, 2 3.2 and 3.0.5 installed and use them all (1.3 only occasionally nowadays).
MuseScore 3 for new scores and larger changes in older ones, 1 and 2 for smaller changes in scores from those versions

In reply to by julianpinn

If you edit a version 2 score in version 3 and then save it, you have turned it into a version 3 score and you will not be able to open the edited score in version 2. If you do not replace the version 2 score it will still be there. you have to force Musescore to replace a version 2 score with a version 3 score. By default, it tries to put the version 3 score in a new location and then warns you if you navigate to the version 2 location and try replacing an existing score with an edited version 3 score.

Keep your version 2 & 3 scores separate to avoid compatibility problems.

In reply to by julianpinn

On a score by score basis decide which version you want to use. There is nothing wrong with having both a version 2 and version 3 score. At some point you are going to move completely to version 3, maybe even starting with version 3.1. At that time, all of your new scores will be version 3. If you want to take advantage of a version 3 feature, then save the old score in version 3, otherwise only edit the score in version 2. There's no reason to convert every score from version 2 to version 3 if you're happy with the version 2 score.

A lot of us have both version 2 & 3 on our computer and shortcuts to both on our desktops so we can run both at the same time as needed. I've been using version 3 since last September when the Alpha was released. If I have a score I don't remember if it's in version 3, I look for it there, then use version 2 if I don't find it.

In reply to by mike320

This is exactly what I do. We're in complete agreement. However, it's a very unsatisfactory situation to have to juggle two versions of what's supposed to be the same app. It's free, it's really powerful, but someone's really messed up with the debugging of version 3.0 publishing it before it's ready.

In reply to by mike320

That's really encouraging. I really wish companies, even with a freemium model, would do proper alpha and beta testing before publishing their bug-ridden Vx.0s. Yet we're still here as fans, so why should they behave differently! By and large I'm very impressed with Musescore but fingers crossed 3.1 fixes the show-stoppers.

In reply to by julianpinn

And that someone's really messed up with the debugging of version 3.0 publishing it before it's ready is all of us, the entire comunity, there have been develeopment builds, Alpha and Beta versions, 6 releases (3.0-3.0.5), 2 further Betas (for 3.1), all available for anyone to test and report problems on.

In reply to by Jojo-Schmitz

Interesting. I wasn't familiar with how the alpha and beta testing is done by MuseScore. Normally, alpha should be in-house only, and beta is then to a select bunch of users that are kind enough to assist, and then publish. V3.0 to me seems not fit for even beta testing and is still very much part way through alpha.

In reply to by julianpinn

The house for MuseScore just isn't big enough for it to sufficiently test any pre-release (most developers are volunteers), so they post info here in the forums requesting people to help with testing. Maybe a few hundred people actually test and far fewer of them actually report problems in the issue tracker, though from Sep '18 - Jan '19 (the testing period) there was a huge increase in the number of issues reported compared to times when there is no alpha or beta release. Once the 3.0 release was made official on Dec 24 '19, the number of bug reports continued at a high rate and a lot more people were talking about MuseScore in the forums, as can be expected. This is the point where the community really started to contribute to the improvement of MuseScore because the number of users grew exponentially (from a few hundred to hundreds of thousands). Feedback from the community drove the programmers to many great improvements over the initial release and everyone involved with creating version 3.1 will be proud with it when it is released next week.

In reply to by Jojo-Schmitz

By enabling software, I mean MuseScore 1.x, 2.x, 3.x, not the web server etc. Without MuseScore scoring software, there won't be anything to freely publishing and thus no interest for people to pay for the Pro level of Musescore Inc's service. And because it's free software, those users complaining / feeding back bugs are less inclined to go to a competitor's solution (or V2.x) until the situation gets super bad--which with 3.0, it was.

In reply to by Jojo-Schmitz

Yes, I understood that from mike320. It's still a genius and bold business model. I'm not sure what the incentives are for volunteer developers but it's clearly working. The by-product of the model though is that Vx.0 will always be very buggy because the feedback isn't high enough from the alpha and beta versions but it is from the published Vx.0 version, which is when the end-users get invested. This has been a very illuminating conversation and completely explains why 3.0 was so bad. I guess as end-users we should either use Vx.0s in the future and volunteer to help the development; avoid early versions; or consider paying for alternatives.

In reply to by julianpinn

There are people who refuse to buy any x.0 version of any program because there are bugs missed even in large operations because final releases always have wider audiences, more feedback and therefore more fixes. The time frame between x.0 and x.1 is now much more compressed than it was before almost all software was distributed on the internet so waiting is not as bad as it once was. Internet distribution allows for much more frequent updates. The plan for MuseScore is to update it every 3 weeks or so. So when thousands of people start finding the bugs a few hundred of us didn't find in version 3.1 testing the bugs should be fixed relatively fast.

The nice thing about the open source model is that you can fix a bug yourself if you have then knowledge and time to do so, or you can do like I do and have an open conversation with the programmers about what's happening. See #289453: [Regression] Unable to start slur mode (within note input) one voice > 1 at end of measure for a very recent example where 3 programmers have been involved in the discussion with me.

In reply to by mike320

Yes, mike320, I complete understand. However, and constructive consumer feedback aside (I hope we're all willing to do that and also help our fellow users, like today), my worry is that on the one side it could be considered an admirable thing to become a volunteer developer (or play as a musician for free) but on the other side, doing that dilutes the pay potential of those wanting or needing to make it their profession.

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