lilypond-devel
[Top][All Lists]
Advanced

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

Re: GSoC rendering improvements


From: Janek Warchoł
Subject: Re: GSoC rendering improvements
Date: Wed, 4 Apr 2012 22:27:56 +0200

Hi Corey,

On Apr 4, 2012, at 6:35 AM, Corey F wrote:
> I'd be interested in working on either of two projects suggested for Google
> Summer of Code, most likely "Improve beaming" but perhaps instead "Improve
> slurs and ties".

Glad to hear that you're interested in those!

> Though LilyPond isn't currently my notation tool of choice, I believe I do
> have an exacting aesthetic sense that would be useful to these projects,

I suggest you to go here
http://news.lilynet.net/IMG/pdf/Coronation_Mass_-_Credo_2-15-33_marked.pdf
and check whether yellow, orange and brown markings surprise you or
not.  That could be a good test.

> I don't currently have further specific ideas beyond the outline given on
> the LilyPond website, but any insights into these projects, and how I should
> best form a GSoC proposal, would definitely be welcome.

On Wed, Apr 4, 2012 at 3:47 PM, address@hidden
<address@hidden> wrote:
> I'd first formulate the problem in aesthetic terms
> (i.e. "The literature shows that beams usually do X, whereas LilyPond
> currently does Y") and then read beam-quanting.cc to see why lilypond does Y
> and what types of modifications would be necessary to arrive at X.

I think there might not be enough time to define all specific changes
that are needed in beam positions or tie and slur shapes before
application deadline - it's a lot of work.  However, you can try
describing some general changes, for example:
- change beam thickness and beam gap according to staff size
(something similar to optical sizing
http://lilypond.org/doc/v2.15/Documentation/essay/engraving-details#optical-sizing),
- when beam gap is small, hide stafflines that show in these gaps to
increase legibility
- make beaming depend on context (surrounding notes)
- automatically adjust beam gap and line thickness to allow better beam quanting
- make beaming more consistent (a bad output example: { e''8[ c'']
d''[ b'] c''[ a'] } )
- make beam collision avoidance more precise (currently it sometimes
moves the beams too much)
- make beam position quanting less strict

If you want, i can send you my (huge) collection of examples about
beams and ties.

cheers,
Janek



reply via email to

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