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

[thomasmorley65]

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.

> >

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.

> 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.


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?
?



https://codereview.appspot.com/7615043/