lilypond-devel
[Top][All Lists]
Advanced

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

Re: a list of manually fine-tuned beaming exceptions?


From: Janek Warchoł
Subject: Re: a list of manually fine-tuned beaming exceptions?
Date: Sat, 5 Mar 2011 23:33:52 +0100

2011/3/5 Phil Holmes <address@hidden>:
> I'm not qualified to comment, and it seems it would be hard work, but you
> might be interested in this snippet in the music I'm setting now.  To me,
> the shorter beams look rather squashed, and I'm surprised they're not the
> same height as the longer ones, since the notes are so similar:
>
> { \key d\major fis'16 ( [ a'16 fis'16 a'16 d'16 a16 ) ] g'16 ( [ a'16 g'16 
> a'16 cis'16 a16 ) ] }

I agree that the difference between these two stems looks quite big.
However instead of moving first beam up a staffspace, i'd move it 0.2
ss up and the second 0.2 ss down.


2011/3/5 address@hidden <address@hidden>:
> There are a couple things to note.
> First, in define-grobs.scm, there is an old beamed-minimum-free-lengths list 
> that
> is commented out - this may get you the results you want.
>
> Second, the calculation for ideal length takes beam_thickness into 
> consideration
> but not beam_translation, which I think would be important in figuring out 
> this length.
>
> If you were looking for places in the code that could lead to a viable patch,
> these'd be the two places I'd mess around w/ first.

Thanks for pointers! I'll investigate when i finish my shortened flags issue.


2011/3/5 Trevor Daniels <address@hidden>:
> When I suggested investigating the automatic beaming I didn't
> mean messing with the code.  But there are a number of parameters
> in the #'details property of beam which might be worth exploring.
> For example, the default value of stem-length-demerit-factor is
> 5.  Setting this to 10 lowers the beam of the first example above by
> a staff space.  Setting it to 20 lowers it by 2 ss.  Neither of these
> settings changes the beam position in the second of your examples.

Thanks for information! Yes, this should be investigated.
However, i'm afraid that when i change some well-established
parameters, it may cause unwanted side-effects in other beams. And the
worst part is that i have no means to check this: it would require a
gigantic proof-sheet consisting of thousands of different beams to
check that some parameter combination works optimal.
That's why i suggested a temporary solution. It could also serve as a
reference beaming database later.

cheers,
Janek



reply via email to

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