Re: Reorganizing the contents of the \paper block
Trevor Bača wrote:
OTOH, I really do believe that the reason most
users walk around without a solid model of file structure (or score
structure) in their heads isn't because chapters 3 - 5 (which are
*amazingly* helpful and huge improvement over the previous manual,
which was essentially silent on these points) are in some way
deficient, but instead because the vast majority of actual lily code
which users (both new and experienced) look at simply doesn't
*reinforce* that file structure. See below ...
I disagree. (sidenote: there's info about file structure in chapter 10
as well, which is linked to in chapter 3 I believe).
Let's do this logically:
1) experienced users understand the structure.
2) the purpose of the documentation is to allow an interested,
reasonably intelligent, inexperienced user to do everything an
experienced user can do.
3) interested, reasonably intelligent, inexperienced users do not
understand the structure.
4) the documentation is flawed.
I have no difficulty admitting that the docs are flawed ("flawed" = "not
perfect"). If #3 is true -- and I admit that I do not currently
believe* that is _is_ true -- then the docs should be improved. By now,
everybody knows how to do this.
* I don't have a lot of evidence to back this up -- but then again, I
doubt that other people have evidence to counter this claim.
Carl:
I think if you asked 100 novice users of LilyPond about that
relationship, fewer than 5 could articulate it.
Trevor again:
Are users willfully ignoring 3 - 5?
My belief? Yes.
Look, LilyPond is complicated. Before a new user starts doing serious
work, he should read AT LEAST chapters 2, 3, 4, 5, 6, any relevant
sections in 7 and 8, 10.1, 10.2, 11.1, appendix D, and know that
appendix G and H exist.
That doesn't include any fancy things like \override, scheme, or
changing the spacing. All that documentation -- probably about 100
pages of printed material -- just to properly write basic music syntax
with the default output, without shooting himself in the foot by doing
things incorrectly.
That's a lot of stuff to read. A _lot_. I've been experiencing similar
pains: in the past year, I've written non-trivial programs (with little
or no previous experience) in ChucK, perl, java, C++, python, and QT
(not a language, but still requires a lot of doc-reading). I've had to
read a lot of documentation, and sometimes I've wanted to scream -- if I
know how to something in perl, why should I spend an hour reading the
python tutorial to figure out how to do in it that language?!
But there really isn't another option. Programming languages are
complicated. Fully-featured layout languages are complicated. You
can't do anything (serious) in LaTeX without having a heavily-used pdf
of "the short guide to LaTeX" on your desktop.
I don't blame users for ignoring chapters 3-5... but at the same time,
I'm not going to wring my hands in sympathy for them. The information
is there. Could it be improved? Sure. All documentation suggestions
are welcome. Would it be easier for new users if every lilypond example
were constructed in the same way? Yes, definitely. When I started
writing Appendix D, I tried to make each template with the same style.
But there's a lot of examples that need to be updated, and I don't have
much time.
If anybody wants to volunteer to do a clean-up of the manual and LSR
snippets -- I mean, cleaning up the LSR snippets to a higher level than
I think the LSR maintainer should do -- then I will enthusiastically
accept your help. Budget at least 50 hours for this task.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača wrote: I dunno. I don't wanna type more stuff (explicit \score and \book and whatever) all the time, but I'm pretty convinced that both file structure and score structure will remain confusing for new and even experienced users right up until the point that we do make such a requirement. What about adding some sort of switch? An advanced option, so to speak. Much like I include #(ly:set-option 'point-and-click #f) at the top of every score, since I don't need point and click, maybe we could create a #(ly:set-option 'strict-structure #f) for advanced users. This would allow for requiring strict file structure until you feel comfortable enough to not need it. We would probably have to allow it as a command line option as well, otherwise all the doc examples, etc., would need the switch and that could be cumbersome. Just thinking out loud, here. I haven't delved into the code that allows the structure to be so fluid, so I'm not sure how much work this would be to implement. Cheers, Bryan... --- Bryan Stanbridge[EMAIL PROTECTED] Purple Frog Press www.purplefrogpress.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/8/07, Graham Percival <[EMAIL PROTECTED]> wrote:
Han-Wen Nienhuys wrote:
> Trevor Bača escreveu:
>> Wow. I really like this. Anyone else?
>
> I don't.
I don't like it either, but for different reasons.
- how do identifiers work? Where do we define them? Does it make sense
for an identifier to be bound up in the "File" or "Book" or "Staff"
contexts?
Right. Han-Wen makes this point, too, later in the thread, and I think
I'm finally getting it. Putting forth a strict File { Book { Score {
Staff { Voice } } } } model only works if our input files are limited
to *static* data definitions or "pure" expressions (more or less like
XML).
Our input files do, in fact, contain static data definitions, or
"pure" expressions, as Han-Wen writes ...
Some parts of the input resemble 'pure' expressions
(ie. data), for example \markup and music expressions,
but also \book and \score.
... but -- crucially -- our input files also contain dynamic commands
(ie, expressions with side effects).
Music expressions and markup may very well be the most *interesting*
parts of an input file, but they are not the *only* parts of an input
file, and this is where the File { Book { Score ... } } model won't
work.
- explicitly adding everything is fine for big files, but we have about
300 bugs and we'll have another 200 during the next year. I really
don't want to add extra fluff to them... and that says nothing about the
docs.
True. I still think this is a tricky question. I write a number of
snippet and bugs and it would definitely be more effort to wrap each
one in \score, etc. OTOH, I really do believe that the reason most
users walk around without a solid model of file structure (or score
structure) in their heads isn't because chapters 3 - 5 (which are
*amazingly* helpful and huge improvement over the previous manual,
which was essentially silent on these points) are in some way
deficient, but instead because the vast majority of actual lily code
which users (both new and experienced) look at simply doesn't
*reinforce* that file structure. See below ...
You said that university people had problem with file structure... were
you teaching this course with the new-ish chapters 3-5? Did you point
them at the templates? IMO, if you've read 3.1 - 3.3, 4.1 - 4.2, and a
couple of the templates in Appendix D, it's clear how lilypond files
work. If not, we should improve those docs instead of making a
radically new file structure.
I agree now (after going through all this) that a radically new file
structure won't help.
However, I also think that chatpers 3 - 5 are quite well written and
don't need any serious updates.
And yet, as Carl points out (and I agree), the fact is that most users
(probably even experienced users) don't walk around with a solid
mental picture of file structure (or score model -- and I suppose
those two things are different) in their heads, CS:
"... notes exist in Voices which exist in Staffs
which exist in Scores.
I think if you asked 100 novice users of LilyPond about that
relationship, fewer than 5 could articulate it.
I think if you asked 100 users who had created "normal" music (i.e.,
music that doesn't require any special constructs, but can be based on
templates and examples), 50 or less could articulate that relationship.
And even fewer could articulate that Scores exist in Books which exist
in Paper."
/CS
I think Carl is right on this. But if chapters 3 - 5 actually are
sufficient (and I think they are, minus maybe a couple of smallish
additions here and there) then what's going on? If we have well
written descriptions of file structure (and score structure), then why
do users keep bringing so many structure-related questions to the
table (which we can see, for example, in Mats's need to keep repeating
basic skeleton structure over and over in his didactic mail for new
users)? Are users willfully ignoring 3 - 5? Or is something else going
on here?
The answer must be that the parts of the docs and the list that users
actually use all the time when they're writing music don't reinforce
file or score structure. IOW, we detail file and score structure well
in chapters 3 - 5, but the parts of the manual and the list that
people use all the time (how do I add articulations? how do I move
slur points around? can I change whether accidentals are forced to
print or not?, etc etc) don't do anything to reinforce these
structures and, in fact, render the structures mostly invisible.
I dunno. I don't wanna type more stuff (explicit \score and \book and
whatever) all the time, but I'm pretty convinced that both file
structure and score structure will remain confusing for new and even
experienced users right up until the point that we do make such a
requirement.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Reorganizing the contents of the \paper block
> -Original Message-
> From: Carl D. Sorensen
> Sent: Friday, February 09, 2007 7:48 AM
> >
> > independenty of this
> >
> > \book {
> > \score {
> > \layout {
> > %% A
> > }
> > }
> > \paper {
> >%% B
> > }
> >}
> >
> > means
> >
> > \book {
> > \score {
> > \layout { \$defaultlayout
> > %% A
> > }
> > }
> > \paper { \$defaultpaper
> >%% B
> > }
> >}
> >
>
> Perhaps part of the confusion about the overall structure of
> LilyPond arises from the fact that sometimes (e.g. when
> identifiers are used), the order of statements matter; while
> at other times (e.g. %B being a place to lookup layout
> variables from %A) the order doesn't matter. In fact, in the
> lookup process you described above, there is no clue in the
> file that (i) %B is defined for a \book, (ii) the \score is
> contained in a \book, and (iii) the \layout of which %B is a
> part is in any sort of scope that includes the \score of
> which %A is a part.
I'm sorry -- I didn't read the example carefully enough. My comment applies to
the syntax with the \book missing, where it is implicit, rather than explicit.
Carl Sorensen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Reorganizing the contents of the \paper block
> No, top-level \paper sets a default for the \book level \paper.
> top-level \layout sets a default for \score level \layout.
>
> \layout { X }
> \paper { Y }
>
> mean
>
> $defaultlayout = \layout { \$defaultlayout X } $defaultpaper
> = \layout { \$defaultpaper X }
>
> independenty of this
>
> \book {
> \score {
> \layout {
> %% A
> }
> }
> \paper {
>%% B
> }
>}
>
> means
>
> \book {
> \score {
> \layout { \$defaultlayout
> %% A
> }
> }
> \paper { \$defaultpaper
>%% B
> }
>}
>
>
> If at run time, a score-level layout variable, such as
> ragged-right, is looked up in %A.
> If it's not found, it is looked
> up in %B. If it's not found in %B, then it is assumed undefined.
>
> iow. There are 2 orthogonal mechanisms:
>
> - toplevel output-defs set defaults, which are copied
> implicitly during parsing ( $defaultlayout / $defaultpaper )
>
> - the \paper (book level) is parent to \layout (score
> level), this parent relation is employed during formatting.
>
Perhaps part of the confusion about the overall structure of LilyPond arises
from the fact that sometimes (e.g. when identifiers are used), the order of
statements matter; while at other times (e.g. %B being a place to lookup layout
variables from %A) the order doesn't matter. In fact, in the lookup process
you described above, there is no clue in the file that (i) %B is defined for a
\book, (ii) the \score is contained in a \book, and (iii) the \layout of which
%B is a part is in any sort of scope that includes the \score of which %A is a
part.
Carl Sorensen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/8/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Trevor Bača escreveu:
> The first command sets the size of all pages. The second command sets
> the size of the pages that the \paper block applies to – if the \paper
> block is at the top of the file, then it will apply to all pages. If
> the \paper block is inside a \book, then the paper size will only
> apply to that book."
I rather think that the problem is that the input file of Lily is not
a data definition. You've tried to make it look like one by proposing
\new File, but it really isn't:
- we have identifiers; those imply state. for example
foo= { c4 d8 }
<< \foo \foo >>
is valid, but
<< \foo \foo >>
foo= { c4 d8 }
is not. So, we have statefulness.
- we have an entire scheme interpreter under the hood,
#(set-default-paper-size "a4")
executes a command which has side-effects.
I think it would be best if we were more straightforward,
and tell users that an input file is a sequence of commands
which are run in an interpreter. We're doing that anyway:
each .ly file actually is a Scheme module, and the whole file
is a sequence of top-level expressions, which are evaluated one
by one.
Some are directly run as Scheme expressions, such as
#(set-default-paper-size "a4")
Some parts of the input resemble 'pure' expressions
(ie. data), for example \markup and music expressions,
but also \book and \score.
Then, expressions at toplevel have side effects,
* foo = bar
defines identifier \foo
* \header { .. }
is an expression, eg. you can do
bla = \header { .. }
however, if you have a \header{} at toplevel,
it sets the default header.
* #(set-default-paper-size .. )
sets the default paper size
* \book { .. }
will produce an PS/PDF file as side effect
I think this is a well established concept. IN python, you can type
pure data as a toplevel expressions, eg.
"foo"
is valid python. But you can also define variables, either by
def bar(x): pass
or
bar = lambda x: 1
and execute statements with side effects, eg.
print "hello world"
In fact, some interpreters have a REPL (read-eval-print-loop), which are
written in the language itself. This is conceptually similar to
toplevel-handlers that we have in LilyPond.
The behavior of toplevel expressions is actually configurable
at run-time. This is a very useful, because it allows us to
make \book and \score behave differently in normal operation and
in lilypond-book.
See ly/declarations-init.ly and ly/lilypond-book-preamble.ly for the
relevant code.
> The language is actually then considerably clearer: no more \paper (at
> two scoping levels) and \layout (at three scoping levels). Just
> \score-settings, \book-settings and \global-settings naming unique
> slots for input entry. Furthermore, examples in the docs or on the
> list like \paper { whatever } will no longer be ambiguous as to level
> of scope. We will have either \book-settings { whatever } or
> \global-settings { whatever } instead.
this looks superfluous to me, in that we could just use \settings{}
everywhere. Introducing 3 keywords would make the documentation more
consistent and/or clearer. My experience is that it doesn't work, because
people won't use it. We have had \simultaneous { .. } as a
more correct form of << .. >> , but I've never seen it being used.
Hi Han-Wen,
Thanks for the detailed explanations and also for the pointers on how
to think about what's really going on in input.
The point about about the assignment of identifiers implying state in
an input file is the clencher in this argument (as you and Graham were
both pointing to) -- our input files do *not* define (static) data but
instead give a sequence of *commands*, interpreted one by one.
OK, so I'll return tomorrow one more time to the question of how to
possibly clean up (or maybe just better document) the settings that
fit in \paper and \layout, probably by considering one last time the
suggestion of collapsing both into a generic \settings block (which
can then live at any of the three levels of scope).
I've really gotten a lot from thinking through alternatives -- even
the impractical ones -- and I definitely appreciate the dialogue and
the examples.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu:
> The first command sets the size of all pages. The second command sets
> the size of the pages that the \paper block applies to – if the \paper
> block is at the top of the file, then it will apply to all pages. If
> the \paper block is inside a \book, then the paper size will only
> apply to that book."
I rather think that the problem is that the input file of Lily is not
a data definition. You've tried to make it look like one by proposing
\new File, but it really isn't:
- we have identifiers; those imply state. for example
foo= { c4 d8 }
<< \foo \foo >>
is valid, but
<< \foo \foo >>
foo= { c4 d8 }
is not. So, we have statefulness.
- we have an entire scheme interpreter under the hood,
#(set-default-paper-size "a4")
executes a command which has side-effects.
I think it would be best if we were more straightforward,
and tell users that an input file is a sequence of commands
which are run in an interpreter. We're doing that anyway:
each .ly file actually is a Scheme module, and the whole file
is a sequence of top-level expressions, which are evaluated one
by one.
Some are directly run as Scheme expressions, such as
#(set-default-paper-size "a4")
Some parts of the input resemble 'pure' expressions
(ie. data), for example \markup and music expressions,
but also \book and \score.
Then, expressions at toplevel have side effects,
* foo = bar
defines identifier \foo
* \header { .. }
is an expression, eg. you can do
bla = \header { .. }
however, if you have a \header{} at toplevel,
it sets the default header.
* #(set-default-paper-size .. )
sets the default paper size
* \book { .. }
will produce an PS/PDF file as side effect
I think this is a well established concept. IN python, you can type
pure data as a toplevel expressions, eg.
"foo"
is valid python. But you can also define variables, either by
def bar(x): pass
or
bar = lambda x: 1
and execute statements with side effects, eg.
print "hello world"
In fact, some interpreters have a REPL (read-eval-print-loop), which are
written in the language itself. This is conceptually similar to
toplevel-handlers that we have in LilyPond.
The behavior of toplevel expressions is actually configurable
at run-time. This is a very useful, because it allows us to
make \book and \score behave differently in normal operation and
in lilypond-book.
See ly/declarations-init.ly and ly/lilypond-book-preamble.ly for the
relevant code.
> The language is actually then considerably clearer: no more \paper (at
> two scoping levels) and \layout (at three scoping levels). Just
> \score-settings, \book-settings and \global-settings naming unique
> slots for input entry. Furthermore, examples in the docs or on the
> list like \paper { whatever } will no longer be ambiguous as to level
> of scope. We will have either \book-settings { whatever } or
> \global-settings { whatever } instead.
this looks superfluous to me, in that we could just use \settings{}
everywhere. Introducing 3 keywords would make the documentation more
consistent and/or clearer. My experience is that it doesn't work, because
people won't use it. We have had \simultaneous { .. } as a
more correct form of << .. >> , but I've never seen it being used.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu:
>> > So this means there are really three levels of scope at which these
>> > settings can be made ...
>> >
>> > 1. at score level (which is most specific)
>> > 2. at book level (which is intermediate), and
>> > 3. at top level
>> >
>> > ... as reflected in the following example:
>> >
>> > %%% BEGIN 3-LEVELS OF SCOPE %%%
>> >
>> > \version "2.11.16"
>> >
>> > \paper { indent = #100 }
>> >
>> > \book {
>> >
>> > \paper { indent = #50 }
>> >
>> > \score {
>> > \new Staff { c'1 }
>> > \layout { indent = #0 }
>> > }
>> >
>> > }
>> >
>> > %%% END %%%
>> >
>> > If I comment out the score-level indent, then the book-level indent
>> > will take over. If I comment out both the score-level and book-level
>> > indents, then the top-level indent will take over.
>>
>> No, the \book level indent overwrites the toplevel
>>
>> \paper { indent = #75 }
>> \book {
>>\paper { indent = #50 }
>> }
>>
>> really maens
>>
>> "$defaultpaperblock" = \paper { \$defaultpaperblock indent = #75 }
>> \book {
>> \paper { \$defaultpaperblock indent = #50 }
>> }
>
> I think we're saying the same thing. To make sure:
>
> 1. score-level settings will overwrite book-level settings
> 2. book-level settings will overwrite top-level settings
>
> Or, put another way:
>
> 1. a top-level setting is the most general, broadly scoped type of setting
> 2. a book-level setting is more specific and more narrowly scope
> 3. and a score-level setting is the most specific, most narrowly scope
> type of setting of the three types listed here
>
> Correct?
No, top-level \paper sets a default for the \book level \paper.
top-level \layout sets a default for \score level \layout.
\layout { X }
\paper { Y }
mean
$defaultlayout = \layout { \$defaultlayout X }
$defaultpaper = \layout { \$defaultpaper X }
independenty of this
\book {
\score {
\layout {
%% A
}
}
\paper {
%% B
}
}
means
\book {
\score {
\layout { \$defaultlayout
%% A
}
}
\paper { \$defaultpaper
%% B
}
}
If at run time, a score-level layout variable,
such as ragged-right, is looked up in %A.
If it's not found, it is looked
up in %B. If it's not found in %B, then it is
assumed undefined.
iow. There are 2 orthogonal mechanisms:
- toplevel output-defs set defaults, which are
copied implicitly during parsing ( $defaultlayout / $defaultpaper )
- the \paper (book level) is parent to \layout (score level),
this parent relation is employed during formatting.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu:
> %%% BEGIN %%%
>
> \new File \with {
> \sourcefilename "backend-svg.ly"
> \sourcefileline 0
> #(ly:set-option 'backend 'svg)
> #(set! output-count 1)
> \include "typography-demo.ly"
> \version "2.11.16"
> #(define outname (ly:parser-output-name parser))
> #(ly:set-option 'backend 'eps)
> #(display "Invoking inkscape...\n")
> #(system (format #f "LD_LIBRARY_PATH= inkscape -T -E ~a-1.eps
> ~a-1.svg" outname outname))
> #(set! output-count 0)
> #(set-default-paper-size "a5") } {
>
> \new Book \with {
>texidoc = "SVG output, rendered through inkscape."
>title = "SVG" } {
>
>\new Score {
> \lyrics {
>\markup {
> \epsfile #X #30.0 #(format #f "~a-1.eps" outname)
>}
>x x x
> }
>}
> }
> }
> }
>
> %%% END %%%
>
> ?
>
> All settings (including Scheme commands) are still available, just put
> in a *named place* in the input file, rather than floating freely in
> space ...
then what does it mean, \new File? You've just created a new place
( \new File { ... } ) with absolutely no structure.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Han-Wen Nienhuys wrote: Trevor Bača escreveu: Wow. I really like this. Anyone else? I don't. I don't like it either, but for different reasons. - how do identifiers work? Where do we define them? Does it make sense for an identifier to be bound up in the "File" or "Book" or "Staff" contexts? - explicitly adding everything is fine for big files, but we have about 300 bugs and we'll have another 200 during the next year. I really don't want to add extra fluff to them... and that says nothing about the docs. You said that university people had problem with file structure... were you teaching this course with the new-ish chapters 3-5? Did you point them at the templates? IMO, if you've read 3.1 - 3.3, 4.1 - 4.2, and a couple of the templates in Appendix D, it's clear how lilypond files work. If not, we should improve those docs instead of making a radically new file structure. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
A setting in the Score \with block?
\new Score \with { output = midi } { ... }
\new Score \with { output = pdf } { ... }
On 2/8/07, Kress, Stephen <[EMAIL PROTECTED]> wrote:
It's a nice start. How would you specify what you wanted for output (i.e.,
PDF (ps) vs. MIDI)? It might look a little weird if you needed a Book for
MIDI output...
Stephen
-Original Message-
From: Trevor Baca [mailto:[EMAIL PROTECTED]
Sent: Thu 2/8/2007 12:20 PM
To: Han-Wen Nienhuys
Cc: Kress, Stephen; lilypond-devel
Subject: Re: Reorganizing the contents of the \paper block
On 2/8/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>
> [-user trimmed]
>
> Trevor Baca escreveu:
> > Wow. I really like this. Anyone else?
>
> I don't.
>
>
> * Have a look at input/regression/backend-svg.ly
> How do I do this with a tightly defined structure?
%%% BEGIN %%%
\new File \with {
\sourcefilename "backend-svg.ly"
\sourcefileline 0
#(ly:set-option 'backend 'svg)
#(set! output-count 1)
\include "typography-demo.ly"
\version "2.11.16"
#(define outname (ly:parser-output-name parser))
#(ly:set-option 'backend 'eps)
#(display "Invoking inkscape...\n")
#(system (format #f "LD_LIBRARY_PATH= inkscape -T -E ~a-1.eps
~a-1.svg" outname outname))
#(set! output-count 0)
#(set-default-paper-size "a5") } {
\new Book \with {
texidoc = "SVG output, rendered through inkscape."
title = "SVG" } {
\new Score {
\lyrics {
\markup {
\epsfile #X #30.0 #(format #f "~a-1.eps" outname)
}
x x x
}
}
}
}
}
%%% END %%%
?
All settings (including Scheme commands) are still available, just put
in a *named place* in the input file, rather than floating freely in
space ...
> * You're mixing up the Music type (which has length and
> pitch) with various others which don't. Looks nice in an example
> like you gave, but is semantically clear as mud.
>
> I think the discussion would be served if it starts
> with how stuff works on the inside now, and how that
> can be improved. Different and more logical syntax will
> follow as a side effect.
That's a good place for Erik to lead, probably, since he has a good
handle on the internals.
--
Trevor Baca
[EMAIL PROTECTED]
2007-02-08, 12:59:45
The information contained in this e-mail message and any attachments may be
privileged and confidential. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that any review, dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please notify the sender
immediately by replying to this e-mail and delete the message and any
attachments from your computer.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/8/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
[-user trimmed]
Trevor Bača escreveu:
> Wow. I really like this. Anyone else?
I don't.
* Have a look at input/regression/backend-svg.ly
How do I do this with a tightly defined structure?
%%% BEGIN %%%
\new File \with {
\sourcefilename "backend-svg.ly"
\sourcefileline 0
#(ly:set-option 'backend 'svg)
#(set! output-count 1)
\include "typography-demo.ly"
\version "2.11.16"
#(define outname (ly:parser-output-name parser))
#(ly:set-option 'backend 'eps)
#(display "Invoking inkscape...\n")
#(system (format #f "LD_LIBRARY_PATH= inkscape -T -E ~a-1.eps
~a-1.svg" outname outname))
#(set! output-count 0)
#(set-default-paper-size "a5") } {
\new Book \with {
texidoc = "SVG output, rendered through inkscape."
title = "SVG" } {
\new Score {
\lyrics {
\markup {
\epsfile #X #30.0 #(format #f "~a-1.eps" outname)
}
x x x
}
}
}
}
}
%%% END %%%
?
All settings (including Scheme commands) are still available, just put
in a *named place* in the input file, rather than floating freely in
space ...
> * You're mixing up the Music type (which has length and
pitch) with various others which don't. Looks nice in an example
like you gave, but is semantically clear as mud.
I think the discussion would be served if it starts
with how stuff works on the inside now, and how that
can be improved. Different and more logical syntax will
follow as a side effect.
That's a good place for Erik to lead, probably, since he has a good
handle on the internals.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
[-user trimmed] Trevor Bača escreveu: > Wow. I really like this. Anyone else? I don't. * Have a look at input/regression/backend-svg.ly How do I do this with a tightly defined structure? * You're mixing up the Music type (which has length and pitch) with various others which don't. Looks nice in an example like you gave, but is semantically clear as mud. I think the discussion would be served if it starts with how stuff works on the inside now, and how that can be improved. Different and more logical syntax will follow as a side effect. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/8/07, Trevor Bača <[EMAIL PROTECTED]> wrote:
On 2/8/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> Trevor Bača escreveu:
>
> > Note that this is not a zero-code proposal, however: the idea of
> > collapsing \paper and \layout is a pretty serious structural change,
> > even though I think it makes extremely good sense.
>
> It's actually not. Inside the code it's already implemented like that.
> The difference between paper and layout is that paper has a
>
> is-paper = ##t
>
> setting.
OK. So this means that if we build consensus for the "collapse \paper
and \layout into \settings" proposal (which we haven't done yet) then
at least the implementation will be straightforward. That's good.
> What you're really losing is the ability to set a default for the \layout
> block.
Oh I hope not.
If we do away with \paper and \layout and wind up instead with
\score-settings, \book-settings and \global-settings, then we should
be able to set a value in \book-settings which will then act as the
default for any values in \score-settings. This should preserve the
ability to set defaults, I believe. Ex:
%%% BEGIN %%%
\global-settings { }
\book {
\book-settings { special-layout-setting = foo }
\score {
\new Staff { c'4 }
}
\score {
\new Staff { c'4 }
\score-settings { special-layout-setting = bar }
}
}
%%% END %%%
In this example, we have two scores both living inside the same book.
Score 1 will inherit special-layout-setting as foo from
\book-settings. Score 2 likewise inherits special-layout-settings as
foo from \book-settings but then overrides the value of
special-layout-setting to bar in the \score-settings block.
So \book-settings gives us the ability to set defaults for all of our
different scores within a single book, which we are then free to
override with a \score-settings block inserted directly into any
particular score.
So we actually do preserve the ability to set (and overide) defaults, yes?
> > Perhaps if we wind up wanting to collapse \layout and \paper, then we
> > can simply rip \context blocks out and leave them as free-standing
> > elements within a \score. But this is a sidenote until we consider
> > whether collapsing \paper and \layout even makes sense.]
>
> No, I think that in this case, the \context definitions have to go into
> \settings as well, ie. in the \book wide settings.
OK.
OK, I'm going to float one last proposal that I know will be much
harder to implement, though I do think it's worth mentioning if for
nothing other than to add to the discourse.
NOTE: this is a second and different proposal from the "compress
\paper and \layout into \settings" proposal. More radical and we might
call this the "ubiquitous \with" proposal.
What about a file structure like this:
%%% BEGIN UBIQUITOUS WITH %%%
\new File \with { % ALL possible top-level settings live here } {
\new Book \with { % ALL possible book-level settings live here} {
\new Score \with { % ALL possible score-level settings live here } {
\new Staff \with { % ALREADY all possible staff settings
can live here } { c'4 }
}
}
}
%%% END %%%
That's it: NO special input blocks of *any* sort -- no \layout, no
\paper, no \midi, no \settings, no nothing. Nada. Not even any
top-level Scheme commands. This would in many ways be a *super* clean
way of organizing both music content and settigs of all sorts. Every
setting that exists would go into the \with-block of an actual piece
of real input -- File, Book, Score, Staff, Voice, right on down the
hierarchy.
Benefits:
* Semantic input blocks only
* All settings attach to one input block
* Clear nesting; all elements of hierarchy named uniquely
* Kills off \paper, \layout, \midi (or \settings) reducing the need to
ever document or refer to these again
* Extends existing and effective \with pattern to (all) other input objects
* Provides absolutely unambiguous written language to describe where a
setting is made ("in the File \with-block, in the Book \with-block, in
the Score \with-block, in the Staff \with-block, etc".)
* Unifies currently disjunct parts of the input language because book
(and the newly proposed File) starts to look like the Score, Staff,
Voice, etc.
* Kinda looks like XML
* Provides absolutely unambiguous definition for what an input file
actually *is*: "A Lily input file comprises exactly one File block,
which comprises one to many Book blocks, each of which comprise one to
many Score blocks, each of which comprises exactly one music
expression. Settings for all blocks live in the special \with
construct." Period.
Wow. I really like this. Anyone else?
OK, so I'm also sure this blows up tons of stuff ... Han-Wen? As a
longer term design goal, say for 3.0?
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/8/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Trevor Bača escreveu:
> Note that this is not a zero-code proposal, however: the idea of
> collapsing \paper and \layout is a pretty serious structural change,
> even though I think it makes extremely good sense.
It's actually not. Inside the code it's already implemented like that.
The difference between paper and layout is that paper has a
is-paper = ##t
setting.
OK. So this means that if we build consensus for the "collapse \paper
and \layout into \settings" proposal (which we haven't done yet) then
at least the implementation will be straightforward. That's good.
What you're really losing is the ability to set a default for the \layout
block.
Oh I hope not.
If we do away with \paper and \layout and wind up instead with
\score-settings, \book-settings and \global-settings, then we should
be able to set a value in \book-settings which will then act as the
default for any values in \score-settings. This should preserve the
ability to set defaults, I believe. Ex:
%%% BEGIN %%%
\global-settings { }
\book {
\book-settings { special-layout-setting = foo }
\score {
\new Staff { c'4 }
}
\score {
\new Staff { c'4 }
\score-settings { special-layout-setting = bar }
}
}
%%% END %%%
In this example, we have two scores both living inside the same book.
Score 1 will inherit special-layout-setting as foo from
\book-settings. Score 2 likewise inherits special-layout-settings as
foo from \book-settings but then overrides the value of
special-layout-setting to bar in the \score-settings block.
So \book-settings gives us the ability to set defaults for all of our
different scores within a single book, which we are then free to
override with a \score-settings block inserted directly into any
particular score.
So we actually do preserve the ability to set (and overide) defaults, yes?
> Perhaps if we wind up wanting to collapse \layout and \paper, then we
> can simply rip \context blocks out and leave them as free-standing
> elements within a \score. But this is a sidenote until we consider
> whether collapsing \paper and \layout even makes sense.]
No, I think that in this case, the \context definitions have to go into
\settings as well, ie. in the \book wide settings.
OK.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/8/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Trevor Bača escreveu:
> On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>> Trevor Bača escreveu:
>>
>> > Right now both list 1 and list 2 will just be put together into the
>> > outside-of-score (\paper) bucket.
>> >
>> > But it seems that may list 1 is really concerned with the *the layout
>> > of music on the page* whereas list 2 is concerned with *adding headers
>> > and footers outside the music*.
>> >
>> > So does it make sense to divide list 1 and list 2? And if so, with what
>> > names?
>>
>> I think this doesn't make sense. There are two output-def objects with
>> nested
>> scope. Variables that by their nature have \book-wide effect, go into
>> the outer
>> scope, variables that are score-wide may be put in the inner scope.
>>
>> If that confuses you, it might be a better idea to rename \layout and
>> \paper to
>> better reflect this.
>
> Another point of clarification:
>
> So this means there are really three levels of scope at which these
> settings can be made ...
>
> 1. at score level (which is most specific)
> 2. at book level (which is intermediate), and
> 3. at top level
>
> ... as reflected in the following example:
>
> %%% BEGIN 3-LEVELS OF SCOPE %%%
>
> \version "2.11.16"
>
> \paper { indent = #100 }
>
> \book {
>
> \paper { indent = #50 }
>
> \score {
> \new Staff { c'1 }
> \layout { indent = #0 }
> }
>
> }
>
> %%% END %%%
>
> If I comment out the score-level indent, then the book-level indent
> will take over. If I comment out both the score-level and book-level
> indents, then the top-level indent will take over.
No, the \book level indent overwrites the toplevel
\paper { indent = #75 }
\book {
\paper { indent = #50 }
}
really maens
"$defaultpaperblock" = \paper { \$defaultpaperblock indent = #75 }
\book {
\paper { \$defaultpaperblock indent = #50 }
}
I think we're saying the same thing. To make sure:
1. score-level settings will overwrite book-level settings
2. book-level settings will overwrite top-level settings
Or, put another way:
1. a top-level setting is the most general, broadly scoped type of setting
2. a book-level setting is more specific and more narrowly scope
3. and a score-level setting is the most specific, most narrowly scope
type of setting of the three types listed here
Correct?
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/8/07, Mats Bengtsson <[EMAIL PROTECTED]> wrote:
Carl D. Sorensen wrote:
> On a related note, I think it would be cleaner to _always_ require users to put in the
necessary scope levels, i.e. don't have lilypond put the \book block in by default. It
would make it a bit harder to get started, but would make it much easier to move from the
"beginning user" stage to doing complicated scores.
>
Honestly, how many of you have ever used several \book blocks in the
same file (which is the only reason ever to to use an explicit \book block)?
Therefore, I don't think it's a good idea to make the \book compulsory.
On the other hand, I have argued a number of times that we should make
\score{...} compulsory. Primarily for the benefit of beginners, since it
makes it much more clear what lines in a file that really result in any
output and which are just macro definitions. I have seen many question
on the mailing list that are related to the fact that people don't realize
what becomes a \score and what doesn't.
Also, for more experienced users it give a natural starting point when you
look at a .ly file that you wrote yourself some year ago or that
somebody else
has written, just like I always start by looking or the main() function
when
looking at a C or C++ program.
Then, again, I don't think it would be a good idea to force people to
enter all scope levels. Then even the simplest example file would look like
\score{
\new Staff {
\new Voice {
c'1
}
}
}
I'm still mulling over the detailed and helpful answers everyone's
been sending to the main thread, but while doing I'd like to chime in
on this sidepoint, too.
Just in the last couple of months I've had the opportunity to teach
LilyPond to university composers in both California and Texas. The
experience has been extremely insightful, of course, because I've been
forced to answer questions that I'd forgotten having when I started
out. It's also been helpful because the audience for those couple of
classes have been *extremely* insightful adults -- all of them with
the knowledge and perspectives of professional composers and very many
of them with a substantial programming background as well.
And the conclusion from the teaching of Lily that I've done so far is
that *BY FAR AND AWAY* the greatest points of confusion all concern
file structure.
I can't prove that this confusion results from the implicit-ness of so
many of our examples in the docs on the list, etc, but I strongly
suspect this is the case.
A perfect case in point are some of the examples in the docs I've had
to check while writing the main part of this thread about the scoping
and meaning differences between \paper and \layout. Consider just the
very first words of chapter 11, which concern the rather concrete
concept of physical dimensions of paper:
"To change the paper size, there are two commands,
#(set-default-paper-size "a4")
\paper {
#(set-paper-size "a4")
}
The first command sets the size of all pages. The second command sets
the size of the pages that the \paper block applies to – if the \paper
block is at the top of the file, then it will apply to all pages. If
the \paper block is inside a \book, then the paper size will only
apply to that book."
This is actually extraordinarily difficult to cope with when you first
start using the program. Why? Because you don't know where these two
different commands *are supposed to physically sit in the input file*.
What is this book block the explanation referes to (but which doesn't
appear in the example and which nobody seems to use)? And what is this
top level? Is the example I'm looking at here at top level? It
certainly looks that way, but how can I be sure?
(I know that the text is perfectly clear once you're an experienced
user; but put yourself in the shoes of a new user and it really is
difficult to visualize the implicit scoping levels that the docs
everywhere refer to and the examples everywhere omit.)
So what to do?
Forcing all input files to be "fullly qualified" will probably lead to
a religious war (although, if it matters, I'll go on record as being
in favor of such a move -- if you really need to abbreviate files all
the time you're probably able to whip up a 4-line shell script to do
so).
OTOH, fully qualifying at least the most important examples in the
docs -- especiallly where we're talking about settings that can and do
live in more than one scope or input construct -- seems to be an
obvious good step.
Even so, I think even with fully qualified examples we still need some
language that makes it easy to say things like "Set the command
#(set-paper-size "a4") inside either a book-level \paper block or a
top-level \paper block. Set the command command
#(set-default-paper-size "a4") at top level outside of any input block
whatsoever." I think sentences lke that probably blow right over the
heads of most readers both because there's no mental picture of what a
"book-level \paper block" is and bec
Re: Reorganizing the contents of the \paper block
Would it be possible to implement something like Perl's use strict pragma? That would let people who need to do something quick-and-easy do so, while encouraging more formal structure in general. Geoff ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Carl D. Sorensen wrote:
On a related note, I think it would be cleaner to _always_ require users to put in the
necessary scope levels, i.e. don't have lilypond put the \book block in by default. It
would make it a bit harder to get started, but would make it much easier to move from the
"beginning user" stage to doing complicated scores.
Honestly, how many of you have ever used several \book blocks in the
same file (which is the only reason ever to to use an explicit \book block)?
Therefore, I don't think it's a good idea to make the \book compulsory.
On the other hand, I have argued a number of times that we should make
\score{...} compulsory. Primarily for the benefit of beginners, since it
makes it much more clear what lines in a file that really result in any
output and which are just macro definitions. I have seen many question
on the mailing list that are related to the fact that people don't realize
what becomes a \score and what doesn't.
Also, for more experienced users it give a natural starting point when you
look at a .ly file that you wrote yourself some year ago or that
somebody else
has written, just like I always start by looking or the main() function
when
looking at a C or C++ program.
Then, again, I don't think it would be a good idea to force people to
enter all scope levels. Then even the simplest example file would look like
\score{
\new Staff {
\new Voice {
c'1
}
}
}
/Mats
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Reorganizing the contents of the \paper block
> -Original Message-
> From: Han-Wen Nienhuys [mailto:[EMAIL PROTECTED]
> > If I comment out the score-level indent, then the book-level indent
> > will take over. If I comment out both the score-level and
> book-level
> > indents, then the top-level indent will take over.
>
> No, the \book level indent overwrites the toplevel
>
> \paper { indent = #75 }
> \book {
>\paper { indent = #50 }
> }
>
> really maens
>
> "$defaultpaperblock" = \paper { \$defaultpaperblock indent = #75 }
> \book {
> \paper { \$defaultpaperblock indent = #50 }
> }
>
>
Does this mean that \paper settings are always at top level? If so, then a
change to combine \paper and \layout into \settings, with scope defined by
where the \settings block occurs, would constitute a change in functionality.
However, that change in functionality would be cleaner and more consistent.
The scope would be what the syntax of the input file implied.
On a related note, I think it would be cleaner to _always_ require users to put
in the necessary scope levels, i.e. don't have lilypond put the \book block in
by default. It would make it a bit harder to get started, but would make it
much easier to move from the "beginning user" stage to doing complicated scores.
Carl Sorensen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Mats Bengtsson escreveu: > > When it comes to syntax, I just want to remind everybody that we used to > have > a single directive \paper corresponding to the current \layout and > \book, until > version 2.4, but it was split into the two in an attempt to clarify what > you could > do where. See > http://lilypond.org/doc/v2.4/Documentation/topdocs/out-www/NEWS.html This was not because of clarification, rather to have a place to put page settings in. 2.4 also was the 1st release to have page breaking. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu: > Note that this is not a zero-code proposal, however: the idea of > collapsing \paper and \layout is a pretty serious structural change, > even though I think it makes extremely good sense. It's actually not. Inside the code it's already implemented like that. The difference between paper and layout is that paper has a is-paper = ##t setting. What you're really losing is the ability to set a default for the \layout block. > Perhaps if we wind up wanting to collapse \layout and \paper, then we > can simply rip \context blocks out and leave them as free-standing > elements within a \score. But this is a sidenote until we consider > whether collapsing \paper and \layout even makes sense.] No, I think that in this case, the \context definitions have to go into \settings as well, ie. in the \book wide settings. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu:
> On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>> Trevor Bača escreveu:
>>
>> > Right now both list 1 and list 2 will just be put together into the
>> > outside-of-score (\paper) bucket.
>> >
>> > But it seems that may list 1 is really concerned with the *the layout
>> > of music on the page* whereas list 2 is concerned with *adding headers
>> > and footers outside the music*.
>> >
>> > So does it make sense to divide list 1 and list 2? And if so, with what
>> > names?
>>
>> I think this doesn't make sense. There are two output-def objects with
>> nested
>> scope. Variables that by their nature have \book-wide effect, go into
>> the outer
>> scope, variables that are score-wide may be put in the inner scope.
>>
>> If that confuses you, it might be a better idea to rename \layout and
>> \paper to
>> better reflect this.
>
> Another point of clarification:
>
> So this means there are really three levels of scope at which these
> settings can be made ...
>
> 1. at score level (which is most specific)
> 2. at book level (which is intermediate), and
> 3. at top level
>
> ... as reflected in the following example:
>
> %%% BEGIN 3-LEVELS OF SCOPE %%%
>
> \version "2.11.16"
>
> \paper { indent = #100 }
>
> \book {
>
> \paper { indent = #50 }
>
> \score {
> \new Staff { c'1 }
> \layout { indent = #0 }
> }
>
> }
>
> %%% END %%%
>
> If I comment out the score-level indent, then the book-level indent
> will take over. If I comment out both the score-level and book-level
> indents, then the top-level indent will take over.
No, the \book level indent overwrites the toplevel
\paper { indent = #75 }
\book {
\paper { indent = #50 }
}
really maens
"$defaultpaperblock" = \paper { \$defaultpaperblock indent = #75 }
\book {
\paper { \$defaultpaperblock indent = #50 }
}
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu: > (If I'm getting something factually incorrect, somebody please correct me.) No, this is correct, albeit a bit more wordy than how I would phrase it. :-) -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača wrote:
But what about the (semantic) grouping that I started this thread
with? Doesn't it still make sense to group, for example, these ...
ragged-bottom
ragged-last-bottom
system-count
between-system-space
between-system-padding
horizontal-shift
... settings together somehow? I mean, these things actually do
pertain to each other at a logical level, right?
Yes, definitely. But maybe this logical, user-centric division can be
handled perfectly cleanly just in the docs? The docs for settings can
then look something like this (and this is obviously just a sketch,
some pseudocode for the actual docs that I'll clean up long before
sending to Graham):
Leaving the question of syntax for the moment, one crucial limitation in
LilyPond
today (unless this changed over the last couple of months) is that you
cannot
specify settings like ragged-bottom or ragged-last-bottom individually
per score.
Of course, such a possibility doesn't make sense if you have several
short scores
on the same page, but if you have inserted a page break in between each
score,
it certainly makes lots of sense. Hmm, maybe it's better to think of it
the same way
as the \enlargethispage command in LaTeX, which you can specify anywhere in
the input file and which applies to the current page in the generated
output (if you
have several of these commands in the input that corresponds to one and
the same
page, then the last one of them overrides the others).
I find it a severe limitation that the current \paper{...} related
settings only can
be specified per \book.
When it comes to syntax, I just want to remind everybody that we used to
have
a single directive \paper corresponding to the current \layout and
\book, until
version 2.4, but it was split into the two in an attempt to clarify what
you could
do where. See
http://lilypond.org/doc/v2.4/Documentation/topdocs/out-www/NEWS.html
/Mats
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača wrote: \layout has another function, although it may be a special case of one of its other uses. If a \score block contains a \midi block the \layout block is needed if PDF output is also desired. Ah right. I remember that coming up a while back. OK, duly noted. If there's support for the layout + paper -> settings proposal, then we'll have to find a way to tell lily to produce a PDF even when there's no \settings block. Sounds like a good candidate for a commandline switch. Only as long as you can specify it also for each \score block within the file in a simple manner. Remember that one main reason to have a score block where you don't want printed output is if you make separate score blocks for MIDI and for printed output in the same file, for example to expand repeats and so on. /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Cameron Horsburgh <[EMAIL PROTECTED]> wrote:
> [Sidenote: if this proposal to collapse \paper and \alyout does make
> sense, then we'll have to decide what to do with the fact that there's
> a second, equally important use for \layout blocks, which is the
> overriding of context attributes ... which is a wholly separate thing
> from making the different settings talked about in this thread, as
> described in 9.2.6. This sort of thing:
>
> \layout {
> ...
> \context {
>\Staff
>
>\set fontSize = #-2
>\override Stem #'thickness = #4.0
>\remove "Time_signature_engraver"
> }
> }
>
\layout has another function, although it may be a special case of one
of its other uses. If a \score block contains a \midi block the
\layout block is needed if PDF output is also desired.
Ah right. I remember that coming up a while back.
OK, duly noted. If there's support for the layout + paper -> settings
proposal, then we'll have to find a way to tell lily to produce a PDF
even when there's no \settings block. Sounds like a good candidate for
a commandline switch.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
> [Sidenote: if this proposal to collapse \paper and \alyout does make
> sense, then we'll have to decide what to do with the fact that there's
> a second, equally important use for \layout blocks, which is the
> overriding of context attributes ... which is a wholly separate thing
> from making the different settings talked about in this thread, as
> described in 9.2.6. This sort of thing:
>
> \layout {
> ...
> \context {
>\Staff
>
>\set fontSize = #-2
>\override Stem #'thickness = #4.0
>\remove "Time_signature_engraver"
> }
> }
>
\layout has another function, although it may be a special case of one
of its other uses. If a \score block contains a \midi block the
\layout block is needed if PDF output is also desired.
--
=
Cameron Horsburgh
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Bryan Stanbridge <[EMAIL PROTECTED]> wrote: David Rogers wrote: > The correct answer is (I believe) exactly as you proposed earlier. Talking about Lilypond's internal logic is IMHO counterproductive. In fact, internally, I suspect Lilypond should stay the same - it just needs to allow the user to use it effectively by making (or even just *allowing*) the logical separation between paper, headers, and music, which you already outlined. It would be great if we could also leave the current mechanism in place if we do such a change. The system made sense to me from the beginning and I'd prefer to think in terms of scope (I have a strong programming background). I don't oppose a division on its merits, but it would be nice if the format would stay the same. Right. The scoping mechanism is actually fantastic. So what do you think about the collapsing of \paper and \layout into \settings which is then a *pure* representation of the scope at which the variable sets? [Side question: had you realized that there were actually *three* levels of scope (at least in input files) rather than two? I certainly didn't. But I never use \book explicitly ...] -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Juergen Reuter <[EMAIL PROTECTED]> wrote: Hi, all! What about unifying "\paper" and "\layout" into a single "\layout" directive, such that in the input language there is no syntactical difference any more between \paper and \layout block? (Of course, in the implementation, the different scopes still could be kept.) Then the place where the \layout occurs in the .ly file determines which properties can be changed (that is exactly what scopes are about). Obviously, if someone operates in the wrong scope, i.e. if someone tries to change things on score level \layout block which only should be changed globally (such as paper margin), lily should emit a warning. Wow. We may actually be moving towards consensus on this. See previous mail from just a second ago with the proposal to call this simply a generic \settings block ... -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, David Rogers <[EMAIL PROTECTED]> wrote:
On Wed, 7 Feb 2007 16:45:26 -0600, Trevor Bača wrote:
> And now I see why Han-Wen keeps inviting a name change of the \paper
> and \layout buckets (while implicitly discouraging the moving around
> of settings between those two buckets): the buckets show the *scope*
> of the different settings, which isn't really an attribute that can be
> easily changed.
>
> OK. I get it. Now I see why the task is a renaming task rather than a
> moving-around task.
>
> Hm ... more thinking ...
The way this is typed in an input file has to make sense to the user. The user
should not be required to think like a computer. It has taken you, an obvious
expert, months and months to get his head around this. I never got it at all
until you explained it.
The correct answer is (I believe) exactly as you proposed earlier. Talking
about Lilypond's internal logic is IMHO counterproductive. In fact, internally,
I suspect Lilypond should stay the same - it just needs to allow the user to
use it effectively by making (or even just *allowing*) the logical separation
between paper, headers, and music, which you already outlined.
Hi David, hi list,
I'm *definitely* in favor of clarifying the daylights out of what's
going on here with the different settings. They're *so* powerful but
very much in need of doc clarification.
However, I really do think we can have our cake (clear delineation of
functionality in a user-centric way that fits the problem domain of
engraving score) and eat it too (preserve the CSS-style overrides of
settings that Han-Wen has been explaining).
(BTW, the reason I've been cluttering up everyone's inbox here with so
much of this is that I've given myself the task of rewriting both the
vertical spacing docs in chapter 11 and also the proportional spacing
stuff, too. And, as it turns out, those things both hinge crucially on
two concepts -- the settings that started this thread, and also line-
and page-breaking. So this is all part of peeling back the onion to
hopefully get a good an even more accurate set of docs for vertical
and horizontal spacing.)
So how to have our cake and eat it too?
What if we start (and hear me out here because I know it sounds weird)
with abolishing the distinction between \paper and \layout altogether.
Just forget they ever existed. And let's instead create a generic
\settings block where we can make any of the 30 or 40 settings that
currently live today in either \paper or \layout. Oh, and we'll allow
ourselves to instantiate a \settings block at any of the three lexical
levels of scope allowed for in an .ly file -- at score-level, at
book-level, and at top-level:
%%% BEGIN GENERIC SETTINGS BLOCK %%%
\settings { } % these are top-level settings
\book {
\settings { } % these are book-level settings
\score {
\new Staff { c'4 }
\settings { } % these are score-level settings
}
}
%%% END %%%
Now with this structure it's at least 100% clear how the three
different possible \settings blocks all interact with each other:
1. lily first checks for a value at score-level; if found, use that
value, otherwise ...
2. check for the value at book-level; if found, use that value, otherwise ...
3. check for the value at top-level; if found, use that value,
otherwise use the system default value.
Pefectly clean, perfectly clear. And the term \settings doesn't
confuse anyone by making us wonder how it is that the different
settings can relate to each other. They're just settings. Big bags of
settings. Some deal with padding between systems, some deal with the
text used to render the composer's name.
But what about the (semantic) grouping that I started this thread
with? Doesn't it still make sense to group, for example, these ...
ragged-bottom
ragged-last-bottom
system-count
between-system-space
between-system-padding
horizontal-shift
... settings together somehow? I mean, these things actually do
pertain to each other at a logical level, right?
Yes, definitely. But maybe this logical, user-centric division can be
handled perfectly cleanly just in the docs? The docs for settings can
then look something like this (and this is obviously just a sketch,
some pseudocode for the actual docs that I'll clean up long before
sending to Graham):
"LilyPond supports 47 different different page layout and setup
settings. These settings divide into 5 different functional areas.
These five functional areas are:
* page dimensions
* page margins
* headers and footers
* the layout of systems
* the location of line- and page-breaks
In addition, LilyPond input files support three different places where
these different settings can be made. These three levels where
settings can be made are:
* score level
* book level
* top level
Some settings can be made only at score level and book level. Other
settings can be made at all three levels. In the detailed descriptions
that follow, we note whether a setting can be set at 2 or
Re: Reorganizing the contents of the \paper block
David Rogers wrote: The correct answer is (I believe) exactly as you proposed earlier. Talking about Lilypond's internal logic is IMHO counterproductive. In fact, internally, I suspect Lilypond should stay the same - it just needs to allow the user to use it effectively by making (or even just *allowing*) the logical separation between paper, headers, and music, which you already outlined. It would be great if we could also leave the current mechanism in place if we do such a change. The system made sense to me from the beginning and I'd prefer to think in terms of scope (I have a strong programming background). I don't oppose a division on its merits, but it would be nice if the format would stay the same. Cheers, Bryan... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Hi, all! What about unifying "\paper" and "\layout" into a single "\layout" directive, such that in the input language there is no syntactical difference any more between \paper and \layout block? (Of course, in the implementation, the different scopes still could be kept.) Then the place where the \layout occurs in the .ly file determines which properties can be changed (that is exactly what scopes are about). Obviously, if someone operates in the wrong scope, i.e. if someone tries to change things on score level \layout block which only should be changed globally (such as paper margin), lily should emit a warning. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Trevor Bača escreveu:
> Right now both list 1 and list 2 will just be put together into the
> outside-of-score (\paper) bucket.
>
> But it seems that may list 1 is really concerned with the *the layout
> of music on the page* whereas list 2 is concerned with *adding headers
> and footers outside the music*.
>
> So does it make sense to divide list 1 and list 2? And if so, with what
> names?
I think this doesn't make sense. There are two output-def objects with nested
scope. Variables that by their nature have \book-wide effect, go into the outer
scope, variables that are score-wide may be put in the inner scope.
If that confuses you, it might be a better idea to rename \layout and \paper to
better reflect this.
Another point of clarification:
So this means there are really three levels of scope at which these
settings can be made ...
1. at score level (which is most specific)
2. at book level (which is intermediate), and
3. at top level
... as reflected in the following example:
%%% BEGIN 3-LEVELS OF SCOPE %%%
\version "2.11.16"
\paper { indent = #100 }
\book {
\paper { indent = #50 }
\score {
\new Staff { c'1 }
\layout { indent = #0 }
}
}
%%% END %%%
If I comment out the score-level indent, then the book-level indent
will take over. If I comment out both the score-level and book-level
indents, then the top-level indent will take over.
Of course we're almost completely unaware of this most of the time
since probably no one ever explicitly instantiates \books.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Reorganizing the contents of the \paper block
My suggestion:
\paper {}
paper-width
paper-height
top-margin
bottom-margin
left-margin
\page-layout{}
first-page-number
print-first-page-number
print-page-number
auto-first-page-number
head-separation
foot-separation
printallheaders
after-title-space
before-title-space
between-title-space
blank-page-force
blank-last-page-force
\music-layout{} or \system-layout{}
indent
line-width
ragged-bottom
ragged-last-bottom
system-count
between-system-space
between-system-padding
horizontal-shift
page-spacing-weight
ragged-right
ragged-last
systemSeparatorMarkup (should be changed to system-separator-markup?)
Carl Sorensen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Trevor Bača escreveu: > Right now both list 1 and list 2 will just be put together into the > outside-of-score (\paper) bucket. > > But it seems that may list 1 is really concerned with the *the layout > of music on the page* whereas list 2 is concerned with *adding headers > and footers outside the music*. > > So does it make sense to divide list 1 and list 2? And if so, with what > names? I think this doesn't make sense. There are two output-def objects with nested scope. Variables that by their nature have \book-wide effect, go into the outer scope, variables that are score-wide may be put in the inner scope. If that confuses you, it might be a better idea to rename \layout and \paper to better reflect this. OK. I think I finally see what's going on and what's been confusing me for months. Let me see if I can get it into words: What's really going in the current implementation is that there are a whole bunch of different settings. The settings have names like ragged-right, indent, left-margin, between-system-space, and so on. There are probably 30 or 40 or more of these settings. And all 30 or 40 settings divide into one of two classes: CLASS I. Class I settings -- by their very nature -- have only \book-wide effect and can NEVER have score-local effect. An example of a \book-wide-only setting are top-margin and bottom-margin. These are settings that affect *ENTIRE PAGE AT A TIME* and can not under any circumstances change midpage. Page margins of course can not change in the middle of a page. So page margins make excellent examples of Class I settings. CLASS II. Class II settings -- again, by their very nature -- are more flexible and may be set either at the \book-level, or at the more specific score-level, or at both. An example of this second class of setting is ragged-right. It is entirely possible to have two scores on a single page (or "in a single \book") such that score 1 is ragged-right and score 2 is not ragged right. I think these two classes perfectly map to what Han-Wen keeps patiently describing: two different levels of scope in which settings can be made. (Han-Wen, if this isn't right, please correct.) Now with this division between Class I and Class II settings it's possible to clearly explain where the confusion arises. (And, in so doing, to explain why Han-Wen keeps inviting a rename of \paper and \layout rather than a moving around of settings from one bucket to the other.) Basically, the real division of settings is into class I and class II. And -- as an accident of naming history -- the bucket into which class I settings fit happens to have been named "\paper". Likewise, the bucket into which class II settings fit happens to have been named "\layout". (And, in fact, the history of convert-ly points to the fact that these two buckets used to be named differently, in fact.) The buckets could just have easily been called "red" and "blue". And this explains the confusion: I'm sitting here looking at the 27 different settings that 11.1.2 puts into the \paper (class I) bucket and thinking "My God, how on earth do these things relate to each other? Some are page setup settings like margins while others have nothing at all to do with page set up and concern how systems of music lay out across the page, like between-system-padding. How did these different settings all wind up in the same category?" And now the answer is clear: the 27 settings that 11.1.2 puts into the \paper (class I) bucket are all there not because they relate to each other semantically (ie, not because they all share a similar purpose) but instead because all share the same SCOPE -- you can stick any setting you want in \paper provided that the setting can have \book-level scope. OTOH, \layout is a more "selective" place to stick your settings: you can only stick settings into \layout that can have a more localized score-level scope. And now I see why Han-Wen keeps inviting a name change of the \paper and \layout buckets (while implicitly discouraging the moving around of settings between those two buckets): the buckets show the *scope* of the different settings, which isn't really an attribute that can be easily changed. OK. I get it. Now I see why the task is a renaming task rather than a moving-around task. Hm ... more thinking ... (If I'm getting something factually incorrect, somebody please correct me.) -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
David Rogers wrote: I propose: \papersize (for only the actual paper-related items) \systemlayout (for Trevor's list 1) \headerlayout (for Trevor's list 2) I second this proposal, although they should probably be \paperSize \systemLayout \headerLayout or \paper-size \system-layout \header-layout Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu:
> I'm used to thinking of ragged-right as a "layout setting". But,
> apparently, ragged-right can go in either the (top-level) \paper or
> (top-level) \layout block equally. Why is this allowed? Is there some
> benefit?
As I said, the scoping is nested at runtime: if a lookup in \layout of a
\score fails, it is looked up in the \paper{} of the enclosing \book block.
(in a lot of cases, the \book block is implicit, and supplied by lilypond)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu: > Question for anyone who can answer: are there *any* settings that > *can* go in a score-level \layout block but *can not* go in the > top-level \paper block? No, not that I know. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu: > Right now both list 1 and list 2 will just be put together into the > outside-of-score (\paper) bucket. > > But it seems that may list 1 is really concerned with the *the layout > of music on the page* whereas list 2 is concerned with *adding headers > and footers outside the music*. > > So does it make sense to divide list 1 and list 2? And if so, with what > names? I think this doesn't make sense. There are two output-def objects with nested scope. Variables that by their nature have \book-wide effect, go into the outer scope, variables that are score-wide may be put in the inner scope. If that confuses you, it might be a better idea to rename \layout and \paper to better reflect this. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Trevor Bača <[EMAIL PROTECTED]> wrote:
Question for anyone who can answer: are there *any* settings that
*can* go in a score-level \layout block but *can not* go in the
top-level \paper block?
Second question: why do the top-level
\layout { ragged-right = ##t }
and
\paper { ragged-right = ##t }
have exactly the same effect on the output in the following file?
%%% BEGIN %%%
\version "2.11.16"
% these have exactly the same effect, no matter which one is commented out
%\layout { ragged-right = ##t }
\paper { ragged-right = ##t }
\score {
\new Staff {
c'1 \break c'1
}
}
\score {
\new Staff {
d'1 \break d'1
}
\layout { ragged-right = ##f }
}
%%% END %%%
I'm used to thinking of ragged-right as a "layout setting". But,
apparently, ragged-right can go in either the (top-level) \paper or
(top-level) \layout block equally. Why is this allowed? Is there some
benefit?
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Trevor Bača <[EMAIL PROTECTED]> wrote:
On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> Trevor Bača escreveu:
> > On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> >> Trevor Bača escreveu:
> >>
> >> >
> >> > I wouldn't ask except for the fact that I've now been laying out score
> >> > very successfully with lily for going on two years and I still have to
> >> > stop and ask myself "Hmm ... I'm wanting to pad systems on the page so
> >> > that they lay out more loosely. So that concerns layout and I'll look
> >> > for settings over here in the \layout block. Oh wait. Settings for
> >> > system layout live in the \paper block ..."
> >>
> >> the \layout block only affects what's in a score. Page layout (margins,
> >> titles, etc) fall outside that and therefore are in the \paper block.
> >> Perhaps better names can be found for paper/layout; suggestions
> >> appreciated.
> >
> > Hmmm.
> >
> > Just thinking out loud here ... so there's an inside-of-score /
> > outside-of-score dichotomy going on here. I don't think I had ever
> > realized that ...
> >
> > So that means that ragged-right (which currently lives in \layout) is
> > perceived as inside-of-score, whereas ragged-bottom (which currently
> > lives in \paper) is outside-of-score?
>
> yes. However, \layout settings default to what is in the \paper block,
> so ragged-right may also be defined in the \paper{} block.
OK.
Hm. So ragged-right can live in the *\layout* block (and have
score-level scope). Or ragged-right can live in the *\paper* block
(and have file-level scope).
Would it make more sense to have the idea that ragged-right only ever
live in a \layout block, together with the companion idea that there
can be both score-level \layout blocks and also one file-level \layout
block?
Question for anyone who can answer: are there *any* settings that
*can* go in a score-level \layout block but *can not* go in the
top-level \paper block?
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Kress, Stephen <[EMAIL PROTECTED]> wrote:
I think Han-Wen said it himself (though he didn't realize it).
I like the idea if \paper being as you described (with just the six
properties).
Me too. I think that greatly clears up what belongs in the \paper
block -- just stuff that has to do with the physical dimensions and
printable area of actual paper.
Put all the other stuff (the outside-the-score layout stuff) in a new block
called \page-layout
Maybe, if folks get too confused between \page-layout and \layout, the
\layout block can be moved inside the \score block since that's what it
applies to the most. It might also be that a \layout block that is outside
a \score block (for the purposes of a "global" style) could be renamed to
\score-layout.
So what do think about dividing the outside-of-score stuff into two
categories? Because it seems like maybe these two lists of settings do
different things:
list 1:
ragged-bottom
ragged-last-bottom
system-count
between-system-space
between-system-padding
horizontal-shift
blank-page-force
blank-last-page-force
page-spacing-weight
list 2:
first-page-number
print-first-page-number
print-page-number
auto-first-page-number
head-separation
foot-separation
print-all-headers (iso printallheaders)
after-title-space
before-title-space
between-title-space
Right now both list 1 and list 2 will just be put together into the
outside-of-score (\paper) bucket.
But it seems that may list 1 is really concerned with the *the layout
of music on the page* whereas list 2 is concerned with *adding headers
and footers outside the music*.
So does it make sense to divide list 1 and list 2? And if so, with what names?
Just some q&d thoughts...
Stephen
-Original Message-
From:
[EMAIL PROTECTED]
on behalf of Trevor Baca
Sent: Wed 2/7/2007 12:47 PM
To: Han-Wen Nienhuys
Cc: lilypond-devel; lilypond-user
Subject: Re: Reorganizing the contents of the \paper block
On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> Trevor Baca escreveu:
> > On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> >> Trevor Baca escreveu:
> >>
> >> >
> >> > I wouldn't ask except for the fact that I've now been laying out
score
> >> > very successfully with lily for going on two years and I still have
to
> >> > stop and ask myself "Hmm ... I'm wanting to pad systems on the page
so
> >> > that they lay out more loosely. So that concerns layout and I'll
look
> >> > for settings over here in the \layout block. Oh wait. Settings for
> >> > system layout live in the \paper block ..."
> >>
> >> the \layout block only affects what's in a score. Page layout
(margins,
> >> titles, etc) fall outside that and therefore are in the \paper block.
> >> Perhaps better names can be found for paper/layout; suggestions
> >> appreciated.
> >
> > Hmmm.
> >
> > Just thinking out loud here ... so there's an inside-of-score /
> > outside-of-score dichotomy going on here. I don't think I had ever
> > realized that ...
> >
> > So that means that ragged-right (which currently lives in \layout) is
> > perceived as inside-of-score, whereas ragged-bottom (which currently
> > lives in \paper) is outside-of-score?
>
> yes. However, \layout settings default to what is in the \paper block,
> so ragged-right may also be defined in the \paper{} block.
OK.
Hm. So ragged-right can live in the *\layout* block (and have
score-level scope). Or ragged-right can live in the *\paper* block
(and have file-level scope).
Would it make more sense to have the idea that ragged-right only ever
live in a \layout block, together with the companion idea that there
can be both score-level \layout blocks and also one file-level \layout
block?
--
Trevor Baca
[EMAIL PROTECTED]
2007-02-07, 13:02:32
The information contained in this e-mail message and any attachments may be
privileged and confidential. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that any review, dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
immediately by replying to this e-mail and delete the message and any
attachments from your computer.
2007-02-07, 13:33:40
The information contained in this e-mail message and any attachments may be
privileged and confidential. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified th
Re: Reorganizing the contents of the \paper block
On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Trevor Bača escreveu:
> On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>> Trevor Bača escreveu:
>>
>> >
>> > I wouldn't ask except for the fact that I've now been laying out score
>> > very successfully with lily for going on two years and I still have to
>> > stop and ask myself "Hmm ... I'm wanting to pad systems on the page so
>> > that they lay out more loosely. So that concerns layout and I'll look
>> > for settings over here in the \layout block. Oh wait. Settings for
>> > system layout live in the \paper block ..."
>>
>> the \layout block only affects what's in a score. Page layout (margins,
>> titles, etc) fall outside that and therefore are in the \paper block.
>> Perhaps better names can be found for paper/layout; suggestions
>> appreciated.
>
> Hmmm.
>
> Just thinking out loud here ... so there's an inside-of-score /
> outside-of-score dichotomy going on here. I don't think I had ever
> realized that ...
>
> So that means that ragged-right (which currently lives in \layout) is
> perceived as inside-of-score, whereas ragged-bottom (which currently
> lives in \paper) is outside-of-score?
yes. However, \layout settings default to what is in the \paper block,
so ragged-right may also be defined in the \paper{} block.
OK.
Hm. So ragged-right can live in the *\layout* block (and have
score-level scope). Or ragged-right can live in the *\paper* block
(and have file-level scope).
Would it make more sense to have the idea that ragged-right only ever
live in a \layout block, together with the companion idea that there
can be both score-level \layout blocks and also one file-level \layout
block?
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu:
> On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>> Trevor Bača escreveu:
>>
>> >
>> > I wouldn't ask except for the fact that I've now been laying out score
>> > very successfully with lily for going on two years and I still have to
>> > stop and ask myself "Hmm ... I'm wanting to pad systems on the page so
>> > that they lay out more loosely. So that concerns layout and I'll look
>> > for settings over here in the \layout block. Oh wait. Settings for
>> > system layout live in the \paper block ..."
>>
>> the \layout block only affects what's in a score. Page layout (margins,
>> titles, etc) fall outside that and therefore are in the \paper block.
>> Perhaps better names can be found for paper/layout; suggestions
>> appreciated.
>
> Hmmm.
>
> Just thinking out loud here ... so there's an inside-of-score /
> outside-of-score dichotomy going on here. I don't think I had ever
> realized that ...
>
> So that means that ragged-right (which currently lives in \layout) is
> perceived as inside-of-score, whereas ragged-bottom (which currently
> lives in \paper) is outside-of-score?
yes. However, \layout settings default to what is in the \paper block,
so ragged-right may also be defined in the \paper{} block.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
On 2/7/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Trevor Bača escreveu: > > I wouldn't ask except for the fact that I've now been laying out score > very successfully with lily for going on two years and I still have to > stop and ask myself "Hmm ... I'm wanting to pad systems on the page so > that they lay out more loosely. So that concerns layout and I'll look > for settings over here in the \layout block. Oh wait. Settings for > system layout live in the \paper block ..." the \layout block only affects what's in a score. Page layout (margins, titles, etc) fall outside that and therefore are in the \paper block. Perhaps better names can be found for paper/layout; suggestions appreciated. Hmmm. Just thinking out loud here ... so there's an inside-of-score / outside-of-score dichotomy going on here. I don't think I had ever realized that ... So that means that ragged-right (which currently lives in \layout) is perceived as inside-of-score, whereas ragged-bottom (which currently lives in \paper) is outside-of-score? -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reorganizing the contents of the \paper block
Trevor Bača escreveu: > > I wouldn't ask except for the fact that I've now been laying out score > very successfully with lily for going on two years and I still have to > stop and ask myself "Hmm ... I'm wanting to pad systems on the page so > that they lay out more loosely. So that concerns layout and I'll look > for settings over here in the \layout block. Oh wait. Settings for > system layout live in the \paper block ..." the \layout block only affects what's in a score. Page layout (margins, titles, etc) fall outside that and therefore are in the \paper block. Perhaps better names can be found for paper/layout; suggestions appreciated. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
