[Top][All Lists]

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

Re: bug report: partcombine and multi-measure rests

From: Gilberto Agostinho
Subject: Re: bug report: partcombine and multi-measure rests
Date: Sun, 18 Oct 2015 13:25:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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.


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:




\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}

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

bug-lilypond mailing list

reply via email to

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