lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with Percent repeats


From: David Kastrup
Subject: Re: Problem with Percent repeats
Date: Thu, 16 Jul 2015 00:16:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Joshua Nichols <address@hidden> writes:

>> On Sun, Jul 5, 2015 at 5:26 PM, David Kastrup <address@hidden> wrote:
>>
>>> David Kastrup <address@hidden> writes:
>>>
>>> > Joshua Nichols <address@hidden> writes:
>>> >
>>> >> I absolutely sent the wrong example. This is my work around for right 
>>> >> now,
>>> >> here below, and re-attached, is the example I'm having trouble with.
>>> >
>>> > Ok, here's the deal: percent repeats don't work with changed time
>>> > signatures.  The problem is that a change in time signature is effected
>>> > by a context property change while typesetting, and the percent repeat
>>> > _iterator_ starts making decisions at the time it encounters the \repeat
>>> > percent which is earlier.
>>> >
>>> > That's stupid.  It's also the same problem as issue 3693
>>> > <URL:https://code.google.com/p/lilypond/issues/detail?id=3693>.
>>>
>>> It turns out that emulating the broken part is somewhat feasible.
>>>
>>>
>>>   {
>>>     \time 5/16  a16\<[ r c-> r a]
>>>     \time 4/16  c16->\! r r8 \mark \markup { \box 191 }
>>>   }
>>>   \omit\time 9/32
>>>   #(make-music 'DoublePercentEvent
>>>     'length (ly:make-moment 9/16))
>>>   #(make-music 'DoublePercentEvent
>>>     'length (ly:make-moment 9/16))
>>>
>>> There is a whole bunch wrong with that.  But the graphical output in
>>> _this_ staff (others will likely need to have the time signature made
>>> invisible as well) seems to be more or less what you want.  Maybe one
>>> can play around in order to make the input correspond a bit better with
>>> the logic.
>
> Thank you for your speedy reply and candor. I appreciate this, as now I can
> look forward to seeing improvements with an already stellar program and
> tinker with the "moment" at the same time! Thanks again!

I've uploaded a patch for issue 3693.  I consider it likely that it will
have made it through our review process before version 2.19.24 gets
released (10 days or so).

This will still not make your particular example work: the meter change
inside of the percent repeat cannot reasonably reliably be extracted and
repeated.  However, if you just put the meter changes in a parallel
passage outside of the percent repeat, stuff will then work fine.

So your particular code will still require a workaround (unless you
already have a parallel "timing track"), but the workaround is much more
straightforward than currently.

-- 
David Kastrup



reply via email to

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