[Top][All Lists]

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

Re: fine-tuning new flags - feedback needed

From: Carl Sorensen
Subject: Re: fine-tuning new flags - feedback needed
Date: Fri, 4 Feb 2011 17:06:56 -0700

On 2/4/11 3:59 PM, "Janek Warchoł" <address@hidden> wrote:

> W dniu 4 lutego 2011 20:13 użytkownik Carl Sorensen <address@hidden>
> wrote:
>> On 2/4/11 12:01 PM, "Janek Warchoł" <address@hidden>
>> wrote:
>>> Hi,
>>> this is (hopefully) the final version of the new flags; it's a mix of
>>> previous two propositions and some new modifications. I must admit
>>> that i'm proud of it :)
>>> Some differencies between this version and the "compromise" version
>>> (from my previous mail):
>>> - 32nd stems are a bit shorter (but not as short as i suggested
>>> before), 128th stems are a bit shorter too. This makes the stem length
>>> transition smoother (see the coloured lines in the attachments),
>>> - the downstem flags are modified in such a way that the gap between
>>> notehead and flag is smaller; this makes 64th and especially 128th
>>> notes more balanced (at least in my opinion), see the dots in the
>>> attachment,
>> Read shows a larger gap on 64th and 128th flags than on the longer note
>> duration flags.
>> The downstem flags shown by Read have no gap between the flag and the head
>> for eighth, sixteenth, and 32nd notes.  I have not looked into
>> beautifully-engraved music to see what the publishers' practice is.
> Isn't all this a matter of the font design exclusively? We have our
> own font and we design it the way we like it.

Absolutely.  But the way we like it should be informed by the best engraving

> I changed downstem 64th and 128th flags because they looked like their
> design was limited by previous code. I mean that until now LilyPond
> used one flag for standard and shortened stems, and therefore this
> flag had to be some sort of a compromise (if the flag with smaller gap
> (like the one i made now) was used in old code, it would look good on
> standard length stems, but horrible on shortened stems; therefore the
> old flag had to have wide gap). Now i've changed the code, allowing
> different versions of flags being used on stems of different length,
> so the need for compromise is gone.
> Maybe the need for compromise was the reason why flags in Read have
> wide gaps, too?

I don't think so, but it's possible.

> As for the downstem 8th flag, it's current look is simply inconsistent
> with other flags (and with itself - it looks different when notehead
> lies on the staff line insted of between the lines). Look at the
> attachment.

Read's downstem flag is actually inconsistent in different locations, which
is probably consistent with a hand-engraved look.

>>> - the shortened upstem 8th flags are shorter (now the dots don't
>>> collide with them!).

Great!  That's one of the items Read mentions that should happen -- avoiding
the dots (although he says he does it by having different flags when the dot
is present).

>>> Here are the .ly files used for testing:
>>> Here are the pdfs:
>>> Here are pdfs made with current dev release (2.13.47) for comparison:
>>> Here is the patch file (i hope i got this right...):
>> Since you have made a patch, it appears that you have git available.
> Probably... :)
> I did the following:
> - modified the files
> - called lily-git.tcl
> - clicked "New local commit"
> - clicked "Make patch set"
> - send you the file that appeared.
> I don't know if using lily-git GUI instead of git (from terminal)
> makes any difference here...
>> Is there a reason you haven't uploaded the patch to Rietveld for review?
> CG 2.2 says
>   "More experienced contributors should upload the patch
>    for web-based review. This requires additional software and use
>    of the command-line; see Uploading a patch for review."
> and i felt like a not-so-experienced-contributor.

Fair enough.  But your work is significant, so I see you much less like a
not-so-experienced contributor.

> Perhaps i should have send all this to frog mailing list, but i wanted
> to know developers' opinion about the output too (not only the code
> itself)... sorry for the mess.

No apology needed.  This isn't a mess.  It's just that the next step for
review is having a patch on Rietveld.  And I can post it for you, or you can
post it yourself.  I'm just asking how you'd like to proceed.

> I tried doing things described in CG 3.3.4 "Uploading a patch for
> review" now, but i'm stuck after calling
>   git cl upload origin/master
> below is what the terminal showed me (i entered that description
> earlier, when i was using lily-git):
> # Enter a description of the change.
> # This will displayed on the codereview site.
> # The first line will also be used as the subject of the review.
> shortened stems and flags
> This improves the way that stems in forced directions are shortened
> and adds loads of new flags to be used with these shortened stems.
> I cannot do anything with this, only move cursor. pressing Return does
> nothing and i cannot scroll this too. Spooky...

Once you get to that point, just hit the escape key, then type :wq.

You are in vim, or some equivalent editor.

You're most of the way there, and you're a strong contributor.  But if you'd
prefer, I'll be happy to post the patch for you.



reply via email to

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