Re: shortened flags affair, part 4 - downstem 8th flag

[Carl Sorensen]

On 3/5/11 6:54 PM, "Janek Warchoł" <address@hidden> wrote:

> W dniu 6 marca 2011 01:17 użytkownik Carl Sorensen <address@hidden>
> napisał:
>> 
>> On 3/5/11 4:12 PM, "Janek Warchoł" <address@hidden> wrote:
>>> Short question: do you agree to make downstem 8th flag shorter, as in
>>> "single downstem proposed.png"?
>>> I've seen a finale user complaining about it too. I recommend reading
>>> http://forum.makemusic.com/default.aspx?f=6=209535=209731#m209729
>>> <http://forum.makemusic.com/default.aspx?f=6&m=209535&g=209731#m209729>
>>> - we can learn something from his post.
>> 
>> As far as the comments he has about his music, I'd like to see his source
>> code.  It looks to me like he's forcing a non-optimal layout; the note close
>> to the bar line in measure 6 is not something that LilyPond will do by
>> default now (and I doubt it did in 2.10.33, either).
> 
> I was curious too, so i wrote it down.
> Indeed it looks like he used non-default layout (by default Lily uses
> 3 systems), but i won't call it non-optimal. In my opinion fitting
> this music in two systems is perfectly reasonable here (and maybe even
> better than spreading over 3 systems), and Lily should be able to
> execute this flawlessly.
> Unfortunately, measure 6 still looks bad. It's not as spectacular as
> in his pdf, but i won't said its acceptable at all. It's a shame
> especially because this problem is something in which Finale (2008)
> excels (see attachment).

I don't see what you mean in your attachment.  I see lots of places where
the notes in the attachment are *much* closer to the barlines than in the
current LilyPond output.

> Still, even not counting this, he undoubtedly proved - with some very
> simple music - that LilyPond 2.10.33 failed to produce acceptable
> output :(

So I compared his 2.10.33 output with the current 2.13.53.

Here are the things he didn't like:

> Errors I can spot: 
> bar 1: dynamic to far to the right

Still there, I suppose.  I'd like to see what he considers "just right".

> Bb - to short stem (throughout)

Perhaps.  It's consistent with Read.  But thanks to your fix, that's now
fixed in 2.13.53.

> flags (incorrect notation, just to test commands) to close to notehead when
> notehead is in a space.

The concept you're currently working on.  If we agree to accept your
changes, that concern will go away.

> bar 6: final note WAY to close to barline.

Now only slightly too close to barline.  Should probably be filed as a bug.
I don't know why the last note in measure 6 is closer to the barline than
any other note in the piece.  I assume it's because of the time signature
change.

Indeed, if I eliminate the time signature change the spacing is improved.
I'll see if I can make a Tiny Example.

> bars 7,8,9: cresc/dim and axpressions - bad allignment.

Perfectly aligned now.

> bars 8,9,11: ugly slurs, bad placement in bar 8

I agree with 9 and 11 having ugly slurs -- too sharply peaked.

I've changed the slur scoring so that it doesn't try to move slurs away from
staff lines.  It cleans up the ugly slurs, at the expense of letting the
slurs touch the line.  I've attached a pdf with those changes.

I don't think 8 is an ugly slur, or that the placement is bad.  Can you tell
me what is ugly about it, and why the placement is bad?

> bar 12: accidental touching slur.

If we let it go to 3 systems, it doesn't touch.  If we force it to 2, it
does.

After changing the move from staff line slur scoring, the collision goes
away.

What do you think about this new layout?

Thanks,

Carl

promenade.pdf
Description: promenade.pdf