Re: \bookpart and variables
Am 09.02.2015 um 09:31 schrieb Werner LEMBERG:
Folks,
why are variable assignments not allowed in \bookpart? For example,
this snippet
\bookpart {
APT = \allowPageTurn
{ c'' }
}
fails. In case this is just an omission, can it be fixed easily?
If not this should help you as an easy workaround:
https://github.com/openlilylib/openlilylib/tree/master/general-tools/scheme-wrapper/parserDefine
HTH
Urs
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \bookpart and variables
Werner LEMBERG w...@gnu.org writes:
Folks,
why are variable assignments not allowed in \bookpart? For example,
this snippet
\bookpart {
APT = \allowPageTurn
{ c'' }
}
fails. In case this is just an omission, can it be fixed easily?
Well, as far as I can see, assignments are also not allowed in books.
And the reason mostly would be that books and bookparts don't have scope
of their own (apart from book's \paper block). So even if it were
allowed, it would end up just the same as a global assignment outside of
the book/bookpart.
Do you have a particular use case in mind?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \bookpart and variables
why are variable assignments not allowed in \bookpart? [...]
Well, as far as I can see, assignments are also not allowed in
books.
Hmm...
And the reason mostly would be that books and bookparts don't have
scope of their own (apart from book's \paper block). So even if it
were allowed, it would end up just the same as a global assignment
outside of the book/bookpart.
OK. Even if \book and \bookpart don't provide `real' grouping (in the
lilypond sense), they contain data between `{' and `}' – let's call
this visual grouping. I consider it quite natural to put stuff into
`\bookmark { ... } ' to indicate that it belongs together.
Do you have a particular use case in mind?
Yes. I have the following structure for a collection of piano pieces
file-a.ly: left = ...
right = ...
file-b.ly: left = ...
right = ...
...
and I would like to organize it as follows.
\bookpart {
\include file-a.ly
\score { ... }
}
\bookpart {
\include file-b.ly
\score { ... }
}
...
Right now, I have to do this:
\include file-a.ly
\bookpart {
\score { ... }
}
\include file-b.ly
\bookpart {
\score { ... }
}
...
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Web: CSS: remove vendor prefixed border-radius (issue 200340043 by paulwmor...@gmail.com)
Reviewers: ,
Message:
Please review, thanks.
Description:
Web: CSS: remove vendor prefixed border-radius
No need for these anymore:
-moz-border-radius
-webkit-border-radius
Please review this at https://codereview.appspot.com/200340043/
Affected files (+2, -24 lines):
M Documentation/css/lilypond-manuals.css
M Documentation/css/lilypond-website.css
Index: Documentation/css/lilypond-manuals.css
diff --git a/Documentation/css/lilypond-manuals.css
b/Documentation/css/lilypond-manuals.css
index
8950b847a712bdf7f169793a833c5ebe7ec57fee..04a6877d8dbd833ba2568d7d5834ec3b6757ba29
100644
--- a/Documentation/css/lilypond-manuals.css
+++ b/Documentation/css/lilypond-manuals.css
@@ -513,8 +513,7 @@ div#search p, div#search form {
padding: 0;
border: 1px solid green;
/* Experimental rounded corners */
- -moz-border-radius: 10px;
- -webkit-border-radius: 10px;
+ border-radius: 10px;
margin: 1em;
}
@@ -532,7 +531,6 @@ body.contributor .warning { border-color: #00; }
padding: 0;
border: 1px solid green;
/* Experimental rounded corners */
- -moz-border-radius: 10px;
- -webkit-border-radius: 10px;
+ border-radius: 10px;
margin: 0.5em 0.5em 2em 3em;
}
Index: Documentation/css/lilypond-website.css
diff --git a/Documentation/css/lilypond-website.css
b/Documentation/css/lilypond-website.css
index
032feebdd964a4a8aa66774e2d46eb5d43a922fb..60c0f815a404a2af79121d65dcc90e31e4b85b8b
100644
--- a/Documentation/css/lilypond-website.css
+++ b/Documentation/css/lilypond-website.css
@@ -75,10 +75,6 @@ div#tocframe {
font-size: 100%;
line-height: 1;
padding: 0;
- -moz-border-radius-bottomleft: 7px;
- -moz-border-radius-bottomright: 7px;
- -webkit-border-bottom-left-radius: 7px;
- -webkit-border-bottom-right-radius: 7px;
border-bottom-left-radius: 7px;
border-bottom-right-radius: 7px;
margin: 0;
@@ -96,8 +92,6 @@ div#tocframe {
}
#tocframe ul:first-child li:first-child a {
- -moz-border-radius-bottomleft: 7px;
- -webkit-border-bottom-left-radius: 7px;
border-bottom-left-radius: 7px;
}
@@ -107,8 +101,6 @@ div#tocframe {
}
#tocframe ul:first-child li:last-child {
- -moz-border-radius-bottomright: 7px;
- -webkit-border-bottom-right-radius: 7px;
border-bottom-right-radius: 7px;
}
@@ -137,8 +129,6 @@ div#tocframe {
padding: 0.1em 0.1em 0.1em 0.6em;
border: 0;
margin: 0;
- -moz-border-radius: 7px;
- -webkit-border-radius: 7px;
border-radius: 7px;
}
@@ -194,20 +184,12 @@ div#tocframe {
}
#tocframe .toc .toc li:first-child a {
- -moz-border-radius-topleft: 7px;
- -moz-border-radius-bottomleft: 7px;
- -webkit-border-top-left-radius: 7px;
- -webkit-border-bottom-left-radius: 7px;
border-top-left-radius: 7px;
border-bottom-left-radius: 7px;
border-left: 1px solid rgba(85, 130, 70, 0.25);
}
#tocframe .toc .toc li:last-child a {
- -moz-border-radius-topright: 7px;
- -moz-border-radius-bottomright: 7px;
- -webkit-border-top-right-radius: 7px;
- -webkit-border-bottom-right-radius: 7px;
border-top-right-radius: 7px;
border-bottom-right-radius: 7px;
}
@@ -888,8 +870,6 @@ div.color4 h3 {
padding: 0;
border: 1px solid green;
/* Experimental rounded corners */
- -moz-border-radius: 10px;
- -webkit-border-radius: 10px;
border-radius: 10px;
margin: 1em;
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Web: introduction.itexi fix typo (Vim - Emacs) (issue 197530043 by paulwmor...@gmail.com)
Reviewers: ,
Message:
Just fixing a typo on the website.
-Paul
Description:
Web: introduction.itexi fix typo (Vim - Emacs)
Please review this at https://codereview.appspot.com/197530043/
Affected files (+1, -1 lines):
M Documentation/web/introduction.itexi
Index: Documentation/web/introduction.itexi
diff --git a/Documentation/web/introduction.itexi
b/Documentation/web/introduction.itexi
index
dc755d528abb0c8d636f9802accd5e8a85342347..3942a42959cdc68ca1a0ee4374eca928d294144b
100644
--- a/Documentation/web/introduction.itexi
+++ b/Documentation/web/introduction.itexi
@@ -1305,7 +1305,7 @@ with LilyPond source files. A developer has written
If you are not already familiar with Emacs then you may probably prefer
to use a different editor for writing LilyPond input files.
-More information on setting up Vim can be found in
+More information on setting up Emacs can be found in
@rprogram{Text editor support}.
@subsubheading Vim
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \bookpart and variables
Werner LEMBERG w...@gnu.org writes:
why are variable assignments not allowed in \bookpart? [...]
Well, as far as I can see, assignments are also not allowed in
books.
Hmm...
And the reason mostly would be that books and bookparts don't have
scope of their own (apart from book's \paper block). So even if it
were allowed, it would end up just the same as a global assignment
outside of the book/bookpart.
OK. Even if \book and \bookpart don't provide `real' grouping (in the
lilypond sense), they contain data between `{' and `}' – let's call
this visual grouping. I consider it quite natural to put stuff into
`\bookmark { ... } ' to indicate that it belongs together.
Do you have a particular use case in mind?
Yes. I have the following structure for a collection of piano pieces
file-a.ly: left = ...
right = ...
file-b.ly: left = ...
right = ...
...
and I would like to organize it as follows.
\bookpart {
\include file-a.ly
\score { ... }
}
\bookpart {
\include file-b.ly
\score { ... }
}
...
Right now, I have to do this:
\include file-a.ly
\bookpart {
\score { ... }
}
\include file-b.ly
\bookpart {
\score { ... }
}
Well, yes. The former arrangement suggests a locality that is not
there. Here is an example (where I use the Scheme equivalent of
assignment):
\book {
\bookpart {
#(define notecolor blue)
\score {
{ \override NoteHead.color = #(lambda (grob) notecolor)
c1
}
}
}
\bookpart {
#(define notecolor red)
\score {
{ \override NoteHead.color = #(lambda (grob) notecolor)
c1
}
}
}
}
Now wouldn't you expect, assuming assignment were allowed where
#(define...) is not being used, that the bookparts would show different
colors for the noteheads?
Instead both of them have red noteheads because both use the same global
variable `notecolor' and reference it when \book starts iterating the
already assembled bookparts.
So as long as everything refers to global variables _and_ bookparts are
not iterated when they are encountered but only after the complete music
expressions in a book have been collected, we are just asking for
trouble by allowing assignment in places where the actual execution
happens at a different time than the assignments would.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \bookpart and variables
Werner LEMBERG w...@gnu.org writes:
Here is an example (where I use the Scheme equivalent of
assignment): [...]
Interesting. Note that
foo = \relative c' { c d e f g }
\bookpart {
\foo
}
foo = \relative c'' { g f e d c }
\bookpart {
\foo
}
fortunately works as expected (this is, different notes in different
\bookparts), while
#(define notecolor blue)
\bookpart {
\score {
{ \override NoteHead.color = #(lambda (grob) notecolor)
c1
}
}
}
#(define notecolor red)
\bookpart {
\score {
{ \override NoteHead.color = #(lambda (grob) notecolor)
c1
}
}
}
gives a red notehead both times. So I think that your comparison is
not completely valid, since lilypond's `variables' are obviously
expanded at a different time than Scheme assignments.
No, they aren't. This is not due to a difference between LilyPond and
Scheme. If you override with #notecolor you'll again get two different
colors. But #(lambda (grob) notecolor) is called at iteration time, and
at that time the second assignment to notecolor has already happened.
Is this documented somewhere?
That iteration and parsing happen at different times? It's not all that
surprising. If we write
\score { ...
\midi ...
\layout ...
}
then we get two instances of iteration for the music starting the
score. It's not all that surprising that it is only read in once.
We don't allow assignments inside of music expressions either, and again
the reason is not as much that it wouldn't be possible to allow them
there, but rather that people would be surprised that reassigning a
variable inside of music will affect previous uses of it and not be in
any conceivable way synchronized with the flow of music.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
\bookpart and variables
Folks,
why are variable assignments not allowed in \bookpart? For example,
this snippet
\bookpart {
APT = \allowPageTurn
{ c'' }
}
fails. In case this is just an omission, can it be fixed easily?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \bookpart and variables
Here is an example (where I use the Scheme equivalent of
assignment): [...]
Interesting. Note that
foo = \relative c' { c d e f g }
\bookpart {
\foo
}
foo = \relative c'' { g f e d c }
\bookpart {
\foo
}
fortunately works as expected (this is, different notes in different
\bookparts), while
#(define notecolor blue)
\bookpart {
\score {
{ \override NoteHead.color = #(lambda (grob) notecolor)
c1
}
}
}
#(define notecolor red)
\bookpart {
\score {
{ \override NoteHead.color = #(lambda (grob) notecolor)
c1
}
}
}
gives a red notehead both times. So I think that your comparison is
not completely valid, since lilypond's `variables' are obviously
expanded at a different time than Scheme assignments.
Is this documented somewhere?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \bookpart and variables
So I think that your comparison is not completely valid, since lilypond's `variables' are obviously expanded at a different time than Scheme assignments. No, they aren't. This is not due to a difference between LilyPond and Scheme. If you override with #notecolor you'll again get two different colors. But #(lambda (grob) notecolor) is called at iteration time, and at that time the second assignment to notecolor has already happened. Is this documented somewhere? That iteration and parsing happen at different times? It's not all that surprising. Believe it or not, it *is* surprising. You have to stumble upon nasty side effects to start thinking about the issue. Being a long-term user and developer of lilypond, even I skipped the `fine print' until now. We don't allow assignments inside of music expressions either, and again the reason is not as much that it wouldn't be possible to allow them there, but rather that people would be surprised that reassigning a variable inside of music will affect previous uses of it and not be in any conceivable way synchronized with the flow of music. You are correct, of course, but this is not obvious at a first glance. Could you add a corollary of our e-mail exchange on this topic to the documentation? Perhaps a section `When does variable expansion happen?'... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \bookpart and variables
Werner LEMBERG w...@gnu.org writes: We don't allow assignments inside of music expressions either, and again the reason is not as much that it wouldn't be possible to allow them there, but rather that people would be surprised that reassigning a variable inside of music will affect previous uses of it and not be in any conceivable way synchronized with the flow of music. You are correct, of course, but this is not obvious at a first glance. Could you add a corollary of our e-mail exchange on this topic to the documentation? Perhaps a section `When does variable expansion happen?'... I'll try keeping it in mind. In mean time, scores have \header blocks, and books have \paper blocks, and some information can be put there and will indeed stay local to those blocks and scores and books. One can't usefully _change_ variables there: the meaningful uses are basically as constants given a value that they keep. If we find that we are missing tools for organizing scores in a useful manner, we'll need to think about how we can arrive at semantics that better reflect what people want to put into their sources while still working well for the kind of batch parsing we employ (and which will likely eventually be our road into comparatively reliable MusicXML ex- and import). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: systems-per-page and blank-page-penalty
On 09/02/15 10:19, Werner LEMBERG wrote:
consider the following snippet.
#(set-default-paper-size a6)
\paper { systems-per-page = 6 blank-page-penalty = 1000
#(define page-breaking ly:page-turn-breaking)
copyright = footer = tagline = }
m = \relative c' { f'8 f, f f f f f f | \repeat unfold 11 { f8 f f
f f f f f } | }
{ \m \allowPageTurn \m \allowPageTurn \m \m }
There is a blank page in it, and I would like to avoid that, thus
the `blank-page-penalty' parameter. [In this demo snippet the
result would be extremely ugly, but in real-life situations with
more break points it would be much less disturbing.]
However, it doesn't work.
Looking into `page-breaking.cc' (function
`Page_breaking::space_systems_on_n_or_one_more_pages'), I see that
no blank page penalties are checked if `systems-per-page' is set.
This looks wrong to me.
Werner
Maybe I'm being a bit hasty but
https://code.google.com/p/lilypond/issues/detail?id=4285
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The status of Lilypond and Guile 2?
Am 2015-02-09 um 01:34 schrieb Edward d'Auvergne true.bug...@gmail.com: I was wondering what the current status of Guile 2 support in Lilypond is? The dev/guilev2 branch hasn't been touched since 2014-10-13. It is becoming more and more impossible to run Lilypond on modern Linux distributions (for example see https://bugs.mageia.org/show_bug.cgi?id=10969). Is there any relief in sight? Have a look at the mailing list’s archives, it was discussed just yesterday or maybe two days before in the GSoC thread: The problem is Guile 2’s garbage collection that’s incompatible with LilyPond’s internal data structures. Only the Guile developers can really solve this; as far as I understood, there are a lot more issues in Guile 2; looks to me like nobody uses Guile as much as LilyPond... Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net http://angerweit.tikon.ch/lieder/ https://www.cacert.org (I'm an assurer) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
systems-per-page and blank-page-penalty
Folks,
consider the following snippet.
#(set-default-paper-size a6)
\paper {
systems-per-page = 6
blank-page-penalty = 1000
#(define page-breaking ly:page-turn-breaking)
copyright =
footer =
tagline =
}
m = \relative c' {
f'8 f, f f f f f f |
\repeat unfold 11 { f8 f f f f f f f } |
}
{
\m \allowPageTurn
\m \allowPageTurn
\m
\m
}
There is a blank page in it, and I would like to avoid that, thus the
`blank-page-penalty' parameter. [In this demo snippet the result
would be extremely ugly, but in real-life situations with more break
points it would be much less disturbing.]
However, it doesn't work.
Looking into `page-breaking.cc' (function
`Page_breaking::space_systems_on_n_or_one_more_pages'), I see that no
blank page penalties are checked if `systems-per-page' is set. This
looks wrong to me.
Werner
blank-page.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The status of Lilypond and Guile 2?
Edward d'Auvergne true.bug...@gmail.com writes: Hi, I was wondering what the current status of Guile 2 support in Lilypond is? The dev/guilev2 branch hasn't been touched since 2014-10-13. That corresponds with the last time I got a promise GUILEv2 developers would take a look at our GC problems. It is becoming more and more impossible to run Lilypond on modern Linux distributions (for example see https://bugs.mageia.org/show_bug.cgi?id=10969). Is there any relief in sight? I've scheduled making the dev/guilev2 branch unnecessary for initial GUILEv2 work this week as I got another promise. After GUILEv2 work can be done on master directly, GUILEv2 developers will be able to experiment with a current master anytime they feel like following up on promises. So you'll be able to ask your question on the GUILE developer list soon. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: systems-per-page and blank-page-penalty
Maybe I'm being a bit hasty but https://code.google.com/p/lilypond/issues/detail?id=4285 Thanks. It perhaps makes sense to add the PDF file also... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clean up inconsistencies in engraver-init.ly and performer-init.ly (issue 199460043 by thomasmorle...@gmail.com)
On 2015/02/09 06:09:34, lemzwerg wrote: LGTM. It would be nice if David's checker script could be added, too. More, I'd consider it a good idea to use the checker on the current patch again. There was such a mess that I'm not sure I corrected all. https://codereview.appspot.com/199460043/diff/20001/ly/performer-init.ly File ly/performer-init.ly (right): https://codereview.appspot.com/199460043/diff/20001/ly/performer-init.ly#newcode174 ly/performer-init.ly:174: \accepts ChordNames I wonder whether it makes sense to sort the many \accept lines alphabetically... I'd happily do it, though, why alpabetically? And why only for the lines with \accept, could be done for the context-defs as well. And it's also thinkable to sort it following context-hierarchy: first bottom-contexts like Voice, then Staff up to Score and Global. Or vice versa... What do others think? https://codereview.appspot.com/199460043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allow independent adjustment of minimum length for spanner siblings (issue 201140043 by david.nales...@gmail.com)
LGTM https://codereview.appspot.com/201140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
