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

2017-04-03 Thread Simon Albrecht
Am 03.04.2017 um 17:08 schrieb David Kastrup: The full-measure rest thing would fit that engraver [Completion_rests_engraver] and its niche as another option. This makes a great deal of sense, since I’m using Completion_heads_engraver already (for splitting notes at barlines, which in a barl

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

2017-04-03 Thread David Kastrup
Kieren MacMillan writes: > Hi David, > >> Completion_rest_engraver is there. > > Ah! Sorry I didn’t think to look. I guess this thread made me assume > it must not exist. > >> It doesn't change r into R. > > So this is the point of discussion/contention? > > Okay, so… > > SNIPPET BEGINS > {

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

2017-04-03 Thread Wols Lists
On 02/04/17 21:24, David Kastrup wrote: >> 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 f

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

2017-04-03 Thread Kieren MacMillan
Hi David, > Completion_rest_engraver is there. Ah! Sorry I didn’t think to look. I guess this thread made me assume it must not exist. > It doesn't change r into R. So this is the point of discussion/contention? Okay, so… SNIPPET BEGINS { \time 5/8 c''8*12 } \score { { \time 5/8 c

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

2017-04-03 Thread David Kastrup
Kieren MacMillan writes: > Hi David (et al.), > >> I have a hard time understanding how one can consider the visuals of >> >> { \time 2/4 r4*12 } >> { \time 2/4 R4*12 } >> >> as conveying the same semantics. > > I agree that the visuals of those two things do not convey the same semantics. > >

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

2017-04-03 Thread Kieren MacMillan
Hi David (et al.), > I have a hard time understanding how one can consider the visuals of > > { \time 2/4 r4*12 } > { \time 2/4 R4*12 } > > as conveying the same semantics. I agree that the visuals of those two things do not convey the same semantics. That being said, I consider the following

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

2017-04-03 Thread David Kastrup
Simon Albrecht writes: > Am 02.04.2017 um 23:56 schrieb David Kastrup: >> I have >> a hard time understanding how one can consider the visuals of >> >> { \time 2/4 r4*12 } >> { \time 2/4 R4*12 } >> >> as conveying the same semantics. > > Well, to me the semantics are ‘maintain silence for the giv

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

2017-04-03 Thread Simon Albrecht
Am 02.04.2017 um 23:56 schrieb David Kastrup: I have a hard time understanding how one can consider the visuals of { \time 2/4 r4*12 } { \time 2/4 R4*12 } as conveying the same semantics. Well, to me the semantics are ‘maintain silence for the given period’. The first of your examples does h

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

2017-04-02 Thread Noeck
Hi > I have a hard time understanding how one can consider the visuals of > > { \time 2/4 r4*12 } > { \time 2/4 R4*12 } > > as conveying the same semantics. I don't understand what's so hard to understand about Simons question. Of course there is a difference between the full measure rest and a

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

2017-04-02 Thread David Kastrup
Simon Albrecht writes: > Am 02.04.2017 um 22:48 schrieb David Kastrup: >>> 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

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

2017-04-02 Thread Simon Albrecht
Am 02.04.2017 um 22:48 schrieb David Kastrup: 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? Becaus

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

2017-04-02 Thread Simon Albrecht
Am 02.04.2017 um 22:48 schrieb David Kastrup: 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. Oh, sorry for the misconception. Best, Simon ___ lilypo

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

2017-04-02 Thread David Kastrup
Simon Albrecht writes: > Am 02.04.2017 um 22:24 schrieb David Kastrup: >> Simon Albrecht 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 i

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

2017-04-02 Thread Simon Albrecht
Am 02.04.2017 um 22:24 schrieb David Kastrup: Simon Albrecht 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 alig

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

2017-04-02 Thread David Kastrup
Simon Albrecht 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 >>

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

2017-04-02 Thread Simon Albrecht
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 o

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

2017-04-02 Thread David Kastrup
Simon Albrecht writes: > Am 01.04.2017 um 17:21 schrieb David Kastrup: >> Formatting is completely different (multi measure rests are spanners!), >> so articulations etc will behave surprisingly if LilyPond switches on >> its own initiative. > > I take that as a ‘yes, it’s possible, though the ch

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

2017-04-02 Thread Simon Albrecht
Am 01.04.2017 um 17:21 schrieb David Kastrup: Formatting is completely different (multi measure rests are spanners!), so articulations etc will behave surprisingly if LilyPond switches on its own initiative. I take that as a ‘yes, it’s possible, though the changes required to handling of MMRs

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

2017-04-02 Thread Graham King
On Sat, 2017-04-01 at 17:21 +0200, David Kastrup wrote: > Simon Albrecht writes: > > > Hello everybody, > > > > once again I find myself typesetting ancient music, which poses > > special challenges with regard to separation of content and > > presentation. Right now, I’m talking about the fact t

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

2017-04-01 Thread Simon Albrecht
Am 01.04.2017 um 17:21 schrieb David Kastrup: Polyphony can become rather awkward to read if some voice has a full bar rest while another has material. { << c''1 \\ R1 >> } Well, that has been typographical standard ever since engravers stopped center-aligning whole bar _notes_ (around t

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

2017-04-01 Thread David Kastrup
Simon Albrecht writes: > Hello everybody, > > once again I find myself typesetting ancient music, which poses > special challenges with regard to separation of content and > presentation. Right now, I’m talking about the fact that bar lines are > an editor’s decision and not part of the musical c