[Top][All Lists]

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

Re: An overview of the system

From: Han-Wen Nienhuys
Subject: Re: An overview of the system
Date: Mon, 12 Dec 2005 11:57:47 +0100
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)

Don Blaheta wrote:
When you type something that produces a bit of music, that musical thing
is normally placed immediately after the thing you typed previously, and

only for sequential music. Try

 \score { << a b c d e >> }

Any context can be created anonymously (\new) or named (\context). When you create a new context, it is contained by the innermost open
context that is able to contain it---e.g. if the Score, a Staff, and a
Voice are open, and you create a new Voice, that new voice will be
contained by the Staff, not the Voice.  This means that the textual
nesting (what you see when you look at pairs of {}, <<>>, <>) may *not*
reflect the logical nesting.  If you open a named context, and a context

Textual nesting as such doesn't really exist, internally. << >> and { } reflect time-wise relations between Music. Nothing more.

* Side note: when trying to figure out whether Lyric contexts were
actually contained by Staffs or became siblings, I typed the following:
  \score {<<
    \new Staff {
      %\set Staff.fontSize = #3
        \new Voice { c }
        \new Lyrics \lyricmode { x }
        \new Lyrics \lyricmode { y }
    \new Voice { f }
and when the \set is uncommented, suddenly the lyrics move below the
second staff line.  Why is that?  (It certainly answered my question,
though not quite the way I expected.)  It doesn't seem to matter what I
\set there.

The order in which contexts appear on paper is the order in which they are created. By putting \set in a sequence, you force everying following it ( the << >> ) to be done after "opening" the outermost \new Staff .

Just renamed, or is this a more fundamental change?  There are
presumably still leaf nodes....

it's an internal change. The C++ class Event has disappeared, but of course, there are still events. The definition of those has moved entirely to the Scheme side.

Maybe not "subclass" then, but I wanted to see the hierarchy; for
example I can find out that a BeamEvent can be a general-music, event,
beam-event, or span-event, but not that an Event is related to a
BeamEvent, at least, not from the page on Event.  Even if you rearrange
and rename the internals, I assume there will be some sort of hierarchy
in there....

They are related through their 'types property. See scm/define-music-types.scm for more information. Strictly speaking, there is no hierarchy.

Iterators and translators decide that. If you need to know more, you can either copy what others already did, or you can read the source code for hints (usually, only gurus tweak Music properties, and most gurus know how to read source code)

In general, i'd advice you to look directly in the .scm files (scm/* wherever lilypond's data files are), rather than the online docs. The .scm files sometimes contain additional hints.

So you're arguing against documenting the system?

No, against inferring who things work from the docs,  I guess.

 Han-Wen Nienhuys - address@hidden -

reply via email to

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