bug report: partcombine and multi-measure rests
Hello all,
I get strange results when I change the type of \partcombine (for
instance, using \partcombineApart) when one of the parts is in the
middle of a several bars long multi-measure rest:
http://lilypond.1069038.n5.nabble.com/file/n182372/39.png
code:
\version "2.19.15"
partA = \relative c'' {
c1 |
R1*2 |
\partcombineApart r2 b2~ |
b1 |
\partcombineAutomatic c1 |
}
partB = \relative c' {
f1 |
R1*2 |
R1*2 |
f1 |
}
partBalternative = \relative c' {
f1 |
R1*4 |
f1 |
}
\markup {"When the bottom part has the bar rests divided into two groups
(exactly were \partcombineApart takes" }
\markup {"place) of R1*2, the rests below the b2~b1 are properly
displayed:"}
{\partcombine \partA \partB}
\markup {"Now when the rests are combined into a single R1*4, the rests
below b2~b1 are not displayed at all:"}
{\partcombine \partA \partBalternative}
Exchanging R1*N by \repeat N R1 solves the problem, but has the side
effect of influencing \compressFullBarRests.
There was a discussion in our forum in the following link:
lilypond.1069038.n5.nabble.com/partcombine-and-multi-measure-rests-td182372.html
Cheers,
Gilberto
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet
"Phil Holmes" writes: > "David Kastrup" wrote in message > news:87twpt4rx3@fencepost.gnu.org... > >> The LSR version of vspace (when was this ever a good idea?) by now has >> markedly diverged from the built-in variant, so it really should get >> removed and its effect compensated. >> >> So it might make sense to run >> >> convert-ly -f 2.17.18 -t 2.17.19 >> >> on the LSR snippet (though it's possible that this has already been done >> once and should not be repeated) before throwing out its own vspace >> definition. > > > Or simply delete the snippet? It's a pretty large one. I think it should only be deleted once we are sure that its functionality is sufficiently part of LilyPond these days. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet
On Wed, 2015-10-14 at 17:24 +0100, Phil Holmes wrote: > "David Kastrup" wrote in message > news:87twpt4rx3@fencepost.gnu.org... > > > The LSR version of vspace (when was this ever a good idea?) by now has > > markedly diverged from the built-in variant, so it really should get > > removed and its effect compensated. > > > > So it might make sense to run > > > > convert-ly -f 2.17.18 -t 2.17.19 > > > > on the LSR snippet (though it's possible that this has already been done > > once and should not be repeated) before throwing out its own vspace > > definition. > > > Or simply delete the snippet? > Please don't. This is a really useful snippet that still produces beautiful results. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet
"David Kastrup" wrote in message news:87twpt4rx3@fencepost.gnu.org... The LSR version of vspace (when was this ever a good idea?) by now has markedly diverged from the built-in variant, so it really should get removed and its effect compensated. So it might make sense to run convert-ly -f 2.17.18 -t 2.17.19 on the LSR snippet (though it's possible that this has already been done once and should not be repeated) before throwing out its own vspace definition. Or simply delete the snippet? -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet
Thomas Morley writes:
> 2015-10-14 10:17 GMT+02:00 Pierre Perol-Schneider
> :
>>
>> I'd suggest to simply delete the 'vspace' defs in "book-titling.ily"
>
> Well, the coding is different, causing different results.
>
> Look at the output from:
>
> \version "2.18.2"
>
> #(define-markup-command (vspace-lsr layout props amount) (number?)
> "This produces a invisible object taking vertical space."
> (let ((amount (* amount 3.0)))
> (if (> amount 0)
> (ly:make-stencil "" (cons -1 1) (cons 0 amount))
> (ly:make-stencil "" (cons -1 1) (cons amount amount)
>
> \markup
> \box
> \line {
> "lsr-def: " \box \column { A \vspace-lsr #-5 B }
> "source-def: " \box \column { A \vspace #-5 B }
> }
>
> In said snippet only positive numbers are used, thus no big
> difference.
LilyPond's definition of vspace was once similar to the one in the LSR
but isn't anymore (issue 3330). The old definition creates an object
that gets padding on both sides, and \hspace (but not \vspace I think)
tried compensating for it but often predicted the value it needed to
compensate for wrong. Even then, negative vspaces did not work well.
The new definition has an empty X-extent which is recognized by the
spacing engine as _not_ marking an object. Consequently, \vspace #0
does not add padding or line spacing or other stuff, and negative and
positive values work smoothly starting from there.
> I'm more or less undecided. Admittedly, using negative numbers will
> circumvent calculated extents. Bug or feature?
Issue 3330 clearly is intentional. In particular, it strove hard to
make spacing and vspace/hspace more predictable and reliable. There is
also some convert-ly rule to counter for \vspace no longer adding
padding.
The LSR version of vspace (when was this ever a good idea?) by now has
markedly diverged from the built-in variant, so it really should get
removed and its effect compensated.
So it might make sense to run
convert-ly -f 2.17.18 -t 2.17.19
on the LSR snippet (though it's possible that this has already been done
once and should not be repeated) before throwing out its own vspace
definition.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet
2015-10-14 10:17 GMT+02:00 Pierre Perol-Schneider
:
>>I'm not top posting
> cc. Nicolas
>
> Hi Squad,
>
> In this snippet : http://lsr.di.unimi.it/LSR/Item?id=368
> there is a predefined 'vspace' command which causes some unwanted result :
>
> \version "2.18.2"
> \include "book-titling.ily"
> \markup\column { A \vspace #-5 B }
>
> I'd suggest to simply delete the 'vspace' defs in "book-titling.ily"
>
> Cheers,
> Pierre
Well, the coding is different, causing different results.
Look at the output from:
\version "2.18.2"
#(define-markup-command (vspace-lsr layout props amount) (number?)
"This produces a invisible object taking vertical space."
(let ((amount (* amount 3.0)))
(if (> amount 0)
(ly:make-stencil "" (cons -1 1) (cons 0 amount))
(ly:make-stencil "" (cons -1 1) (cons amount amount)
\markup
\box
\line {
"lsr-def: " \box \column { A \vspace-lsr #-5 B }
"source-def: " \box \column { A \vspace #-5 B }
}
In said snippet only positive numbers are used, thus no big difference.
I always think using negative numbers for vspace/hspace in order to
_move_ objects feels strange, quick'n dirty best to say. But that's
only me.
Depends what people wish.
I'm more or less undecided. Admittedly, using negative numbers will
circumvent calculated extents. Bug or feature?
Cheers,
Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
[LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet
>I'm not top posting
cc. Nicolas
Hi Squad,
In this snippet : http://lsr.di.unimi.it/LSR/Item?id=368
there is a predefined 'vspace' command which causes some unwanted result :
\version "2.18.2"
\include "book-titling.ily"
\markup\column { A \vspace #-5 B }
I'd suggest to simply delete the 'vspace' defs in "book-titling.ily"
Cheers,
Pierre
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
