lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: review new info on file layout


From: Mats Bengtsson
Subject: Re: review new info on file layout
Date: Sat, 04 Feb 2006 10:59:47 +0100
User-agent: Internet Messaging Program (IMP) H3 (4.0.4)

Quoting Erik Sandberg <address@hidden>:

On Friday 03 February 2006 21.12, Mats Bengtsson wrote:
Quoting Erik Sandberg <address@hidden>:
I would say the opposite, since in all other situations \new is used like
\new Lyrics {...} or \new Lyrics \with {...} {...}. If you insert
\lyricsto inbetween, people might get the the impression that
\lyricsto is part of the \new Lyrics construct. If you want to exaggerate
the pedagogics, I would even propose to say
\lyricsto mytune { \new Lyrics {...} }
to make it really clear what \lyricsto does (I hope it's legal syntax,
haven't checked).

Then I'd propose this instead:
\new Lyrics { \lyricsto mytune { ... } }
because it feels relevant to me to consequently create contexts as top-level
as possible. (hm.. the outer {} in my example are still confusing though,
since lyricsto never can be part of anything sequential)

The intuitive idea behind my proposal is that the second argument
of the \lyricsto construct is the Lyrics context, whereas with your
proposal it's only the lyrics expression. Of course, there might be
situations where you have several \lyricsto within the same Lyrics
context, so then your proposal makes more sense. However, in such
situations, I would normally use something like:
\lyricsto partI \context Lyrics = lyr {...}
\lyricsto partII \context Lyrics = lyr {...}
\lyricsto partIII \context Lyrics = lyr {...}

> I think lily does create separate staves for the voices in this case,
> but it's
> not at all clear, and adding \new Staff statements explicitly makes the
> semantics clearer.

We have lots of optional constructs in the syntax, { c } is actually a
short-cut for
\book{\score{\new Staff{\new Voice{ c }}}}
(maybe I missed something).
yes, you can add a \new Score inbetween also, and empty layout and header
blocks.
I think this is one major source of confusion
but of course it's also convenient. My personal view is that we should
make at least some of these parts compulsory again (especially \score),
since it really only saves a significant portion of key-strokes when
you write an example file with one or two bars, but not really for any
real music.

I think the shorthand without score is highly relevant:
- Lots of music is just short snippets. See e.g. regression tests, LSR and bug archive.

That's only true for the small group of people like you and me who
spend more time answering mailing list questions and handling bug
reports than on typesetting any real music. It's clearly a suboptimization
to adapt the syntax too much to such unnormal use of the program.

- Suppose that Wikipedia begins to use lily. They will probably support
constructs such as <music> {c d e f } </music> regardless of whether lily
forces \score. People who learn lily from wikipedia should be able to use the
syntax they learnt there directly.

I agree that we shouldn't force people to remember lots of extra syntax that the program itself can figure out. However, I've seen lots of confusion on the mailing list because \score
is now optional.

  /Mats





reply via email to

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