Add a procedure to add slashes to Beams and straight Flags

Add a procedure to add slashes to Beams and straight Flags

Adds procedure slash-stencil to stencil.scm
Replaces add-stroke-straight from flag-styles.scm with slash-stencil.
Amends defs in grace-init.ly with slashedBeam.
Amends Beam.details. Creates Flag.details.
Documentation and regtest.

[thomasmorley651, 2019-03-10 13:13:51]

Please review

[thomasmorley651, 2019-03-10 13:37:42]

Oversights

[thomasmorley651, 2019-03-10 17:07:07]

Better deal with changed fontsizes

[Valentin Villenave, 2019-03-10 17:08:33]

On 2019/03/10 13:37:42, thomasmorley651 wrote:
> Oversights

Greetings Harm,
looks good; much better than the hack I had previously suggested about #1333. 
However, you’re using a somewhat similar approach (although much more
fine-tuned) by overriding the stencil rather than creating an independent grob
for the slash; therefore some of the objections from Neil and Carl may also
apply here:
https://codereview.appspot.com/3169041/#msg5

I personally have no objection about it, though.

Cheers,
V.

[thomasmorley651, 2019-03-10 18:02:04]

On 2019/03/10 17:08:33, Valentin Villenave wrote:
> On 2019/03/10 13:37:42, thomasmorley651 wrote:
> > Oversights
> 
> Greetings Harm,
> looks good; much better than the hack I had previously suggested about #1333. 
> However, you’re using a somewhat similar approach (although much more
> fine-tuned) by overriding the stencil rather than creating an independent grob
> for the slash; therefore some of the objections from Neil and Carl may also
> apply here:
> https://codereview.appspot.com/3169041/#msg5
> 
> I personally have no objection about it, though.
> 
> Cheers,
> V.

Hi Valentin,

I considered creating a Slash-grob, but I think it would have been even more
work. ;)
Furthermore, if it would be up to me I'd do it in scheme. C++ would be better, I
suppose, though C++ is out of my depth.

Doing a stencil-override I feel much more to be in my league. 

Ofcourse beams in acciaccatura are now always slashed, as requested in #1333.
This is a design-decision and ofcourse we have appoggiatura.
I added a plethora of possibilities for customizations. If the settings of the
slash and current Flag/Beam will cause bad output, a warning is done, with a
hint what to do. It now deals nicely with changed fontsizes, as far as I can
tell.
So I'm pretty sure it (mostly) does what is promised.

I wrote 'mostly' because there is a little inaccuracy. See one of the TODOs in
slash-stencil. Any hint here would be great.

I'm more concerned about the coding style.
I do Flag and Beam in one go, would it be better to split it in a (cond (Flag
...)(Beam...) (else ...)) ?

Btw, I stumbled over it while patching straight-flag. There is/was a function
doing such slashes. It was a poor one, only for straight flags, and buggy as
soon as unusual angles were provided for straight-flag.
Though, straight flags are similar to beams in some regard. Thus the attempt to
do all in one.

[thomasmorley651, 2019-03-10 19:26:26]

correct changes.tely

[Carl, 2019-03-11 01:21:25]

LGTM

[thomasmorley651, 2019-03-11 23:11:49]

Improve some doc-strings

[Malte Meyn, 2019-03-16 20:42:12]

Here’s some test music:

\version "2.21.0"
\language "deutsch"

\relative {
  %%% looks better than 1/1 IMHO:
  \override Beam.details.slash-gradient = 3/4
  
  %%% default = 1 good for most, but not for some short stems (m. 3, m. 6)
  %\override Beam.details.slash-stem-part = 0.6
  
  %%% has complicated name and it’s not clear why y has to be larger than x
  %%% maybe better “slash-overshoot”?
  \override Beam.details.slash-x-y-over-shoot = #'(0.3 . 0.6)
  
  \acciaccatura { c''16 d } e2
  \acciaccatura { c16 d e f } e2
  \acciaccatura { c16 d e f g a } e2
  \acciaccatura { c16 h } e2
  \acciaccatura { c16 h a g } e'2
  \acciaccatura { c16 h a g f e } e'2
  
  \acciaccatura { c8 d } e2
  \acciaccatura { c8 d e f } e2
  \acciaccatura { c8 d e f g a } e2
  \acciaccatura { c8 h } e2
  \acciaccatura { c8 h a g } e'2
  \acciaccatura { c8 h a g f e } e'2
  
  \acciaccatura { c32 d } e2
  \acciaccatura { c32 d e f } e2
  \acciaccatura { c32 d e f g a } e2
  \acciaccatura { c32 h } e2
  \acciaccatura { c32 h a g } e'2
  \acciaccatura { c32 h a g f e } e'2
}

https://codereview.appspot.com/562550043/diff/564540043/ly/grace-init.ly
File ly/grace-init.ly (right):

https://codereview.appspot.com/562550043/diff/564540043/ly/grace-init.ly#newc...
ly/grace-init.ly:24: \temporary \override Flag.stroke-style = "grace"
If we have \slashedBeam, we might want another shortcut \slashedFlag.

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:408: (slash-stem-part . 1)
It’s not that easy in some cases, see example code below.

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:409: (slash-gradient . (1 . 2))
IMHO that’s to steep, I’d prefer something like '(3 . 4)

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:410: (slash-x-y-over-shoot . (0.4 . 0.8))
I don’t really understand how this works: Why does one need a so much larger y
value? The result doesn’t look like the slash sticks out further at the top than
at the left side.

Also, that’s a really complicated name, how about something simpler (maybe
slash-overshoot)?

[Malte Meyn, 2019-03-16 20:42:42]

On 2019/03/16 20:42:12, Malte Meyn wrote:
> It’s not that easy in some cases, see example code below.

That should be “example code above”.

[Malte Meyn, 2019-03-16 20:44:19]

another small remark

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:409: (slash-gradient . (1 . 2))
On 2019/03/16 20:42:11, Malte Meyn wrote:
> IMHO that’s to steep, I’d prefer something like '(3 . 4)

Also, wouldn’t it be simpler (for the user) to use a number here instead of a
pair? #3/4 or 0.75 instead of #'(3 . 4)

[thomasmorley651, 2019-03-17 10:29:59]

Hi Malte,

thanks for review.

Currently I follow a different route: create a Slash-grob.
Once it is mature I'll publish a concurrent patch-set in a different issue.
For now I'll set this one back to 'needs-work'.
However you spotted some valid points, which I'll likely have to take into
account for a possible Slash.stencil as well.

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:408: (slash-stem-part . 1)
On 2019/03/16 20:42:11, Malte Meyn wrote:
> It’s not that easy in some cases, see example code below.

Yep, it's quite impossible to find a fixed default number-value which looks nice
in all cases, thus I made it a overridable (sub-)property.
Should I try to find some procedure looking at the actual stem-length and set
slash-stem-part accordingly?
Wouldn't it be over-engineered?

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:409: (slash-gradient . (1 . 2))
On 2019/03/16 20:44:19, Malte Meyn wrote:
> On 2019/03/16 20:42:11, Malte Meyn wrote:
> > IMHO that’s to steep, I’d prefer something like '(3 . 4)
> 
> Also, wouldn’t it be simpler (for the user) to use a number here instead of a
> pair? #3/4 or 0.75 instead of #'(3 . 4)

This is one of the TODO's in 'slash-stencil'.
Possible would be pair, fraction, number or even an angle.
I'd love to read more opinions about it.

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:409: (slash-gradient . (1 . 2))
On 2019/03/16 20:42:11, Malte Meyn wrote:
> IMHO that’s to steep, I’d prefer something like '(3 . 4)

Well, a matter of taste I'd say. The slash for beams needs to be more steep in
most cases (compared to slashed default-flags).
I'll take your suggestion and do some tests.

https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#...
scm/define-grobs.scm:410: (slash-x-y-over-shoot . (0.4 . 0.8))
On 2019/03/16 20:42:11, Malte Meyn wrote:
> I don’t really understand how this works: Why does one need a so much larger y
> value? The result doesn’t look like the slash sticks out further at the top
than
> at the left side.

The x-value does not need to look at beam's gradient as opposed to the y-value.
Tbh, I didn't care much about this problem after finding some working code.
Though, you stumbled across it and maybe you will not be the only one. I'll look
how to improve it.
> 
> Also, that’s a really complicated name, how about something simpler (maybe
> slash-overshoot)?

I'll delete the dash in 'over-shoot' according to the existing 'break-overshoot'
Though, looking at other related properties like the already mentioned
'break-overshoot' or 'shorten-pair', those pairs always work in one axis'
direction. I wanted to make clear those values serve different directions.
Again, I'd love to hear more opinions.