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: Alex Loomis
Subject: Re: [Feature Request] \compressFullBarRests improvement(s)
Date: Sat, 21 Dec 2013 17:01:23 -0500

I don't see what's wrong with the output, that's exactly what I would expect it to be.


On Sat, Dec 21, 2013 at 4:09 PM, Kieren MacMillan <address@hidden> wrote:
Hello all,

Consider this snippet:

\version "2.17.97"

theMusic = {
  \compressFullBarRests
  R1*2
  R1*2
}

\score {
  \theMusic
}

Here’s my request: I would love it if \compressFullBarRests actually did what it says it does…  ;)

See <http://lists.gnu.org/archive/html/lilypond-user/2013-10/msg00517.html> for more discussion on this request.

Despite David K’s suggestions that it might be difficult to work out what the user wants/means or what the output “should be”, I believe we can come up with a pretty simple single rule which covers >90% of the cases perfectly. As a first attempt, I would suggest the following:

    \compressFullBarRests will combine any contiguous block of multi-measure rests (within the same context*) which is uninterrupted by any "notation item”** other than a barline***.

Notes:
* This may be up for discussion — though, again, it will more than suffice for >90% of use cases.
** This wording sucks; needs “official” wording.
*** There may be other items I’m not thinking of which are “outputtable" grobs which nevertheless should *not* split a compressed block of MMRs.

Having just engraved nearly 25 minutes of music resulting in 57 different individual parts, I can tell you that this issue inspired quite a bit of reduced efficiency, increased hackery, and even some loud swearing.  =)

Thoughts?

Thanks,
Kieren.
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user


reply via email to

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