Beaming notes over barlines and line breaks

This is a known problem which has been mentioned before, but I can't find it in the issue tracker either.

Current behavior is still not good across line breaks - the beam for the continued staff appears on the beginning staff:

There is supposed to be a beam into the B on the second system. If you're wondering where it is, look just below the 4/4 on the first system :-) And I agree it should probably be facing the opposite direction as well, although I can't point to any particular source for this.

Duplicate #40951: Beams which span two staves are positioned on the wrong staff

I've been looking at this, but I don't think there is an straightforward solution other than to implement beams line more spanners, with separate segments that can belong to different systems. Without this, it might be possible to hack up something that worked across system breaks with a page, but not across pages. And even getting it to work on a single page is easier said than done, it seems - at the point where beams are being laid out, system page positions are not available yet.

FWIW, here is where I had thought it would make sense to add in the vertical offset from the beam's system to the system of the first chord of the fragment:

https://github.com/musescore/MuseScore/blob/38ceee49cf4f8bd1d8f63cf8958…

Maybe there is something I am overlooking, but I think getting this working will require more significant changes than I am comfortable with right now.

I looked some more hoping my recent experience with beams would give me insight, but unfortunately, I am led to the same conclusion - at the point when beams are laid out, we haven't laid out systems yet.

A possible hacky fix that could work within the page would be to somehow mark the segments that don't belong to the current system. Maybe have two lists of segments in the Beam class - one for the current system, one for the next. Then, during Beam::draw(), sort it out. It's a bad fix; the bbox for the beam would still be wrong, so selection would be weird.

Is there any more progress on this issue.?
it still is a problem with
2.02 revision f51dc11 (windows version, running on win7 64bit)
beam spanning over a bar line does not render correctly when the second bar is on a new line.
It still creates a bar artefact at the beginning of the first line, and not the second line, and the artefact is pointing the wrong direction.

There is a proposed fix by pgkos at https://github.com/musescore/MuseScore/pull/2144. There were issues raised with the first attempt. These were addressed but I'm not sure if the second attempt is considered more satisfactory or not. But hopefully this will form the basis for a fix at some point.

Came up twice today, https://musescore.org/en/node/88956#comment-392696 and https://musescore.org/en/node/88326#comment-392671
The PR at least needs a rebase.

Have come across this issue in 2.0.2 and it's still there in 2.1.0 5a8cf68 - see the beam coloured red below.

I'm trying to emulate the original scan

Sorry to point this out again if it's being worked on.

The PR hasn't yet been merged, that's why

I'm sure my scoring problems are related to this issue. I tried to join groups of 6 eighth notes in varying time signatures, which should result in some beams starting in one bar and continuing in the next. A line break creates an artifact beam at the left of the originating system, instead of continuing the beam in the next system. (The beam and artifact are displayed as orange for ease in viewing.)

May I ask, what "PR" stands for?
Would be great, if this feature could find its way into the nightly release... how can I support? Is there a voting system anywhere, where features can be up-voted?
Thank you!

Pull Request. You'd find it at https://github.com/musescore/MuseScore/pull/2144

Thank you for information! - I am wondering: is the feature supposed to be working now or is it still to be implemented? My tests failed with both nightly versions (MAC, MuseScoreNightly-2016-03-21-0756-master-1fd67d0.dmg,
MuseScoreNightly-2016-03-21-0716-2.0.3-8814553.dmg)...

When the status is changed to Fixed, that's how you will know the patch is accepted. Right now it is still set to "code needs review".

Seems fixed in current master

Not for me - now cross staff beaming isn't even *attempted* across systems:

1) my first score
2) enter eighths to fill measures 4 & 5
3) select first eighth of measure 5
4) douvble click "beam middle" icon

Result: nothing happens. Somewhat better than 2.0.3 behavior I guess, but definitiely not correct either.

Came up again at https://musescore.org/en/node/110131.

Marking again as "patch (code needs review)" because https://github.com/musescore/MuseScore/pull/2144 is still active.

Any update concerning this?

The PR needs a rebase, at least

Would love to know if there is any solution planned for v3. Right now, beaming over barlines doesn't work at all, not even within one system.

Any chance to implement a beam feature as we know it from Finale? meaning: manually prolonging the beam lines?

Also: is there any place where users can up vote features?

Thank you!

Hi Rowild, you just voted for this feature. There is currently no other way to vote for feature.
Beam over barlines should work in MuseScore 2.0.3. If it's not the case for you, please use the forum and describe your issue https://musescore.org/en/forum.

Thanks for your response!

"Beam over barlines" works in 2.0.3, but not, when there is a system break. Which is, what this thread is about, if I understood correctly.

Any idea, if anybody will dedicate his work to that topic during the GSC?
It is really the only feature which I am missing so desperately in MuseScore... everything else is there...

Regards,
Robert

Is there any progress on this? Any plans to incorporate this feature it version 3?
What can I do to support this feature?

Thanks!

You could write the code...

...and what if I am not a programmer...?

wait till someone else does it for you ;-)

Wait... somebody did: https://github.com/musescore/MuseScore/pull/2144

Yes, but this a) seems to not be good enough and b) needs at least a rebase

this is going to be fixed in future versions of ms right?

Hopefully so:-)

That PR needs a rebase though

Came up again in #187301: Changing beaming properties adds beams to wrong staff

and again in https://musescore.org/en/node/203816

the way i do it, copied from an earlier comment:

1. make sure the beams are the same type and height (you don't want one beam slanted and the other one horizontal)

2. double click the first note to enter edit mode, then use the arrow keys to move the note towards the end of the system and hit esc. the beam should extend to where the note is.

3. with the same note selected, but not in edit mode, use the element panel on the right to move the note back to where it was (horizontal offset). do the same thing with the stem. the beam should now have some overhang.

4. do steps 2 and 3 on the note on the next line, but moving towards the beginning of the system and back instead of the end and back.

Came up again in https://musescore.org/en/node/211626

Is there any progress being made on this? I just ran into this same issue on 2.1 yesterday. Beams across barlines work, but not when there is a system break. The first note (end of system) is fine, but the note on the next system is missing its half beam. Without seeing how the code is written, this seems like this should not be so hard a fix to be made. The attribute of the note on the second system knows that it is beamed, and should be able to look back to the previous note to see if the beam connects to it. The half beam of the first note is rendered correctly, ending at the bar line. Now the corresponding fix to the note on the next system needs to be made. It should not be much different from a slur between two notes with a system break between them.

"Without seeing how the code is written, this seems like this should not be so hard a fix to be made."

After all writing code is simply typing on a keyboard anyway ;-)

Unfortunately it is not so simple. The difference is in when the code formalin with these things is executed. Beaming is handled fairly early on, before we have enough info to know the vertical position of the system on the page. And there is kind of a chicken and egg problem here. Read through the previous responses and check out the PR that was submitted if you'd like to learn more. No doubt a solution can be found, but it's not as simple as one would hope.

I had not looked at the renderings in detail until tonight. I didn't realize that the beams for the note(s) on the next system are being drawn at the wrong vertical position (on the previous system). I thought they were missing altogether. In looking at the score I am working with, I see that they are indeed there, just at the wrong vertical place. As for the chicken and egg thing, I don't see how you can render a note, until you know where the note goes on the page, and aren't the beams part of the notes? I was looking at the result from the patches in post #2144, which looked very good. Good luck in fixing this permanently. My real-time problem is just for a single pair of notes beamed together crossing a barline, and hence, potentially, a system. I don't have a need for anything as elaborate as the examples shown.

And to augment what I see when using the editor, I see that when you click on the beam, it appears to be a single entity, highlighting both half pieces, hence part of the underlying crux of the problem perhaps. When a beam needs to split across two systems, shouldn't it become two separate entities, a left half beam on the first system, pointing to the right, and a right half beam on the second system pointing to the left. Then they would be selectable separately to manipulate with the inspector, etc., if desired.

The position of many elements is calculated relative to the systems they are on. That way the position of the elements on the systems can help determine the space needed between systems, and we don't need to completely recalculate everything once we decide on system spacing.

But anyhow, yes, making beams more like slurs when you can edit the segments separately when split across staves is probably part of the solution.

Came up again. https://musescore.org/fr/node/269388

Came up again https://musescore.org/en/node/272127

and again in https://musescore.org/en/node/274046

and again in https://musescore.org/en/node/276968

Seems 3.0 doesn't allow cross barline beams at all, so avoids the problem

(crossed message)

Came up in #279695: Can't beam across bar lines. again

Came up again in https://musescore.org/en/node/281059

In V3.0.4 the behavior is improved by breaking the beam at the line break which gives a clean result, even if it is not a complete fix. but the beams may disappear to return later - see #285141: Beam across a system break can disappear

Just wondering - how about a solution as Finale offers it: extending the length of the beams on either side? Would that be anything that could be implemented easier? Maybe even as a plugin?

Edit: Sorry, I do not know, how to handle all those input fields in this post. It now shows "Regression Yes -> no", which is nothing that I want to change. Please edit or correct my post accordingly, before it causes any confusion - thank you!

It's not a regression - this bug has always been present. So, good job :-).

Anyhow, I think what you propose is all anyone wants - it's just proven easier said than done.

Just upgraded to 3.2.3. I thought I remembered this finally working in 2.3, at least with adjacent measures on the same system. In another thread I thought I saw a solution discussed, but the tech talk went over my head. For those of us who don't code, is there a solution yet?

It does work with adjacent measures on the same system. Only measures not on the system don't work, as I explained in https://musescore.org/en/node/280050#comment-933825. You don't have to do anything special if the measures are on the same system; it works perfectly right out of the box.

+1

.

This problem still hasn't been fixed, that's why the status is still active. I don't expect it to be fixed in 3.6 either, but the next release will be 4.0 and I hope it will be fixed then.

I just use pictures to replace the cross beams:
Screenshot a regular beam then load it on the note.

Just paste these onto the note stems:
the result is on the Untitled.png .

Try SVG rather than PNG, those should work even better and scale losslessly

noted thx

I believe this is critical according to the standards because the only work around is "Don't do that" It's impossible to get the common beam that stops at the end of one system and starts on the next.

My workaround is screenshot pictures of beams and attach it to the note stem
Is anything wrong

That doesn't actually fix the root problem. Keep it critical so programmers will think about it more. It's one of the oldest unfixed bugs there is.

ok

a nice workaround after 2 years yay