[Top][All Lists]

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

Re: Piano pedalling patch

From: Chris Jackson
Subject: Re: Piano pedalling patch
Date: Mon, 18 Mar 2002 15:25:28 +0000
User-agent: Mutt/1.3.27i

On Fri, Mar 15, 2002 at 02:24:26PM +0100, Han-Wen Nienhuys wrote:

>      /* Hmm. TODO: This should be set in grob-description.scm, but
>       side-positioning of consecutive brackets only seems to work if
>       direction is +1 within the engraver */

I should explain my confusion about directions ... 

Problem: For 'mixed' style pedals, like Ped.______, the horizontal line
should be shortened by the extent of the Ped. text.  To obtain this
extent, I set the parent of the _____ spanner to be the Ped. text item.

The direction of _____| (PianoPedalBracket) grobs should be -1, as it is
a text spanner (+1 produces an upside down bracket). However, if the
direction of the ____ is set to -1 when it is created by the engraver,
then the output becomes

. . . . . .        (<-  the imaginary line of the PianoPedalLineSpanner)
    ______|        (<-  the actual pedal)

instead of 

. . . . . . 

Is this a consequence of the Ped. being the bracket's parent? Is there a
better way to obtain the size of the text within the line's

> angle-{left,right} should either be renamed, or really be an angle.
> I'd vote for the 2nd option, so people could set redefine the layout
> of a bracket. Or is this redundant as we have edge-width as well? If
> it is, angle-{left,right} should go, and edge-width should be renamed
> to something like "bracket-edge-flare", or "edge-flare"

angle-{left,right} is a boolean for whether the edge of the bracket
corresponds to a bit of a /\. (I've just renamed these to
{left,right}-widen). The amount of stretching is controlled by
edge-width, which is hardcoded at the moment to half staff space, but
I'll work on getting this customisable.  


reply via email to

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