Thanks! This is quite helpful!
IX, Josh On Wed, Jul 15, 2015 at 6:16 PM, David Kastrup <d...@gnu.org> wrote: > Joshua Nichols <josh.d.nich...@gmail.com> writes: > > >> On Sun, Jul 5, 2015 at 5:26 PM, David Kastrup <d...@gnu.org> wrote: > >> > >>> David Kastrup <d...@gnu.org> writes: > >>> > >>> > Joshua Nichols <josh.d.nich...@gmail.com> 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 >
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
