Hi David,
On 26.06.2012 20:27, David Nalesnik wrote:
Hi Jan-Peter,
First of all, I agree with David Kastrup that this is a situation
where a deep fix is in order so that simultaneous ties may be tweaked
directly.
+1
In my short test, I thought of having tie-configuration and shape
combined, so that one can set the direction of the ties, before
shaping them. The downside is, that using this also needs the
staff-positions to be set - so I doubt, this is useful:
This is a useful combination, and setting staff-positions really isn't
all _that_ inconvenient since you can include a "non-entry" for
default ties. I'm delighted to see that overrides of the two work
together! It's nice to be able to group both functionalities into one
command.
Glad to hear it ;-)
One question I have here with your formulation concerns the way you've
expanded the overrides. Why not use #{ . . . }# syntax here? The
only drawback I see is that dollar-signs would be needed with 2.14. I
don't see any issues in 2.15.40 with the replacement I've done below:
--snip--
confShapeTieColumn =
#(define-music-function (parser location conf all-offsets)(list?
list?)
(let ((alb-func (lambda (grob)
(let ((ties (ly:grob-array->list
(ly:grob-object grob 'ties))))
(for-each
(lambda (tie offsets-for-broken-pair)
(let* ((orig (ly:grob-original tie))
(siblings (ly:spanner-broken-into
orig)))
(for-each
(lambda (piece offsets-for-piece)
(if (pair? offsets-for-piece)
(set! (ly:grob-property piece
'control-points)
(map
(lambda (x y)
(coord-translate x y))
(ly:tie::calc-control-points piece)
offsets-for-piece))
))
(if (null? siblings)
(list orig)
siblings)
offsets-for-broken-pair)))
ties all-offsets)))
))
#{
\once \override TieColumn #'tie-configuration = #conf
\once \override TieColumn #'after-line-breaking = #alb-func
#}))
You're absolutely right, these two overrides are a lot easier to read in
#{#}-lily-syntax. I sometimes use the scheme-way, if I want the location
variable to be the one from this function and not the one from the
#{#}-block. But for this case, it does not make so much sense ;-)
Best, Jan-Peter
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
