Beaming notes over barlines and line breaks

• Apr 28, 2012 - 08:35
Priority
P1 - High
Type
Functional
Severity
S2 - Critical
Status
active
Regression
No
Workaround
No
Project

R. 5578 - Windows xp
------------
First reported in
http://musescore.org/en/node/15507
and
http://musescore.org/en/node/15509
------------
Steps to reproduce:
1- create a score (4/4)
2- write two 8th notes on the last beat of a bar
3- create a 8th note on the next bar (1st beat)
4- beam them across the barline
5- add a line break aver this barline
===>> stems with infinite height
------------
The problem has always been there, from 1.0. Now, with 2.0, the result is slightly different.

See screenshots of what should happen and what actually happens (v.1.2):
brahms_op116_0.png
bug_salto_de_linea_musescore_0.png
------------
This is a mixture of bug report and feature request. I put the most 'restrictive' one.
I've been looking for similar posts on the issue tracker but I haven't found anything.

Thanks,
G.

Attachment Size
brahms_op116_0.png 105.08 KB
bug_salto_de_linea_musescore_0.png 195.23 KB

Comments

Win xp - R.2d3b0b9
Update: It's been partly fixed: Now there isn't a very long beam running across the whole page, but it still differs from written scores.
NOT FOUND: 1
Two things:
1) The beams are only cut if each 1/8 note is not beamed to anaything else in its bar (see 2nd example).
2) Shouldn't the cut beams be longer? In the printed scores, they are almost in contact with the barline

Attachment Size
pngg.PNG 33.82 KB
Untitled.mscz 2.05 KB

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

beam-system.png

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.

Attachment Size
beam-system.png 8.5 KB

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.

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

Attachment Size
beam sample.jpg 44.25 KB

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!

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

Status (old) fixed active

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.

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!

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

Reported version 2.1 3.0

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

Thanks!

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.

In reply to by Marc Sabatella

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.

In reply to by Marc Sabatella

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.

In reply to by Jim Newby

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.

In reply to by TinyTrouble

Regression Yes No

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?