# 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)
**Problem**
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
`Beam_scoring_problem::generate_quants`
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.
**Goal**
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,
Torsten
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.
Attachments:
-
[128th-beam-quanting-01.png](https://sourceforge.net/p/testlilyissues/issues/_discuss/thread/1a78231c/4755/attachment/128th-beam-quanting-01.png)
(75.1 kB; image/png)
---
** [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 sourceforge.net because testlilyissues-a...@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/testlilyissues/admin/issues/options. 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, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Testlilyissues-auto mailing list
testlilyissues-a...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
