lilypond-user
[Top][All Lists]
Advanced

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

Re: No R in input! (Proposal for discussion)


From: David Kastrup
Subject: Re: No R in input! (Proposal for discussion)
Date: Sun, 02 Apr 2017 22:48:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Simon Albrecht <address@hidden> writes:

> Am 02.04.2017 um 22:24 schrieb David Kastrup:
>> Simon Albrecht <address@hidden> writes:
>>> Am 02.04.2017 um 15:25 schrieb David Kastrup:
>>>> R4*7 is fundamentally different in meaning (provide 7/4 total amount of
>>>> full-measure rests) from r4*7 (a quarter rest visual with 7 times its
>>>> length).  Full-measure rests are aligned to the middle of the bar, other
>>>> rests are aligned to the beginning of the bar and/or parallel music.
>>> But does it actually demand too much of an engraver to take an r4*7
>>> event, check whether and how many full or partial measures are in its
>>> duration, write full-bar or multi-measure rests for all parts spanning
>>> full measures and normal rests for the remainder?
>> What about "is fundamentally different in meaning" was unclear?  The
>> rests have completely different visuals, not "just" different alignments
>> and different numbers of grobs.
>
> Forgive my ignorance, but I don’t know what part of this an engraver
> can’t do.

The point is not that it can't be done but that it shouldn't be done.

> Completion_rests_engraver checks for barlines and prints one or
> multiple rests depending on these. Suppose someone™ made the effort
> and folded Multi_measure_rest_engraver into Rest_engraver, why would
> such an engraver be fundamentally able to take just one type of rest
> and Do The Right Thing™, using ordinary rests or MMRs where
> appropriate?

Because it wouldn't be the right thing to change one for the other.

-- 
David Kastrup



reply via email to

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