Re: the "perfect" break-engraver (was Re: [Feature Request] \compressFullBarRests improvement(s))
Hi Jay,
> Some minor changes would be needed if a break is needed
> mid-measure (something like \lineBreakAt 27 3/4).
Yes. As I understand it, some less minor changes would be needed for that, too:
currently (AFAIK), Lily won’t break mid-measure without an explicit \bar “”.
> I think I'd still prefer keeping the breaks within the score section
> (instead of in the \layout). Something like:
>
> \score <<
> \new Staff {...}
> \breakmode {
>\lineBreakAfter 27
>\pageBreakForbidAfter 98
>etc...
> }
> >>
I like that syntax.
> It could even be expanded into the regular music after parsing.
I leave the technical details up to the programming wizards. =)
Thanks,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: the "perfect" break-engraver (was Re: [Feature Request] \compressFullBarRests improvement(s))
On Fri, Dec 27, 2013 at 4:08 PM, Kieren MacMillan
wrote:
> I think the “perfect” break-engraver would admit coding like the following
> (pseudocode; all numbers in measures):
>
> \lineBreakAt 27
> \lineBreaksAt (12 28 34 48)
> \noLineBreaks (27-30)
> \lineBreaksForbidAt 28
> \lineBreaksAllowAt 34
> etc., and identical for \pageBreaks-
>
> These breaking-codes would be put in the \layout block of a score — cf. the
> way David N’s engraver currently works — so that there is no need to mix this
> presentation-layer information into the content layer.
>
> The only additional [optional] argument I can think of is a Staff (or Voice?)
> "context target”, e.g.,
>
> \lineBreakAt 27 #”soprano"
>
> which would be necessary for polymetric music (where the measures might not
> all end simultaneously).
>
> Thoughts?
I like the ideas (though I haven't been following the preceding
conversation). Some minor changes would be needed if a break is needed
mid-measure (something like \lineBreakAt 27 3/4). I think I'd still
prefer keeping the breaks within the score section (instead of in the
\layout). Something like:
\score <<
\new Staff {...}
\breakmode {
\lineBreakAfter 27
\pageBreakForbidAfter 98
etc...
}
>>
It could even be expanded into the regular music after parsing. I'm
not sure how possible that would be, but it would isolate the changes
needed. The above would be transformed into something like:
\score <<
...
{
% Assuming '\time 4/4'
s1*27 \break
s1*71 \noPageBreak
etc...
}
>>
-Jay
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
the "perfect" break-engraver (was Re: [Feature Request] \compressFullBarRests improvement(s))
Further to this thread… > I just think it — or something like it — should be vetted and [the > improved/approved version] included with the regular distro. I think the “perfect” break-engraver would admit coding like the following (pseudocode; all numbers in measures): \lineBreakAt 27 \lineBreaksAt (12 28 34 48) \noLineBreaks (27-30) \lineBreaksForbidAt 28 \lineBreaksAllowAt 34 etc., and identical for \pageBreaks- These breaking-codes would be put in the \layout block of a score — cf. the way David N’s engraver currently works — so that there is no need to mix this presentation-layer information into the content layer. The only additional [optional] argument I can think of is a Staff (or Voice?) "context target”, e.g., \lineBreakAt 27 #”soprano" which would be necessary for polymetric music (where the measures might not all end simultaneously). Thoughts? Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi David, > A content-independent line- and page-breaking system is easy. > The content is what makes it complicated… Ah, the semantics cop is on the beat. ;) Let me put it another way: Using David’s engraver (which he graciously sent me off-list), I am happily adding manual breaks EXTERNAL TO THE CONTENT, and this has (for me, anyway) eliminated the need for hacks like \tempBreak, \originalBreak, \draftSkip, etc. I just think it — or something like it — should be vetted and [the improved/approved version] included with the regular distro. We should be encouraging best engraving practices, and simple functions/mechanisms like this would allow us to in ways we cannot right now. Best, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Kieren MacMillan writes: > Hi all, > >> How would it behave if \draftSkip were, instead of being changed, > tagged, and you ran lilypond with exclude-tag #draft? (I can't > remember the syntax off the top of my head, but I think that's > reasonably close.) > > It would be fine… but it’s still a band-aid (um, Band-Aid™) solution. > > Lilypond needs a fully-integrated, content-independent, robust line- > and page-breaking system (q.v., David N’s > bars-per-line-systems-per-page engraver). A content-independent line- and page-breaking system is easy. The content is what makes it complicated... -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi all, > How would it behave if \draftSkip were, instead of being changed, tagged, and > you ran lilypond with exclude-tag #draft? (I can't remember the syntax off > the top of my head, but I think that's reasonably close.) It would be fine… but it’s still a band-aid (um, Band-Aid™) solution. Lilypond needs a fully-integrated, content-independent, robust line- and page-breaking system (q.v., David N’s bars-per-line-systems-per-page engraver). Just my 2¢. Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
How would it behave if \draftSkip were, instead of being changed, tagged, and
you ran lilypond with exclude-tag #draft? (I can't remember the syntax off the
top of my head, but I think that's reasonably close.)
On Dec 27, 2013, at 1:38 AM, "Keith OHara" wrote:
> On Thu, 26 Dec 2013 18:44:56 -0800, Kieren MacMillan
> wrote:
>
>> I look forward to stress-testing this in the very near future.
>
> One missing feature is that \mergeSkips doesn't look inside {...} to see if
> they are empty. I often set breaks for proofreading and then remove them by
> defining them as an empty {}
> draftBreak = {} %% \pageBreak
> conductor = { s1*5 \draftBreak s1*3 }
>
> I could make \mergeSkips {s1*5 {} s1*3} check if the {..} is completely empty
> and output s1*8, but if it gets too complicated for my sake its behavior will
> confuse and maybe frustrate somebody else.
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
On Thu, 26 Dec 2013 18:44:56 -0800, Kieren MacMillan
wrote:
I look forward to stress-testing this in the very near future.
One missing feature is that \mergeSkips doesn't look inside {...} to see if
they are empty. I often set breaks for proofreading and then remove them by
defining them as an empty {}
draftBreak = {} %% \pageBreak
conductor = { s1*5 \draftBreak s1*3 }
I could make \mergeSkips {s1*5 {} s1*3} check if the {..} is completely empty
and output s1*8, but if it gets too complicated for my sake its behavior will
confuse and maybe frustrate somebody else.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi Keith, (Sorry for the delay in responding: ice storm + holidays = crazy times.) YES! This works wonderfully. I look forward to stress-testing this in the very near future. Thank you, Kieren. On Dec 22, 2013, at 4:35 PM, Keith OHara wrote: > Let's try it out, then, using music functions. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Kieren MacMillan sympatico.ca> writes:
> > >> I don't understand why, if you want a four measure rest you would> >>
write 2+2. For the vast majority of cases, if there are 48 bars> >> between
two rehearsal marks I'm happy to see |=48=| between them.> >> So, why write
anything but R1*48 in the part in question?
>
> You can write R1*48 in the *part*, but if a shared variable (say, a global
with other changes in it) is simultaneous-ed with it, the R1*48 gets broken
by Lilypond. This is what I'm trying to avoid.
>
> So ultimately you're supporting my argument/request: If one writes R1*48
in a part, one should see a 48-measure MMRs in the output. =)
Ah, I misunderstood the issue. Indeed:
\new Voice <<
{ s1*2 s1*2 }
{ \compressFullBarRests R1*4 }
>>
hjh
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Kieren MacMillan sympatico.ca> writes:
> You can write R1*48 in the *part*, but if a shared variable (say, a
global with other changes in it) is simultaneous-ed with it, the R1*48 gets
broken by Lilypond. This is what I'm trying to avoid.
>
Let's try it out, then, using music functions. I think that merging
skips after filtering out any irrelevant changes is good to do by default,
but we should only merge { R1*7 R1*8 } if explicitly asked.
music = \context Staff <<
\compressFullBarRests
{s1*10 \tag#'score \break s1*10}
{R1*5 R1*7^\markup\eyeglasses R1*8} >>
\keepWithTag #'part \music
\mergeSkips\keepWithTag #'part \music
\mergeFullBarRests \keepWithTag #'part \music
Try the definitions below (possibly after correcting for email corruption)
in a .ly file included before the examples above:
#(define (append-merge x l r)
"Add x to the head of list l, merging skips,
and if r is true also merging full measure rests."
(if (and (pair? l)
(ly:music? x)
(ly:music? (car l))
(or (and (music-is-of-type? x 'skip-event)
(music-is-of-type? (car l) 'skip-event))
(and r
(music-is-of-type? x 'multi-measure-rest)
(music-is-of-type? (car l) 'multi-measure-rest)))
(not (pair? (ly:music-property (car l) 'articulations
(let ((total
(ly:moment-add
(ly:music-duration-length (car l))
(ly:music-duration-length x)
)))
(set! (ly:music-property x 'duration)
(make-duration-of-length total))
(cons x (cdr l)))
(cons x l)))
mergeSkips = #(define-music-function
(parser location rests-also music) ((boolean?) ly:music?)
"Merge successive skips in sequential music,
optionally merge full-measure rests as well."
(music-map
(lambda (m)
(if (music-is-of-type? m 'sequential-music)
(ly:music-set-property! m
'elements
(fold-right (lambda (x l)
(append-merge x l rests-also))
'()
(ly:music-property m 'elements
m)
music))
mergeFullBarRests = #(define-music-function
(parser location music) (ly:music?)
#{ \mergeSkips ##t $music #})
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
RE: [Feature Request] \compressFullBarRests improvement(s)
Hi David, > >> I don't understand why, if you want a four measure rest you would > >> write 2+2. For the vast majority of cases, if there are 48 bars > >> between two rehearsal marks I'm happy to see |=48=| between them. > >> So, why write anything but R1*48 in the part in question? You can write R1*48 in the *part*, but if a shared variable (say, a global with other changes in it) is simultaneous-ed with it, the R1*48 gets broken by Lilypond. This is what I'm trying to avoid. So ultimately you're supporting my argument/request: If one writes R1*48 in a part, one should see a 48-measure MMRs in the output. =) Thanks,Kieren.___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
That could be a useful feature but should not me the default. Perhaps an override such as \override MultimeasureRest #'condense-all = ##t would be helpful. That way the default would still be the intuitive way (2+2 gives two separate groups) whereas the other is still an option for those who want it. On Dec 22, 2013, at 6:44 AM, Werner LEMBERG wrote: > >> I think one of the things that bothers me about this thread is that >> I don't understand why, if you want a four measure rest you would >> write 2+2. For the vast majority of cases, if there are 48 bars >> between two rehearsal marks I'm happy to see |=48=| between them. >> So, why write anything but R1*48 in the part in question? If there >> *is* a reason then the input can be something different, say R1*32 >> R1*16 to produce |=32=| |=16=|. > > As told earlier: The input of a score should not force the appearance > of the output. For example, I like to write one bar per line in the > input files, interspersed with comments to structure them in five-bars > blocks. Writing e.g. `R1*47' heavily disturbs this structure, making > corrections after inputting the data *much* more time consuming since > it takes longer to identify the right spot (yes, I'm a die-hard user > which uses a plain text editor for input). In this case, it would be > great if multi-measure rests written as > > % 15 > R1*5 | > % 20 > R1*5 | > ... > > could be merged properly. > > >Werner > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
> I think one of the things that bothers me about this thread is that > I don't understand why, if you want a four measure rest you would > write 2+2. For the vast majority of cases, if there are 48 bars > between two rehearsal marks I'm happy to see |=48=| between them. > So, why write anything but R1*48 in the part in question? If there > *is* a reason then the input can be something different, say R1*32 > R1*16 to produce |=32=| |=16=|. As told earlier: The input of a score should not force the appearance of the output. For example, I like to write one bar per line in the input files, interspersed with comments to structure them in five-bars blocks. Writing e.g. `R1*47' heavily disturbs this structure, making corrections after inputting the data *much* more time consuming since it takes longer to identify the right spot (yes, I'm a die-hard user which uses a plain text editor for input). In this case, it would be great if multi-measure rests written as % 15 R1*5 | % 20 R1*5 | ... could be merged properly. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
- Original Message - From: "Werner LEMBERG" To: bobr...@centrum.is Cc: lilypond-user@gnu.org Sent: Sunday, December 22, 2013 9:53:36 AM Subject: Re: [Feature Request] \compressFullBarRests improvement(s) > 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. It is a fundamental problem of separating contents from layout. In many cases it is of great importance to structure the input logically for the full score. However, if you just have a part, this logic is completely uninteresting if the instrument doesn't play. Thus it would be good to be able to better control the conversion of full rests to multi-measure rests. Werner I see this issue as a bit analogous to the note name issue. If you want an Eb printed in the key of Bb you have to specify it with its alteration. Likewise, when I pass 'R1*2 R1*2' to LilyPond I expect, and I get, a pair of two-measure rests. I have to partly disagree with your remark about the resting instruments having no interest in the structure/logic during rests. It depends. If it's a 'tacet bis ende' situation I couldn't agree more. If it's a long series of rests with key changes, rehearsal numbers, etc. I don't need too much detail. There are occasions, however, when understanding the content is precisely what is needed during a rest so that your next entrance is clear to you. I'm another orchestral bass trombonist so rests make up the lion's share of what I do at work. I think one of the things that bothers me about this thread is that I don't understand why, if you want a four measure rest you would write 2+2. For the vast majority of cases, if there are 48 bars between two rehearsal marks I'm happy to see |=48=| between them. So, why write anything but R1*48 in the part in question? If there *is* a reason then the input can be something different, say R1*32 R1*16 to produce |=32=| |=16=|. -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
> 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. It is a fundamental problem of separating contents from layout. In many cases it is of great importance to structure the input logically for the full score. However, if you just have a part, this logic is completely uninteresting if the instrument doesn't play. Thus it would be good to be able to better control the conversion of full rests to multi-measure rests. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
- Original Message - From: "Simon Bailey" To: "Werner LEMBERG" Cc: jamshar...@gmail.com, lilypond-user@gnu.org 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 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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
>> 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. Well, this only works properly with a bunch of appropriate cue notes, of course. It would be a means to be used with caution, but it could be tremendously useful. Especially for percussion instruments, where it is often hard to find the next spot where a single `bing' or `whomp' (with 247 bars tacet before and after) has to be played. > If this becomes default behavior, please leave an option to keep it > working as it does now. It should definitely *not* be the default. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
On Sunday, December 22, 2013 5:07:11 PM HKT, Simon Bailey 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. Note that this is a side suggestion, tangentially related to the main request. The main request is to avoid multi-measure rests that are broken only by a bar line and nothing else. It's okay to break a multi-measure rests for a double bar line, a key or meter change, or a rehearsal mark. It's really questionable to break a multi-measure rest into two when there is no notationally evident reason to do so. | = barline + = Multi-measure rest delimiter | +--- 2 ---+ | 3/4 +--- 2 ---+ |<<-- this is necessary | +--- 2 ---+ | +--- 2 ---+ |<<-- this is pointless | +--- 4 ---+ | <<-- this is the same as the second, but more efficient For the side request, I totally agree that it shouldn't be the default handling. Rests should not be notated such that the duration is ambiguous. "Tacet al fine" would be fine, though. Just my opinions. I'll defer to experts if I'm wrong. hjh ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
On 22 Dec 2013, at 06:56, Werner LEMBERG 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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
>> Here’s my request: I would love it if \compressFullBarRests actually did
>> what it says it does… ;)
>
> FWIW, I agree with Kieren. If I saw a part with some multimeasure
> rests broken for no obvious reason, e.g.
>
> { \compressFullBarRests \mark \default R1*2 R1*2 \mark \default R1*2 }
>
> I would think the publisher was insane or incompetent. I'm surprised
> this is LP's default behavior.
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.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
I agree entirely with James that the input looks good as is. Only
tangentially related, does the placement of the first mark bother anyone
else? I feel like it would look better after rather than over the clef.
On Sat, Dec 21, 2013 at 9:42 PM, James Harkins wrote:
> James Harkins gmail.com> writes:
>
> > FWIW, I agree with Kieren. If I saw a part with some multimeasure rests
> > broken for no obvious reason, e.g.
> >
> > { \compressFullBarRests \mark \default R1*2 R1*2 \mark \default R1*2 }
> >
> > I would think the publisher was insane or incompetent. I'm surprised
> this is
> > LP's default behavior.
>
> Hm, no, that example looks OK because of the older-style rest format.
>
> *This* looks nuts to me, and I don't recall every seeing anything like this
> in any part that I played from in wind bands in high school and college...
> why not just |--- 4 ---|?
>
> { \compressFullBarRests \override MultiMeasureRest #'expand-limit = #1
> \mark
> \default R1*2 R1*2 \mark \default R1*2 }
>
> hjh
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
James Harkins gmail.com> writes:
> FWIW, I agree with Kieren. If I saw a part with some multimeasure rests
> broken for no obvious reason, e.g.
>
> { \compressFullBarRests \mark \default R1*2 R1*2 \mark \default R1*2 }
>
> I would think the publisher was insane or incompetent. I'm surprised this is
> LP's default behavior.
Hm, no, that example looks OK because of the older-style rest format.
*This* looks nuts to me, and I don't recall every seeing anything like this
in any part that I played from in wind bands in high school and college...
why not just |--- 4 ---|?
{ \compressFullBarRests \override MultiMeasureRest #'expand-limit = #1 \mark
\default R1*2 R1*2 \mark \default R1*2 }
hjh
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Kieren MacMillan sympatico.ca> writes:
> 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… ;)
FWIW, I agree with Kieren. If I saw a part with some multimeasure rests
broken for no obvious reason, e.g.
{ \compressFullBarRests \mark \default R1*2 R1*2 \mark \default R1*2 }
I would think the publisher was insane or incompetent. I'm surprised this is
LP's default behavior.
hjh
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi David, > "split points" would require a different signaling/wait framework. While I appreciate the ingenuity here… ;) Consider if this is how auto-beaming were implemented — yuck. Instead, we have \noBeam to break any automatic beam. Why not do the same here? i.e., Make \compressFullBarRests work as expected [to me, anyway :)], and have a command like \splitMMR to force a split where desired. An implementation like that would allow “surgical” splits (e.g., within a single part) as well as “global” splits, while the “improved” \compressFullBarRests would solve [all?] problems like the ones I posted earlier in this thread. Thoughts? Thanks, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Kieren MacMillan writes: > Hi David, > >> Well, you would not count. Instead you'd say something like >> >> \R-until \atMark 8 >> or >> \R-until \atmeasure 80 > > Ah! I could see that being a *very* elegant solution for that problem. > > However, if one suddenly added, post-hoc, a “split point” in the > [shared] global music, would it split the \R-until (as desired)? "split points" would require a different signaling/wait framework. Basically something like \R-until #'(markB violin) in one voice, and then you do in another voice/staff \interrupt #'(violin viola) (which breaks all pending multimeasurerests marked with violin or viola). and at some point \mark "B" \resume #'markB (which makes all multimeasure rests waiting for #'markB resume). >> I am afraid that "2 before mark G" would be too ambitious since one >> can't rewind the time. But "x after" should be possible. > > That would definitely solve the vast majority of use cases — enough to > make it worth implementing, per the old adage “the perfect is the > enemy of the good”. Well, the above signaling would make either work reasonably well, and it would be robust against putting in more or fewer marks since it just synchronizes points between different voices. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi David, > Well, you would not count. Instead you'd say something like > > \R-until \atMark 8 > or > \R-until \atmeasure 80 Ah! I could see that being a *very* elegant solution for that problem. However, if one suddenly added, post-hoc, a “split point” in the [shared] global music, would it split the \R-until (as desired)? > I am afraid that "2 before mark G" would be too ambitious since one > can't rewind the time. But "x after" should be possible. That would definitely solve the vast majority of use cases — enough to make it worth implementing, per the old adage “the perfect is the enemy of the good”. Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Kieren MacMillan writes: > Hi David, > >> I have quite a few orchestra parts where multimeasure rest streaks of >> several lengths are _not_ conflated. Basically, each such rest stands >> for a recognizable unit. > > I’ll look at Gould to see what her recommendations are. > > In any case, whether or not a best practice is known, the snippet I > sent in response to Alex’s reply clearly shows a case where Lily is > not behaving “as expected”. > >> What you need here in my opinion is something else: a command that just >> passes time (using s or R or something else) until a specified event >> occurs initiated from another voice, and then resumes. > > ? > > I don’t understand how that would apply to or solve this issue/problem > — please give a [possibly pseudo-code] example. Well, you would not count. Instead you'd say something like \R-until \atMark 8 or \R-until \atmeasure 80 I am afraid that "2 before mark G" would be too ambitious since one can't rewind the time. But "x after" should be possible. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
I agree that in that case it should be fully compressed, but not in the
first example.
On Sat, Dec 21, 2013 at 5:39 PM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:
> Hi Alex,
>
> > Two separate ones. As an orchestral performer those breaks are often
> used to signify the beginnings of sections to make counting easier, so if
> I'm resting and there are 8 bars of one theme followed by 8 of another, I
> find it much easier to keep my place when it's 8 and 8 instead of 16.
>
> That’s exactly why there are rehearsal marks, markup, cues, spanners,
> etc.: you [can] use them to break up the uninterrupted stretches of
> multi-measure rests — I don’t want to stop that from happening, of course.
>
> I’m simply trying to avoid problems like the one evident in the following
> snippet (where the second score should contain a three-measure MMR):
>
> \version "2.17.97"
>
> theGlobal = {
> \compressFullBarRests
> s1
> s1-\tag #'(foo) -\markup "Foo only"
> s1
> }
>
> theMusic = {
> R1*3
> }
>
> \score {
> \new Staff \keepWithTag #'(foo) << \theGlobal \theMusic >>
> }
>
> \score {
> \new Staff \removeWithTag #'(foo) << \theGlobal \theMusic >>
> }
>
> Cheers,
> Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi David, > I have quite a few orchestra parts where multimeasure rest streaks of > several lengths are _not_ conflated. Basically, each such rest stands > for a recognizable unit. I’ll look at Gould to see what her recommendations are. In any case, whether or not a best practice is known, the snippet I sent in response to Alex’s reply clearly shows a case where Lily is not behaving “as expected”. > What you need here in my opinion is something else: a command that just > passes time (using s or R or something else) until a specified event > occurs initiated from another voice, and then resumes. ? I don’t understand how that would apply to or solve this issue/problem — please give a [possibly pseudo-code] example. Thanks, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi Alex,
> Two separate ones. As an orchestral performer those breaks are often used to
> signify the beginnings of sections to make counting easier, so if I'm resting
> and there are 8 bars of one theme followed by 8 of another, I find it much
> easier to keep my place when it's 8 and 8 instead of 16.
That’s exactly why there are rehearsal marks, markup, cues, spanners, etc.: you
[can] use them to break up the uninterrupted stretches of multi-measure rests —
I don’t want to stop that from happening, of course.
I’m simply trying to avoid problems like the one evident in the following
snippet (where the second score should contain a three-measure MMR):
\version "2.17.97"
theGlobal = {
\compressFullBarRests
s1
s1-\tag #'(foo) -\markup "Foo only"
s1
}
theMusic = {
R1*3
}
\score {
\new Staff \keepWithTag #'(foo) << \theGlobal \theMusic >>
}
\score {
\new Staff \removeWithTag #'(foo) << \theGlobal \theMusic >>
}
Cheers,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Kieren MacMillan writes: > 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? I have quite a few orchestra parts where multimeasure rest streaks of several lengths are _not_ conflated. Basically, each such rest stands for a recognizable unit. What you need here in my opinion is something else: a command that just passes time (using s or R or something else) until a specified event occurs initiated from another voice, and then resumes. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Two separate ones. As an orchestral performer those breaks are often used to signify the beginnings of sections to make counting easier, so if I'm resting and there are 8 bars of one theme followed by 8 of another, I find it much easier to keep my place when it's 8 and 8 instead of 16. Alex On Sat, Dec 21, 2013 at 5:07 PM, Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Alex, > > > I don't see what's wrong with the output, that's exactly what I would > expect it to be. > > Does your output show a single four-measure MMR (which I would both want > and expect it to be), or two two-measure MMRs (which is undesirable, > primarily because it's distracting to the performer)? > > Thanks, > Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
Hi Alex, > I don't see what's wrong with the output, that's exactly what I would expect > it to be. Does your output show a single four-measure MMR (which I would both want and expect it to be), or two two-measure MMRs (which is undesirable, primarily because it's distracting to the performer)? Thanks, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Feature Request] \compressFullBarRests improvement(s)
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 <
kieren_macmil...@sympatico.ca> 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
> 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
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
[Feature Request] \compressFullBarRests improvement(s)
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 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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
