Re: Rests in polyphonic and simple music in the same staff in LilyPond version 2.18.2.

[Alexander Kobel]

Hi Jay,

On 2016-12-24 08:24, Jay Anderson wrote:
> On Fri, Dec 23, 2016 at 2:30 PM, Alexander Kobel <address@hidden> 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