2011/2/12 Han-Wen Nienhuys <hanw...@gmail.com>:
> 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.
Yes, the movement is limited. However, in the following example:
{ c64[ c] }
beams span over the upper four lines of the staff, while they could
span over the lower four lines of the staff also (i mean, they could
be moved exactly a staff space lower and it wouldn't cause any
problems). Maybe this should be changed too.
>> 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).
Agreed. I have an impression that i did it at least once and the
differencies in beamed notes were present, but i'll check it to make
sure.
> I'll have a look to see what changed wrt beaming.
>
>>> 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.
The flags would be basically the same, they'll just be assigned to
stems differently.
cheers,
Janek
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
