lilypond-auto
[Top][All Lists]
Advanced

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

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


From: Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: #5036 128 beaming output not producing output as expected (?)
Date: Sun, 22 Apr 2018 12:38:46 -0000

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 address@hidden 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
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto

reply via email to

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