Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

[address@hidden]

On 17 mars 2013, at 13:36, address@hidden wrote:

> On 2013/03/17 07:27:37, MikeSol wrote:
>> On 2013/03/13 21:38:59, thomasmorley65 wrote:
> 
>> > https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm
>> > File scm/output-lib.scm (right):
>> >
>> >
> 
> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1061
>> > scm/output-lib.scm:1061: (thick (* thick (layout-line-thickness
> grob)))
>> > At first sight I was surprised about `layout-line-thickness´. Than I
>> remembered,
>> > it is defined in bar-line.scm
>> > How about making it public, moving it to lily-library.scm?
>> > It could be used then in local custom-definitions.
>> > Same with `layout-blot-diameter´.
>> > I know, it's another topic, though, what do you think about it?
> 
>> Great idea!
> 
> I'd have expected _this_ change in another patch.
> At least it should be mentioned in the commit-message.

Will do.

> 
>> >
> 
> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1078
>> > scm/output-lib.scm:1078:
>> > What do you think about predefining sth like
>> > ferneyhoughHairpinOn/Off
>> > constanteHairpinOn/Off
>> > in /lyproperty-init.ly?
>> > i.e.
>> > ferneyhoughHairpinOn =
>> > \override Hairpin #'stencil = #ferneyhough-hairpin
> 
>> I'm not against this idea at all - I'd like to see it proposed in a
> different
>> patch set, if possible.  I am teerrrrrible at judging UI issues
> because I hack
>> so much.  It is true that shortcuts help, but there are many, many
> overrides
>> that are shortcut-worthy.  I'm not sure what standard determines which
> overrides
>> should get shortcuts and which shouldn't, so I leave that to a future
> (and
>> important!) conversation.
> 
> ok
> 
>> >
> 
> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1082
>> > scm/output-lib.scm:1082: (define-public constante-hairpin
>> > I'm not happy with constante-hairpin.
> [...]
> 
>> The constante indication means that the dynamic should not change at
> all, so the
>> decision to use a hairpin that grows in a given direction is
> admittedly a hack.
>> The idea of dimMolto (or crescMolto) with constante is a contradiction
> (get very
>> quiet while not changing dynamic).
> 
> Yep.
> And this contradiction _is_ disturbing.

Agreed.

> 
>> Insofar as a hairpin represents a change in
>> dynamics, constante should, in theory, be a different grob.  My
> solution is not
>> ideal, but I think it is an OK middle-ground short of the creation of
> a separate
>> grob.  If people think it is too hackish, I will propose a new patch
> with a
>> Constante grob (or make the hairpin grow-direction = #CENTER default
> to
>> constante, which'd be difficult but doable).
> 
> For now I'd tend to let it as it stands.
> Nevertheless, it _is_ hackish and I think it should be replaced by one
> of your proposals later.

Agreed.

> 
> 
> Though, how about:
> 
>> Is it possible to make the hook-direction depending on the position of
> the
>> Hairpin i.e below or above the staff?
> ?
> 
> 

You'd have to have a wrapper function with a call to ly:scale-stencil with a -1 
to the Y axis based on the direction of the grob.
This is doable, but I'd wait to see from someone who knows how these things 
work if this is actually how they are printed.
I want to say that they are always printed with the line going up irrespective 
of the side of the staff, but I could be wrong.

Thanks for the review!

Cheers,