Re: bug report: partcombine and multi-measure rests

[Gilberto Agostinho]

Hi Simon,

Thanks for the reply. I am not sure I understand your answer, do you 
mean that in the tiny example I created I should simply have used a 
"Solo I" indication in the fourth bar instead of using rests? If that's 
the case, then I disagree with you that would be a better solution than 
rests, as using a Solo indication for a single note before a polyphonic 
bar looks very bad to my eyes, and I have seen this type of notation I 
used in the tiny example (of using rests instead of Solo indication) in 
plenty of scores. But more fundamentally, I simply think this should be 
a decision of the person engraving.

So regardless of notational preferences, I think we both can agree that 
partcombiner should be able to deal with R1*N type of notation. As you 
yourself wrote in the forum:

> I’d say that the partcombiner should be able to deal with this. It’s
> inappropriate to change the input code of either of the voices to make
> up for deficiencies of the partcombiner – at least if you should need to
> print both separately, and that’s part of the point in using 
\partcombine.

Best,
Gilberto

On 17/10/15 20:30, Simon Albrecht wrote:
> Hello Gilberto,
>
> sorry for the late answer.
> If this were a bug, it would be an instance of 
> <https://sourceforge.net/p/testlilyissues/issues/100/>. But I don’t 
> think there is a point in showing these rests in a partcombined voice. 
> After all, there is a ‘Solo I’ indication showing that the second 
> voice is silent.
>
> Yours, Simon
>
> On 14.10.2015 21:15, Gilberto Agostinho wrote:
> > Hello all,
> >
> > I get strange results when I change the type of \partcombine (for 
> > instance, using \partcombineApart) when one of the parts is in the 
> > middle of a several bars long multi-measure rest:
> >
> > http://lilypond.1069038.n5.nabble.com/file/n182372/39.png
> >
> > code:
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >
> > \version "2.19.15"
> >
> >
> > partA = \relative c'' {
> >
> > c1 |
> >
> > R1*2 |
> >
> > \partcombineApart r2 b2~ |
> >
> > b1 |
> >
> > \partcombineAutomatic c1 |
> >
> > }
> >
> >
> > partB = \relative c' {
> >
> > f1 |
> >
> > R1*2 |
> >
> > R1*2 |
> >
> > f1 |
> >
> > }
> >
> >
> > partBalternative = \relative c' {
> >
> > f1 |
> >
> > R1*4 |
> >
> > f1 |
> >
> > }
> >
> >
> > \markup {"When the bottom part has the bar rests divided into two 
> > groups (exactly were \partcombineApart takes" }
> >
> > \markup {"place) of R1*2, the rests below the b2~b1 are properly 
> > displayed:"}
> >
> > {\partcombine \partA \partB}
> >
> >
> > \markup {"Now when the rests are combined into a single R1*4, the 
> > rests below b2~b1 are not displayed at all:"}
> >
> > {\partcombine \partA \partBalternative}
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > <http://lilypond.1069038.n5.nabble.com/file/n182372/partbug.ly>
> > Exchanging R1*N by \repeat N R1 solves the problem, but has the side 
> > effect of influencing \compressFullBarRests.
> >
> > There was a discussion in our forum in the following link: 
> > lilypond.1069038.n5.nabble.com/partcombine-and-multi-measure-rests-td182372.html
> >
> > Cheers,
> > Gilberto
> > _______________________________________________
> > bug-lilypond mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/bug-lilypond