Add a procedure to add slashes to Beams and straight Flags

scm/define-grobs.scm

Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index d17940764b21e6a5c9ed14618b7180a361bfceed..6738f8c12d46d457a59a5d48a714372aa4c0e789 100644
--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
@@ -403,7 +403,12 @@
            (ideal-slope-factor . 10)
            (collision-penalty . 500)
            (collision-padding . 0.35)
-           (round-to-zero-slope . 0.02)))
+           (round-to-zero-slope . 0.02)
+           (slash-attach-side . left)
+           (slash-stem-part . 1)

[Malte Meyn, 2019/03/16 20:42:11]

It’s not that easy in some cases, see example code below.

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

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?

+           (slash-gradient . (1 . 2))

[Malte Meyn, 2019/03/16 20:42:11]

IMHO that’s to steep, I’d prefer something like '(3 . 4)

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

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]

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.

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

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.

+           (slash-x-y-over-shoot . (0.4 . 0.8))

[Malte Meyn, 2019/03/16 20:42:11]

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

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

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

+           (slash-thickness . 0.15)))
         (direction . ,ly:beam::calc-direction)
 
         (normalized-endpoints . ,ly:spanner::calc-normalized-endpoints)
@@ -997,6 +1002,13 @@
                          X 'transparent))
         (color . ,(grob::inherit-parent-property
                    X 'color))
+        (details
+         . (
+            (slash-attach-side . left)
+            (slash-stem-part . 0.8)
+            (slash-gradient . (1 . 1.2))
+            (slash-x-y-over-shoot . (0.4 . 0.4))
+            (slash-thickness . 0.15)))
         (X-extent . ,ly:flag::width)
         (X-offset . ,ly:flag::calc-x-offset)
         (Y-offset . ,(ly:make-unpure-pure-container ly:flag::calc-y-offset ly:flag::pure-calc-y-offset))