Re: R shorthand

Kieren MacMillan writes: > Hi David, > >> I gave the answer previously, including the rationale. Since it was >> tactfully being ignored, it seemed to require more emphasis. >> Otherwise I would likely have been blamed for ignoring users' wishes >> in spite of them reaching perfect agreement. >

Re: R shorthand

Hi David, > I gave the answer previously, including the rationale. Since it was > tactfully being ignored, it seemed to require more emphasis. Otherwise > I would likely have been blamed for ignoring users' wishes in spite of > them reaching perfect agreement. So to be perfectly clear: You can

Re: R shorthand

Kieren MacMillan writes: > Hi David, > >> Whatever you mean by "improve". > > > >> What is supposed to be the result of >> { \time 3/4 << { R15 \time 2/4 R3 } \\ { R3 \time 4/4 R10 } >> } > > One context consisting of a sequence of multi-measure re

Re: R shorthand

Hi David, > Whatever you mean by "improve". > What is supposed to be the result of > { \time 3/4 << { R15 \time 2/4 R3 } \\ { R3 \time 4/4 R10 } >> } One context consisting of a sequence of multi-measure rests totalling 51 quarter notes, simulta

Re: R shorthand

Kieren MacMillan writes: > Hi Evan, > >> FWIW the multimeasure rest syntax has been a bit of an annoyance >> with what I've been working on recently (Mars). > > First of all, could you please email me the note code for "Mars" when > you're done? I'm working on a wicked-cool Lilypond demo, and "Ma

Re: R shorthand

Hi Evan, > FWIW the multimeasure rest syntax has been a bit of an annoyance with what > I've been working on recently (Mars). First of all, could you please email me the note code for "Mars" when you're done? I'm working on a wicked-cool Lilypond demo, and "Mars" was exactly the piece I was co

Re: Re: R shorthand

On 03/19/2013 04:21 PM, Shane Brandes wrote: I see now, but one would think that might cause more difficult programming necessitating the keeping tracking of various R values through out the piece as defined by a time signature as opposed to us setting the value, which probably would also slow do

Re: R shorthand

On Tue, 19 Mar 2013 19:38:10 -0400 Kieren MacMillan wrote: > Hi Shane, > > > one would think that might cause more difficult > > programming necessitating the keeping tracking of various R values > > through out the piece as defined by a time signature as opposed to us > > setting the value, whi

Re: R shorthand

Hi Shane, > one would think that might cause more difficult > programming necessitating the keeping tracking of various R values > through out the piece as defined by a time signature as opposed to us > setting the value, which probably would also slow down lilypond having > to parse and hang on t

Re: R shorthand

I see now, but one would think that might cause more difficult programming necessitating the keeping tracking of various R values through out the piece as defined by a time signature as opposed to us setting the value, which probably would also slow down lilypond having to parse and hang on to that

Re: R shorthand

Even while I am a bit sceptical whether the syntax for R should differ from r, I see your point. Rather than R14 for a 14 measure rest, I would suggest to keep the syntax close to the one before: R*14 (This way I would almost be convinced ;) ) Could the duration be optional this way, keeping the

Re: R shorthand

Hi Shane, > What happens when we need an awkward length R like R1*12/8*14? I'm not sure what you mean by "awkward length"… I'm suggesting that R (with no duration given) should give you a one-measure multi-measure rest, regardless of what the measure duration is. And that Rx (where x is an int

Re: R shorthand

Kieren, What happens when we need an awkward length R like R1*12/8*14? Shane On Tue, Mar 19, 2013 at 3:05 PM, Kieren MacMillan wrote: > Hello all, > > While answering Helge's post about multi-measure rests, I had a couple of > R-elated observations/thoughts: > > 1. We shouldn't be encouragin