lilypond-devel
[Top][All Lists]
Advanced

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

Re: Adds glissando stems to Lilypond. (issue4661061)


From: address@hidden
Subject: Re: Adds glissando stems to Lilypond. (issue4661061)
Date: Fri, 1 Jul 2011 22:12:30 +0200

On Jul 1, 2011, at 7:45 PM, Graham Percival wrote:

> On Fri, Jul 01, 2011 at 07:17:08PM +0200, address@hidden wrote:
>>   I'm responding to your e-mail backwards, with answers to the technical
>>   parts first followed by answers to the broader questions you raise.
> 
> I'll briefly comment on those broader questions.
> 
>>     * Have an engraver (by preference written in Scheme) that hooks up the
>>     glissandi with the stems.
> 
> This might be an ideal way forward -- not necessarily with this
> specific issue, but as a general means of extending lilypond.  I
> think it could be really helpful if we had a few more examples of
> how to write + include such scheme engravers.
> 

I completely agree - I use custom engravers all the time to hook stuff up.  
Either that or I write stuff in Python that auto-generates LilyPond syntax.

>>   This was what I originally did, but the crucial issue that arises is that
>>   of stem direction.  Left to its own devices, Lily will pick the direction
>>   of whatever original arbitrary pitch was chosen, which may be nowhere near
>>   where the glissando actually falls.
> 
> If we want to push the ideal of custom scheme engravers (and I
> don't want to assume that we _do_ want to encourage this approach,
> although at the moment I can't think of any problems with it),
> then perhaps we need more hooks to pass information around, to
> allow "programmer" users to avoid such problems with their custom
> scheme engravers.

I think information is already very well passed around - a custom engraver can 
listen to anything, acknowledge anything, create any grob, etc..  As you say 
above, we just need more examples.

The issue in this particular case is subtle.  Deep in the optical spacing code 
(far removed from anything a user could reasonably override or do without), 
there are decisions made based on a stem's direction, but the direction of a 
glissando stem cannot be known until the line breaking is done and the full 
length of the glissando is known.  This is also the issue with pure properties, 
as Joe pointed out a little while ago.  Even if this issue has ceased to show 
itself because of good safeguarding, it is still present.

I am a proponent of using mixed integer linear programming to solve these 
issues.  I believe that 100% of LilyPond's spacing could be rewritten as 
constraints in a linear program, in which case the vertical and horizontal 
spacing would all happen at the same time, and contingencies like this could be 
built into the linear program.  That'd take a lot of time, but if people were 
interested, I would love to work on this.  It would also make LilyPond more 
modular because cyclical dependencies could be simply sorted out in the linear 
program instead of avoid through the nightmare to which Han-Wen alludes when he 
correctly warns against source code fraught with exceptions.

Cheers,
MS


reply via email to

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