Subdivised beams bug

[foxfanfare]

Hi all,

I found a small bug while using the automatic beaming function.
http://lilypond.org/doc/v2.19/Documentation/notation/beams.html#setting-automatic-beam-behavior

See:

\relative c'' {
\set subdivideBeams = ##t

% Set beam sub-group length to an eighth note
\set baseMoment = #(ly:make-moment 1/8)
\set beatStructure = 2,2,2,2
c32[^"OK" c c c c c c c]

c32[^"OK" c r c c r c c]

c32[ c c c c^"BUG" c c] r
}

When the beat ends with a rest, the subdivised beam doesn't work correctly.



--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

[Malte Meyn]

Post by foxfanfare
When the beat ends with a rest, the subdivised beam doesn't work correctly.

The result (using LilyPond 2.19.82) is exactly what I would’ve expected.
I suppose your expectation is different so what did you expect?

[foxfanfare]

Post by Malte Meyn
The result (using LilyPond 2.19.82) is exactly what I would’ve expected.
I suppose your expectation is different so what did you expect?

The automatic subdivised beam is 16th instead of 8th. Here is the problem
and what I would have expected:

\relative c'' {
\set subdivideBeams = ##t

% Set beam sub-group length to an eighth note
\set baseMoment = #(ly:make-moment 1/8)
\set beatStructure = 2,2,2,2
c32[^"OK" c c c c c c c]

c32[^"OK" c r c c r c c]

c32[ c c c c^"BUG" c c] r

c32[ c c \set stemRightBeamCount = #1 c
\set stemLeftBeamCount = #1 c^"FIXED" c c] r
}

beams.JPG <Loading Image...>




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

[Urs Liska]

Hi foxfanfare,

Post by foxfanfare

The result (using LilyPond 2.19.82) is exactly what I would’ve expected.
I suppose your expectation is different so what did you expect?

The automatic subdivised beam is 16th instead of 8th. Here is the problem
\relative c'' {
\set subdivideBeams = ##t
% Set beam sub-group length to an eighth note
\set baseMoment = #(ly:make-moment 1/8)
\set beatStructure = 2,2,2,2
c32[^"OK" c c c c c c c]
c32[^"OK" c r c c r c c]
c32[ c c c c^"BUG" c c] r
c32[ c c \set stemRightBeamCount = #1 c
\set stemLeftBeamCount = #1 c^"FIXED" c c] r
}
beams.JPG <http://lilypond.1069038.n5.nabble.com/file/t5604/beams.JPG>

you're right, LilyPond's behaviour is incorrect. Although I must admit
it has explicitly been made to behave like this. This is because we
(well, I) misunderstood the section in Gould's book (which is slightly
misleading and especially lacks an example). BTW Dorico exposes the same
bug, at least it did at the time when I realized it. Maybe they found
the time to fix it in the meantime (but don't start talking about the
other commercial "competitors", they're totally at a loss in that area
;-) ).

The problem is that the matter is really complex and the existing code
needs a complete rewrite. When you start looking at subdivisions in
tuplets you'll see that it doesn't work properly at all (and in fact
automatic beaming suffers from the same issues). I've (re-)attached a
document that I compiled half a year ago investigating the problem. I
*think* that it is quite thorough and correct, to the point where it
stops. I couldn't finish it at the time, and I started it because I knew
I wouldn't be able to go ahead and fix the issue (so there should be at
least some documentation left behind). It was too complex for me to
tackle (given my spare time), matters are complicated through the fact
that I don't really know C++, and finally it turned out that you can't
fix the beaming subdivisions on their own but have to fix LilyPond's
notion of tuplets at the same time.

TL;DR: it's a known issue, and there's no reasonable hope to have it
fixed soon.

Best
Urs

[James]

Hello

Post by Urs Liska
TL;DR: it's a known issue, and there's no reasonable hope to have it
fixed soon.
Best
Urs

Does that mean there is a tracker for this, or do we need a new one created?

James

[Urs Liska]

Post by James
Hello

Post by Urs Liska
TL;DR: it's a known issue, and there's no reasonable hope to have it
fixed soon.
Best
Urs

Does that mean there is a tracker for this, or do we need a new one created?

There are a number of open issues, (at least) one lengthy discussion,
and an entry on the GSoC page, but not a comprehensive tracker item.

I suggest someone from the bug squad (deliberately not myself) creates a
new issue for this, referencing

* http://lilypond.org/google-summer-of-code.html#Fix-Beaming-Patterns_002fBeam-Subdivisions-and-Tuplets
* http://lists.gnu.org/archive/html/lilypond-devel/2017-11/msg00037.html

attaching the PDF from my previous post as a starting point and check
whether the following issues should be merged into the new one:

* https://sourceforge.net/p/testlilyissues/issues/4739/
* https://sourceforge.net/p/testlilyissues/issues/4740/
* https://sourceforge.net/p/testlilyissues/issues/4738/
(this definitely refers to outdated attempts)
* https://sourceforge.net/p/testlilyissues/issues/2361/
* https://sourceforge.net/p/testlilyissues/issues/1515/
* https://sourceforge.net/p/testlilyissues/issues/4919/
* https://sourceforge.net/p/testlilyissues/issues/2474/

Urs

Post by James
James

[foxfanfare]

Post by Urs Liska
TL;DR: it's a known issue, and there's no reasonable hope to have it
fixed soon.

Thank you Urs for all the explanations. I feel sorry I don't have the
knowledges myself to help with the code... But LP is now my main engraving
software which I start to use intensively.
My only little contribution to the project for now is reporting bugs so I'm
glad to see my comments are somehow taken into consideration, and I hope
this issue will follow its course!

Cheers




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

[Malte Meyn]

Post by foxfanfare

Post by Malte Meyn
The result (using LilyPond 2.19.82) is exactly what I would’ve expected.
I suppose your expectation is different so what did you expect?

The automatic subdivised beam is 16th instead of 8th.

Ok, now after a closer look I see that the problem is not *where* the
beams are subdivided but *how*. That’s a bug, yes, see Urs’s reply.