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

[address@hidden]

On Mar 5, 2011, at 17:33, Janek Warchoł <address@hidden> wrote:

> 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
> 
> 

Having recently OD'd on beam quanting, I am convinced that the right cocktails 
of penalties and demerits can hit all of the targets that would potentially be 
on this list. There's nothing wrong with keeping a list like this in the form 
of a regtest with lots of beams (I think it's a great idea!), but I think the 
goal should be to modify the quanting such that it attains the result you want 
while not breaking other regtests. I know this is a tall order and means more 
work, but it seems like a better use of contributor time and a more sustainable 
solution.

~Mike