[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
- No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/01
- Re: No R in input! (Proposal for discussion), David Kastrup, 2017/04/01
- Re: No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/01
- Re: No R in input! (Proposal for discussion), Graham King, 2017/04/02
- Re: No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/02
- Re: No R in input! (Proposal for discussion), David Kastrup, 2017/04/02
- Re: No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/02
- Re: No R in input! (Proposal for discussion), David Kastrup, 2017/04/02
- Re: No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/02
- Re: No R in input! (Proposal for discussion),
David Kastrup <=
- Re: No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/02
- Re: No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/02
- Re: No R in input! (Proposal for discussion), David Kastrup, 2017/04/02
- Re: No R in input! (Proposal for discussion), Noeck, 2017/04/02
- Re: No R in input! (Proposal for discussion), Simon Albrecht, 2017/04/03
- Re: No R in input! (Proposal for discussion), David Kastrup, 2017/04/03
- Re: No R in input! (Proposal for discussion), Kieren MacMillan, 2017/04/03
- Re: No R in input! (Proposal for discussion), David Kastrup, 2017/04/03
- Re: No R in input! (Proposal for discussion), Kieren MacMillan, 2017/04/03
- Re: No R in input! (Proposal for discussion), David Kastrup, 2017/04/03