Hi Jay,
On 2016-12-24 08:24, Jay Anderson wrote:
On Fri, Dec 23, 2016 at 2:30 PM, Alexander Kobel <a-ko...@a-kobel.de> wrote:
it seems that there is some interest in integrating your scheme engraver for
merged rests into Lilypond core. Do you mind this idea? If not, are you
interested in submitting a patch for review yourself, or do you want someone
to take care of it?
That'd be great as long as its behavior is acceptable for general use
and it has a few regression tests. I believe there were still some
outstanding questions around killing some of the rest grobs (the
solution I had was to overlap them).
that's great to hear. To be honest, I did not try your code live yet; I
only heard about it recently, and used the snippet in
http://lsr.di.unimi.it/LSR/Item?id=336 for a while. It is less flexible
in terms of number of voices, and it does not deal with multi-measure
rests, so your approach seems preferable.
On the other hand, the author included a selection of the "best-scoring"
rest to keep (which, AFAICS, is somewhat arbitrary). I assume that won't
solve the following problem...
Any attached text would need to be re-parented to the surviving
grob.
... but maybe some of the ideas in the other snippet could help
nevertheless.
That said, I don't think handling this will affect the ending result
of what's visible on the page. It's a performance/cleanliness issues
which could be fixed later.
Indeed. Expected crashes would be highly undesirable for core
functionality, so I'd vote for keeping it simple and sufficient.
The difference should not be visible in ordinary circumstances. The only
remote possibility where I can see this failing: merging normal voices
and cue voices (or some other voice with non-standard appearance, in
particular w.r.t. font size). But this could be mentioned as known
limitation and should not prevent including the functionality.
I'm not sure I'm up for getting the patch through (I've never gone
through the process). I'll most likely have some next week time to
refresh my memory how it works, clean it up, document it, and create
some tests. Beyond that I'd need some guidance.
That'd be a warmly welcome. For me, already the alternative approach did
wonders despite its restrictions.
Just a few days ago, I went through the patch upload procedure for the
first time since years. Main hindrance: you need logins on Rietveld (aka
codereview.appspot.com) for uploading the patch for review and,
optionally, on SourceForge for the issue tracker. The first one has to
be a Google account, but judging from your mail address, that won't be
the issue.
Everything else is standard git usage, plus a support script called
git-cl that manages the uploads to the code review server. No rocket
science for someone who used git before.
Cheers,
Alexander
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user