lilypond-user
[Top][All Lists]
Advanced

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

Re: [Feature Request] \compressFullBarRests improvement(s)


From: address@hidden
Subject: Re: [Feature Request] \compressFullBarRests improvement(s)
Date: Sun, 22 Dec 2013 09:42:42 +0000 (GMT)

----- Original Message -----
From: "Simon Bailey" <address@hidden>
To: "Werner LEMBERG" <address@hidden>
Cc: address@hidden, address@hidden
Sent: Sunday, December 22, 2013 9:07:11 AM
Subject: Re: [Feature Request] \compressFullBarRests improvement(s)


On 22 Dec 2013, at 06:56, Werner LEMBERG <address@hidden> wrote:

> I also support this request.  Another reason is that in many parts of
> percussion instruments, say, there is `tacet' for a very long time,
> e.g. from rehearsal number 20 to 76.  A potential new implementation
> of \compressFullBarRests (or a variant as suggested by David K.)
> should allow compression of everything (including measure changes!)
> into a single MM rest to span these two rehearsal numbers.

as a victim of such parts (orchestral bass trombone), this shouldn't be the 
default behavior. I've had such parts, and it is REALLY annoying when your part 
jumps from say mark G to mark Q (with 137 bars rest) and the conductor asks for 
the rehearsal to start 3 bars before P. unless you _know_ how many bars P has 
or _exactly_ when you're supposed to come in, such parts are useless. 

If this becomes default behavior, please leave an option to keep it working as 
it does now.

regards,
sb


I would like to echo Simon's concern as well.  Furthermore, I don't see why:

R1*2 R1*2

...producing two multimeasure rests of two measures duration is troublesome.  
To me, that's what R1*2 R1*2 means.  At least, that's what it means to LilyPond 
so I take it into account.  If I want a four measure block rest I write R1*4.  
The fact that LilyPond currently produces multimeasure rests the way it does 
makes it a straightforward matter to structure the input to mirror the 
logical/musical structure of the piece.  I think changing the default behavior 
of \compressFullBarsRest so that it collects input like R1*2 R1*2 and 
outputting a four-bar rest is a step in the wrong direction.

On the other hand I think it would be useful to have the option to go in the 
opposite direction.  That is, to have a fairly easy way to let LilyPond 
calculate the empty bars for a section of music, taking into account meter 
changes, etc. and print something like |====== Tacet bis =====| letting the 
user input the desired text to be displayed.  This is useful for parts that 
stop way before the end of o piece.

-David



reply via email to

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