[Top][All Lists]

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

Re: bug report: partcombine and multi-measure rests

From: Simon Albrecht
Subject: Re: bug report: partcombine and multi-measure rests
Date: Sun, 18 Oct 2015 14:20:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 18.10.2015 13:25, Gilberto Agostinho wrote:
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?

No, the solo indication should be created automatically by the partcombiner. It isn’t in 2.19.15, but that’s a bug fixed in 2.19.16. Is there any particular reason why you’d need to stick to that version?

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.

Actually, the NR is not clear on how \partcombineApart should behave for such passages, where one of the voices has rests; the description reads: ‘\partcombineApart and \partcombineApartOnce keep the notes as two separate voices, even if they can be combined into a chord or unison.’ (NR 1.5.2, Automatic part combining). So as I understand it the main point of your request would be the behaviour of \partcombineApart, if one voice has rests. Perhaps someone more acquainted with the topic can comment on that. It seems likely to me that there are many different policies on partcombining, and LilyPond cannot cater for them all. But I now understand why you would expect for \partcombineApart to explicitly show the rests of the silent voice.

So regardless of notational preferences, I think we both can agree that partcombiner should be able to deal with R1*N type of notation.

Which it can, and though it may not be up to your preferences, the output is unambiguous, understandable and correct.

Sorry I can’t help more. I may raise an issue though, but I’d like for someone else’s opinion before.
Yours, Simon

reply via email to

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