bug-lilypond
[Top][All Lists]
Advanced

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

bug report: partcombine and multi-measure rests


From: Gilberto Agostinho
Subject: bug report: partcombine and multi-measure rests
Date: Wed, 14 Oct 2015 21:15:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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


reply via email to

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