[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 2584 (redo 1967): please make partcombine merge slurs (issue 6
From: |
David Kastrup |
Subject: |
Re: Issue 2584 (redo 1967): please make partcombine merge slurs (issue 6294047) |
Date: |
Thu, 19 Jul 2012 07:21:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
"Keith OHara" <address@hidden> writes:
> I wasn't very clear with fragmented codereview comments below.
>
> There is one new problem, with slurs silently dropped in
> \partcombine {c''2^( d'')} {c'2( d')}
>
I used
{ \partcombine {c''2^( d'')} {c'2( d')} }
\layout {
\context {
\Voice
\consists
#(make-engraver
(listeners ((slur-event eng ev)
(format #t "~a:~a~a\n"
(ly:context-id (ly:translator-context eng))
(assoc-ref
'((-1 . "_") (1 . "^") (0 . "") (() . ""))
(ly:event-property ev 'direction))
(assoc-ref
'((-1 . "(") (1 . ")"))
(ly:event-property ev 'span-direction))))))
} }
to verify that the slurs arrive more or less as expected.
> The problem is avoided if get_property("direction") is replaced with
> get_pure_property(), but I don't like the idea of having even more
> code require understanding of "pure". Better might be to cache the
> first explicit direction on a slur-start-event this time-step.
Sounds quite like the easiest solution. A Drul array of booleans for
registering when an explicit direction has been seen. Or simply up_seen
and down_seen. Or something.
> Another solution is to do what version 2.14 did and ignore all but the
> first slur-start-event we see (but keep the new more intelligent
> filter for warnings).
That would mean that the direction of the resulting slur would depend on
the order of events, basically making it more random than desirable.
--
David Kastrup