[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 {
      (listeners ((slur-event eng ev)
                  (format #t "~a:~a~a\n"
                   (ly:context-id (ly:translator-context eng))
                    '((-1 . "_") (1 . "^") (0 . "") (() . ""))
                     (ly:event-property ev 'direction))
                    '((-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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]