[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5036 128 beam

From: Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5036 128 beaming output not producing output as expected (?)
Date: Thu, 26 Apr 2018 20:53:21 -0000

Step 1: Adjust quanting

As the beam translation (the distance between beams) for good reason stays the same for 4 and more beams, it is absolutely impossible to prevent all of the 128th, 256th, ... beams from being placed between stave-lines.

How does LilyPond's beam quanting algorithm work?

Basically, LilyPond will perform the following steps (simplified):
1. Create a list of valid beam positions for the outer beam (sit, straddle, inter (!?), hang)
2. These positions are checked for all beams (the inner beams, too!) and demerits are added up for bad placements
3. LilyPond picks the best compromise (minimum demerits)

By making the outer beam snap into valid positions (even if this beam never touches a stave-line in cases of more than 4 beams), the inner beams will never fit into the stave-line grid any more.
This will yield bad demerit values for any combination, but the (relatively) best one will be chosen.

This is particularly obvious for a 128th beam (Fl. 2.79 when switching on debug-beam-scoring), but 256th, 512th, and 1024th beams are badly placed, too.

Proposed Solution
It's actually the inner beams that will have to snap into valid stave-line grid positions.
Without too much interfering with the (delicate) beaming algorithm, that's what I'm doing:

The feasible (sit, straddle, inter (!?), hang) positions generated in
Will be corrected (for > 4 beams only!!!) so that the outer beam will snap into positions that yield valid positions for the inner beam. That's all (as a first step).
Bad combinations will be filtered out by the following process in a natural way.

I've attached a file comparing current (above) beaming and my proposed solution (below) showing the initiating example of this issue (including debug-beam-scoring info).
The stems have been removed and the stave-lines and beams are coloured so that any positioning mismatches can be clearly seen.

The goal is to make beams > 4 just behave more or less like 64th beams with the additional beams added "on top". It's the inner beams that have to fit into the stave, because the outer beams don't interfere with any stave-lines.

I've included the (standard) 64th example, too, so that you can see that the demerits don't get worse for 128th, 256th, 512th, and 1024th beams (as opposed to the current-state rendering).

"L" is just the lengthening of the stem (can't be avoided), but the "Fl" meaning that (some) of the beams don't fit into valid stave-line positions) are no longer there in the prototype version.

All the best,

PS: Slanted beams (and other aspects) are a special challenge an (there are many things to do there (design discussions needed) - but this is just a first step, so I won't provide a patch yet.


[issues:#5036] 128 beaming output not producing output as expected (?)

Status: Started
Labels: beaming
Created: Fri Jan 20, 2017 01:43 PM UTC by Palmer Ralph
Last Updated: Thu Apr 26, 2018 08:06 PM UTC
Owner: Torsten Hämmerle

Noeck wrote :
is this a bug or done on purpose? The following snippet produces beams
of which the lowest beam does not touch the staff line below.

{ g128[ g] }

The small-gaps-fill-with-ink theory should avoid this. IMHO the output
would look better like this:

  \override Beam.positions = #'(2.7 . 2.7)
  g128[ g]

What do the experts think?

This has been discussed at some length on the user list.

Sent from because address@hidden is subscribed to

To unsubscribe from further messages, a project admin can change settings at Or, if this is a mailing list, you can unsubscribe from the mailing list.

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Testlilyissues-auto mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]