Adds Ferneyhough hairpins to LilyPond.

Adds Ferneyhough hairpins to LilyPond.

[lemzwerg, 2013-03-08 06:26:29]

From visual inspection, LGTM.

https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm#newcode929
scm/output-lib.scm:929: form. @code{x} is the portion of the width consumed for
a given line
Please use two spaces after a full stop.

[thomasmorley65, 2013-03-08 23:15:08]

Hi Mike,

one thought.

The image Trevor Bača posted
http://lists.gnu.org/archive/html/lilypond-user/2013-03/pngIGBdggySyh.png
shows that the left ends of a decrecsendo-hairpin are vertical aligned even if
the hairpin isn't extended horizontal but ascending.
Currently the vertical alignment is gone if the hairpin is rotated, and, afaik,
this is the only way an ascending hairpin is available (apart from constructing
a new one from scratch).

(Similiar for cresc-hairpins.)

Is it possible to extend your code to achieve this?
Might be an interesting feature for common hairpins as well.

Since I don't know of I explained myself well enough, here some markup-code
which mimics it:

#(define drag-hairpin 5) % try different values
  
\markup
  \postscript 
  #(string-append
  "
    0 1.5 moveto
    0.5 -0.75 rlineto 
    15 
    "
    (number->string (+ -0.75 drag-hairpin))
    "
    rlineto
    
    0 -1.5 moveto
    0.5 0.75 rlineto
    15
    "
    (number->string (+ 0.75 drag-hairpin)) 
    "
    rlineto
    stroke
    
    % a red line to show vertical alignment:
    
    gsave
    0 3 moveto
    1 0 0 setrgbcolor
    0 -6 rlineto
    stroke
    grestore
   ")

[mike7, 2013-03-09 06:09:29]

On 9 mars 2013, at 00:15, thomasmorley65@googlemail.com wrote:

> Hi Mike,
> 
> one thought.
> 
> The image Trevor Bača posted
> http://lists.gnu.org/archive/html/lilypond-user/2013-03/pngIGBdggySyh.png
> shows that the left ends of a decrecsendo-hairpin are vertical aligned
> even if the hairpin isn't extended horizontal but ascending.
> Currently the vertical alignment is gone if the hairpin is rotated, and,
> afaik, this is the only way an ascending hairpin is available (apart
> from constructing a new one from scratch).
> 
> (Similiar for cresc-hairpins.)
> 
> Is it possible to extend your code to achieve this?
> Might be an interesting feature for common hairpins as well.
> 
> Since I don't know of I explained myself well enough, here some
> markup-code which mimics it:
> 
> #(define drag-hairpin 5) % try different values
> 
> \markup
>  \postscript
>  #(string-append
>  "
>    0 1.5 moveto
>    0.5 -0.75 rlineto
>    15
>    "
>    (number->string (+ -0.75 drag-hairpin))
>    "
>    rlineto
> 
>    0 -1.5 moveto
>    0.5 0.75 rlineto
>    15
>    "
>    (number->string (+ 0.75 drag-hairpin))
>    "
>    rlineto
>    stroke
> 
>    % a red line to show vertical alignment:
> 
>    gsave
>    0 3 moveto
>    1 0 0 setrgbcolor
>    0 -6 rlineto
>    stroke
>    grestore
>   ")
> 
> 
> 
> 
> 
> 
> https://codereview.appspot.com/7615043/

 Hey Harm,

I think it's worth adding an issue to the tracker for this. You can make a
minimal example with the hairpins in current master.

Cheers,
MS

[MikeSol, 2013-03-09 06:38:03]

Uses two spaces after full stop

[MikeSol, 2013-03-09 06:43:28]

https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm#newcode929
scm/output-lib.scm:929: form. @code{x} is the portion of the width consumed for
a given line
On 2013/03/08 06:26:29, lemzwerg wrote:
> Please use two spaces after a full stop.

Done.

[thomasmorley65, 2013-03-10 00:47:51]

Hi Mike,

decrescendo doesn't work!!

My idea about "drag-hairpin" seems not too hard to implement, ofcourse there
would be need to do a clean definition of the property, currently LilyPond
returns a unsurprisingly warning:


#(define-public ((elbowed-hairpin coords mirrored?) grob)

 (define (normalize-coords cords x y)
    (map
      (lambda (coord)
         (list (* x (car coord)) (* y (cdr coord))))
      coords))

 (define (my-c-p-s points)
 ;; !!!!!!!!!!!!!!!!!!
   (let ((drag-hairpin (ly:grob-property grob 'drag-hairpin 0)))
   (set! points 
         (map (lambda (c) (list (car c) (+ drag-hairpin (cadr c)))) points))
 ;; !!!!!!!!!!!!!!!!!!
    (make-connected-path-stencil
      points
      0.1
      1.0
      1.0
      #f
      #f)))

 (let* ((sten (ly:hairpin::print grob))
        (xex (ly:stencil-extent sten X))
        (lenx (interval-length xex))
        (yex (ly:stencil-extent sten Y))
        (leny (interval-length yex))
        (uplist (normalize-coords coords lenx (/ leny 2)))
        (downlist (normalize-coords coords lenx (/ leny -2))))
        
 (ly:stencil-translate
    (ly:stencil-add
       (my-c-p-s uplist)
       (if mirrored? (my-c-p-s downlist) empty-stencil))
    (cons (car xex) (car yex)))))

#(define-public ferneyhough-hairpin
 (elbowed-hairpin '((0.95 . 0.4) (1.0 . 1.0)) #t))

\relative c'' {
 %% !!!!!!!!!!!!!!!!!!!!!!!!!
 \override Hairpin #'drag-hairpin = #-2.2
 \override Hairpin #'stencil = #ferneyhough-hairpin
 a4\< c e a\f
}

https://codereview.appspot.com/7615043/diff/6001/input/regression/ferneyhough...
File input/regression/ferneyhough-hairpins.ly (right):

https://codereview.appspot.com/7615043/diff/6001/input/regression/ferneyhough...
input/regression/ferneyhough-hairpins.ly:10: a4\< a a a\f
Please test decrescendo, too.

https://codereview.appspot.com/7615043/diff/6001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7615043/diff/6001/scm/output-lib.scm#newcode1032
scm/output-lib.scm:1032: #(define simple-hairpin
It's not clear to me why you give _this_ example.

https://codereview.appspot.com/7615043/diff/6001/scm/output-lib.scm#newcode1067
scm/output-lib.scm:1067: (define-public ferneyhough-hairpin
This defines a crescendo-hairpin for _all_ cases, even for
{ c\> d\! }
!!

[mike7, 2013-03-10 07:16:23]

On 10 mars 2013, at 01:47, thomasmorley65@googlemail.com wrote:

> Hi Mike,
> 
> decrescendo doesn't work!!

Yikes!  Will fix.  Thanks for spotting this.

> 
> My idea about "drag-hairpin" seems not too hard to implement, ofcourse
> there would be need to do a clean definition of the property, currently
> LilyPond returns a unsurprisingly warning:

I see what you're saying, but this is a more general issue about Hairpin
rotation and non-linear DynamicLineSpanners that should be addressed
conceptually as a separate issue.  However, it is an excellent idea and I'd be
happy to work on it at some point later down the line.

Cheers,
MS

[MikeSol, 2013-03-10 17:06:23]

Decrescendos

[thomasmorley65, 2013-03-11 23:38:17]

Hi Mike,

sorry to have some more nit-picks.

https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1051
scm/output-lib.scm:1051: 0.1
Hard-coded thickness.
Why not multiply 'thickness-property from Hairpin and 'line-thickness as usual?

https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1052
scm/output-lib.scm:1052: 1.0
I'd do the scaling here.
ly:stencil-scale would be superfluous than.

https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1077
scm/output-lib.scm:1077: (cons xtrans ytrans)))
I'm not sure ytrans is needed.
Setting it 0 seems to make no difference.
Delete and use ly:stencil-translate-axis?

[thomasmorley65, 2013-03-11 23:56:03]

On 2013/03/11 23:38:17, thomasmorley65 wrote:

>
https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1052
> scm/output-lib.scm:1052: 1.0
> I'd do the scaling here.
> ly:stencil-scale would be superfluous than.

Either scaling-method will change the direction of constante-hairpin.
Is this intended?

[mike7, 2013-03-12 05:48:44]

On 12 mars 2013, at 00:38, thomasmorley65@googlemail.com wrote:

> Hi Mike,
> 
> sorry to have some more nit-picks.
> 
> 
> https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm
> File scm/output-lib.scm (right):
> 
>
https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1051
> scm/output-lib.scm:1051: 0.1
> Hard-coded thickness.
> Why not multiply 'thickness-property from Hairpin and 'line-thickness as
> usual?

Good call!

> 
>
https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1052
> scm/output-lib.scm:1052: 1.0
> I'd do the scaling here.
> ly:stencil-scale would be superfluous than.

I'll try it out.

> 
>
https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1077
> scm/output-lib.scm:1077: (cons xtrans ytrans)))
> I'm not sure ytrans is needed.
> Setting it 0 seems to make no difference.
> Delete and use ly:stencil-translate-axis?

I'm not sure if it makes a difference either. The idea is that, conceptually, we
want the stencil to have the same translation as the original (which is always 0
for now). If that changes in the hairpin print function, we want that to change
in this function as well.

Cheers,
MS

[MikeSol, 2013-03-12 15:25:28]

Addresses Harm's comments

[janek, 2013-03-12 23:02:31]

Nice hairpins!

Janek

https://codereview.appspot.com/7615043/diff/23001/input/regression/ferneyhoug...
File input/regression/ferneyhough-hairpins.ly (right):

https://codereview.appspot.com/7615043/diff/23001/input/regression/ferneyhoug...
input/regression/ferneyhough-hairpins.ly:4: texidoc = "LilyPond creates hairpins
found in Ferneyhough scores.
Please be more specific - a user might not know what Ferneyhough scores look
like.
For example, add "There are two variants of Ferneyhough hairpins: one is
horizontal for its whole length with short vertical line at the end that is
louder, and another one is similar to ordinary hairpin except that its width
doesn't change evenly - it's narrower with a wide opening at the end"

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#newcode1030
scm/output-lib.scm:1030: and draws the stencil based on its coordinates.
I really like this description.  It's so good that i immediately knew how the
output will look like before i compiled it - congrats!

[janek, 2013-03-12 23:23:06]

hi all,

On Sat, Mar 9, 2013 at 12:15 AM,  <thomasmorley65@googlemail.com> wrote:
> The image Trevor Bača posted
> http://lists.gnu.org/archive/html/lilypond-user/2013-03/pngIGBdggySyh.png
> shows that the left ends of a decrecsendo-hairpin are vertical aligned
> even if the hairpin isn't extended horizontal but ascending.
> Currently the vertical alignment is gone if the hairpin is rotated, and,
> afaik, this is the only way an ascending hairpin is available (apart
> from constructing a new one from scratch).
>
> (Similiar for cresc-hairpins.)
>
> Is it possible to extend your code to achieve this?
> Might be an interesting feature for common hairpins as well.

this reminds me of an idea i had that would probably play nicely with this:
make it possible to manipulate hairpins' ends separately.
The point would be that you could specify a vertical offset for one
end and thus easily achieve a slanted hairpin (without going into
hassle of figuring out rotation angle, doing trigonometry etc).

best,
Janek

[mike7, 2013-03-13 08:35:55]

On 13 mars 2013, at 00:02, janek.lilypond@gmail.com wrote:

> Nice hairpins!
> 
> Janek
> 
> 
>
https://codereview.appspot.com/7615043/diff/23001/input/regression/ferneyhoug...
> File input/regression/ferneyhough-hairpins.ly (right):
> 
>
https://codereview.appspot.com/7615043/diff/23001/input/regression/ferneyhoug...
> input/regression/ferneyhough-hairpins.ly:4: texidoc = "LilyPond creates
> hairpins found in Ferneyhough scores.
> Please be more specific - a user might not know what Ferneyhough scores
> look like.
> For example, add "There are two variants of Ferneyhough hairpins: one is
> horizontal for its whole length with short vertical line at the end that
> is louder, and another one is similar to ordinary hairpin except that
> its width doesn't change evenly - it's narrower with a wide opening at
> the end"
> 

(ccing Trevor) Obviously I want the name that is the most appropriate for the
object.  Trevor, having suggested it, may know what it is called in
Anglo-American contemporary music circles (I like "flairpin" :)

Once we decide on a name, I'll add this to the texidoc.

Cheers,
MS

[thomasmorley65, 2013-03-13 21:38:59]

Hi Mike,

sorry to be such an inch pincher.

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?

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

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.

Look at the output from:

dimMolto = 
#(make-dynamic-script (markup #:normal-text #:italic "dim. molto"))

\relative c'' {
  \dynamicUp
  \override Hairpin #'stencil = #constante-hairpin
  a1 a4\dimMolto\> a a a\!
}

The "hook" is placed at the left pointing up.

Wouldn't it be better to have the hook _always_ at the right?
Perhaps by adding a boolean variable to `my-c-p-s´. Doing scaling only while
(and scalable? decresc?).

Is it possible to make the hook-direction depending on the position of the
Hairpin i.e below or above the staff?

[MikeSol, 2013-03-17 07:27:37]

On 2013/03/13 21:38:59, thomasmorley65 wrote:
> Hi Mike,
> 
> sorry to be such an inch pincher.
> 
> 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!

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

>
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.
> 
> Look at the output from:
> 
> dimMolto = 
> #(make-dynamic-script (markup #:normal-text #:italic "dim. molto"))
> 
> \relative c'' {
>   \dynamicUp
>   \override Hairpin #'stencil = #constante-hairpin
>   a1 a4\dimMolto\> a a a\!
> }
> 
> The "hook" is placed at the left pointing up.
> 
> Wouldn't it be better to have the hook _always_ at the right?
> Perhaps by adding a boolean variable to `my-c-p-s´. Doing scaling only while
> (and scalable? decresc?).
> 
> Is it possible to make the hook-direction depending on the position of the
> Hairpin i.e below or above the staff?

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

[MikeSol, 2013-03-17 07:29:34]

Response to Harm's comments

[thomasmorley65, 2013-03-17 12:36:56]

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

[mike7, 2013-03-17 12:42:02]

On 17 mars 2013, at 13:36, thomasmorley65@googlemail.com 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,

[thomasmorley65, 2013-03-17 14:37:52]

On 2013/03/17 12:42:02, mike7 wrote:

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

Sure.
Or in 
(define (my-c-p-s ...
as it is done for `decresc?´

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

The only Ferneyhough-score I've at home prints the dynamics always below the
system.
("Cassandra's Dream Song" for Solo Flute, Edition Peters, 1975)
Perhaps ask on the user-list.

> Thanks for the review!

You're welcome.
Most of your patches are work with C++, which I don't know.
Since the current one provides some very nice feature using scheme, I had a
closer look.
Perhaps you noticed that I already used this approach to answer an
user-question.

[Joseph Rushton Wakeling, 2013-03-17 16:25:55]

On 2013/03/17 14:37:52, thomasmorley65 wrote:
> > 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.
> 
> The only Ferneyhough-score I've at home prints the dynamics always below the
> system.

There are Ferneyhough scores with dynamics above the staff -- some of the piano
works (e.g. Lemma-Icon-Epigram), and some of the vocal works.  See e.g. the
second movement of his 4th String Quartet which has a part for soprano:
http://www.youtube.com/watch?v=hVaDOz7bWU0

In this you see flared hairpins above the staff, and also dynamic brackets above
the staff (e.g. at about 1:33 where there's a great long ffff bracket above the
soprano part).

The more general remark is that even if Ferneyhough did only place his dynamic
markings below the staff, you couldn't assume that would remain true of all
composers wanting to use Ferneyhough-like dynamic indicators in their scores :-)

Final remark: while it's nice to see Ferneyhough getting namechecked might it be
worth naming this alteration as flared-hairpin rather than ferneyhough-hairpin?

[mike7, 2013-03-17 16:28:11]

On 17 mars 2013, at 17:25, joseph.wakeling@gmail.com wrote:

> 
> 
> Final remark: while it's nice to see Ferneyhough getting namechecked
> might it be worth naming this alteration as flared-hairpin rather than
> ferneyhough-hairpin?

My suggestion was flairpin, which is infinitely cheesier and thus way cooler.

Cheers,
MS

[Joseph Rushton Wakeling, 2013-03-17 16:30:55]

On 03/17/2013 05:28 PM, mike@mikesolomon.org wrote:
> My suggestion was flairpin, which is infinitely cheesier and thus way cooler.

I know, but ... at the end of the day, less clear in meaning than either
ferneyhough-hairpin or flared-hairpin.  Sad but IMO true. :-P

[Joseph Rushton Wakeling, 2013-03-17 16:46:48]

On a related issue: one thing that's probably clear looking at Ferneyhough
scores is the way in which the vertical placement of hairpin endpoints is
strongly coupled with the vertical placement of dynamic marks.

I don't think it's really appropriate to bundle all of this together into one
feature request, but it would probably be useful as a complementary feature
request to do some re-evaluation of Lilypond's vertical placement of hairpin
end-points, and whether it's possible to automate the placement of angled
hairpins so as to optimize the relative positions of hairpin start- and
endpoints and nearby dynamic marks.

N.B. this is useful for all music, not just Ferneyhough.  It's a fairly
consistent bugbear of mine that hairpin start- and endpoints are not better
placed relative to dynamic marks.

I think this has already been touched on to an extent in the discussion above
... ?

[mike7, 2013-03-17 17:32:53]

On 17 mars 2013, at 17:46, joseph.wakeling@gmail.com wrote:

> On a related issue: one thing that's probably clear looking at
> Ferneyhough scores is the way in which the vertical placement of hairpin
> endpoints is strongly coupled with the vertical placement of dynamic
> marks.
> 
> I don't think it's really appropriate to bundle all of this together
> into one feature request, but it would probably be useful as a
> complementary feature request to do some re-evaluation of Lilypond's
> vertical placement of hairpin end-points, and whether it's possible to
> automate the placement of angled hairpins so as to optimize the relative
> positions of hairpin start- and endpoints and nearby dynamic marks.
> 
> N.B. this is useful for all music, not just Ferneyhough.  It's a fairly
> consistent bugbear of mine that hairpin start- and endpoints are not
> better placed relative to dynamic marks.
> 
> I think this has already been touched on to an extent in the discussion
> above ... ?
> 
> https://codereview.appspot.com/7615043/

It's more swingable now that skylines are based on stencils for many grobs
instead of extents.
This is the sorta thing I know how to do but that'd take a while.
If you can open a tracker issue w/ the full request, I'll try to get to it (I
have some time next week and then again in late April).

Cheers,
MS

[thomasmorley65, 2013-03-17 17:47:51]

On 2013/03/17 16:25:55, Joseph Rushton Wakeling wrote:
> On 2013/03/17 14:37:52, thomasmorley65 wrote:

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

> There are Ferneyhough scores with dynamics above the staff -- some of the
piano
> works (e.g. Lemma-Icon-Epigram), and some of the vocal works.  See e.g. the
> second movement of his 4th String Quartet which has a part for soprano:
> http://www.youtube.com/watch?v=hVaDOz7bWU0
> 
> In this you see flared hairpins above the staff, and also dynamic brackets
above
> the staff (e.g. at about 1:33 where there's a great long ffff bracket above
the
> soprano part).

Thanks!
And while above the staff dynamic brackets have the hook down.

[Joseph Rushton Wakeling, 2013-03-18 09:54:57]

On 03/17/2013 06:47 PM, thomasmorley65@googlemail.com wrote:
> And while above the staff dynamic brackets have the hook down.

As I said before, I'd have argued for that feature even in the absence of a
Ferneyhough example, as it makes musical/notational sense.  But I think the
example settles it. :-)

[zepadovani, 2013-05-09 12:52:24]

Not sure if it was already mentioned...

just installed 2.17.17 and it seems that the new (and nice!) angled hairpins are
not compatible with the circled tip:

\once \override Hairpin #'circled-tip = ##t %%doesn't work
\once \override Hairpin #'stencil = #flared-hairpin
g4\< ~ g4 ~ g8\f

On 2013/03/18 09:54:57, Joseph Rushton Wakeling wrote:
> On 03/17/2013 06:47 PM, mailto:thomasmorley65@googlemail.com wrote:
> > And while above the staff dynamic brackets have the hook down.
> 
> As I said before, I'd have argued for that feature even in the absence of a
> Ferneyhough example, as it makes musical/notational sense.  But I think the
> example settles it. :-)
>

[Joseph Rushton Wakeling, 2013-05-09 14:01:51]

On 05/09/2013 02:52 PM, zepadovani.lists@gmail.com wrote:
> just installed 2.17.17 and it seems that the new (and nice!) angled
> hairpins are not compatible with the circled tip

I think this should be considered a bug, as the two notations are clearly
compatible.