Hi Phil,

just a remark concerning "she only gives examples up to 4 beams":

The main purpose of the placement rules for horizontal beams within the stave 
is to avoid at all cost beams being placed in the middle of a space.
In my opinion, that's the reason why Gould does not say anything about more 
than four beams, just because 4 is the maximum number of beams to fit within 
the stave (keeping in mind that the inner stave-space should be kept clear of 
beams).

That way,  in the case of more than four beams, the excess beams stick out from 
the stave and, consequently, cannot not interfere with stave-lines.

# LilyPond's problem
LilyPond's beam positioning is governed by the outer beam. And this outer beam 
will snap into position obeying the rules of (invisible) stave-lines - even 
outside of the stave.
As soon as we have more than four beams, the inner beams can't be correctly 
positioned.

# Proposed solution
When it comes to horizontal > 4 beam positioning, the inner beams are much more 
important than the outer beams, because the inner beams have to be positioned 
within the stave.

So, in my opinion, it would be much better to **use the innermost beam for 
finding feasible positioning solutions** in these cases.

In Noeck's example, this is exactly what has been (manually) applied: the inner 
beams neatly sit on the stave-lines, the outside-stave beams won't interfere 
with stave-lines anyway.

What do you think?
Torsten

PS: an alternative would be to further widen the gap between the beams. That'd 
be perfect from a mathematical point of view, but even wider gaps look weird.



---

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

**Status:** Accepted
**Created:** Fri Jan 20, 2017 01:43 PM UTC by Palmer Ralph
**Last Updated:** Sun Apr 23, 2017 01:42 PM UTC
**Owner:** nobody


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 [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
  • [Lilypond-... Auto mailings of changes to Lily Issues via Testlilyissues-auto
    • [Lily... Auto mailings of changes to Lily Issues via Testlilyissues-auto
    • [Lily... Auto mailings of changes to Lily Issues via Testlilyissues-auto

Reply via email to