2011/2/11 Janek Warchoł <lemniskata.bernoull...@gmail.com>:
>> Don't take 32nds as a standard for comparing beams and stems. Due to
>> its configuration, the 32nd beam has very little room to move
>> vertically. See for example
>>
>> \relative {
>> g32 g[g] a32 a[ a] b32 b32[ b] c32 c32[ c] d32 d[ d] e e[ e] f f[ f]
>> }
>>
>> as you can see, there is a discrepancy that goes the other way too.
>
> No, that's a bad example! I mean, to me there's a whole another
> problem in what you posted above. The problem is that the stem of
> unbeamed notes is lenghtened differently than in case of beamed notes.
Correct; but this is inevitable. The beams has much less ability to
move, since the staffline may not come into the blank space between
the beams.
> Look at this, it's a more pronounced example: { c32 c[ c] c64 c[ c] }
> - the unbeamed stems are lenghtened to middle staff line, while beamed
> stems are lenghtened more than that. That's not the case with 8ths and
> 16ths: { c8 c[ c] c16 c[ c] } looks fine.
> In fact, i wondered if this behaviour is correct. My personal opinion
> is that it isn't correct, but i have no idea what engraving books say.
> In my opinion it should look like attached unbeamedVsBeamed.png .
> Can you (or someone else) check this in music engraving books?
good question. I'm not sure I have any of those, but I'll try to look.
>>> In my suggested output shortened 32nd notes with flags are a bit
>>> longer than beamed ones, 8ths are a bit longer or equal, and all other
>>> are equal. No flagged note is shorter than corresponding beamed one.
>>> Are you sure that you haven't switched the files when comparing?
>>
>> I am sure; the version number is on the bottom. I am looking at the
>> flag test proofsheet. Compare for example, a'' 8th upstem (3rd line).
>> The old version pops out, the new version is as long as the beam.
>
> That's true, however compare my proposed output with old output in
> case of the notes marked in red here:
> http://imagehosting.nu/images/flagtestin.png
> What's most interesting is that it's the beamed stems length that
> changed (which i didn't touch at all).
I have been messing with the beam scoring; the regtest came out clean,
but we may miss some coverage. Probably it's best to always compare
the same versions (ie. origin/master vs.origin/master + your patch).
I'll have a look to see what changed wrt beaming.
>> It's best to look at the beams outside the staff, as the ones inside the
>> staff are more restricted in allowed positions due to interference
>> from the stafflines
>>
>> Of course, it may be that the beaming is not perfect, and should be
>> adjusted in some situations, but maybe we could solve one problem at a
>> time? Ie. fix the discrepancy of the 32nd, and improve the shape for
>> the shortened flags at the note head end? We could try to treat the
>> tip lengths in a separate patch; possibly beam scoring should be tuned
>> too.
>
> Yes, i agree. We should do one thing at a time. I even see another
> issue that can be separated here - the transition in length of
> unbeamed notes (the thing illustrated by the second part of the first
> system in "flag testing").
> I'll divide my patch as soon as i resolve some problems that i have
> with my git repository (hopefully this will happen tomorrow), and i
> think we shall discuss these issues in separate threads.
Great!
>> Especially the 8th up flag in shortened position (f'' and higher)
>> looks stocky rather than elegant and slender. If you let the flag
>> length overall be longer, it will be easier to maintain the slender
>> look.
>
> Ah, you mean upstem 8th flag. I thought you were referring to the
> downstem 8th flag.
> Yes, i agree that upstem 8th flag is shortened quite aggresively.
> On one hand, this makes it look more similar to all other shortened
> upstem flags. Also, it was easy to code it this way.
> On the other hand, it's very different from the old look, and, as you
> say, quite stocky.
> I don't insist on keeping it this short.
Awesome. Look forward to the new shapes.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
