[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 - http://www.xs4all.nl/~hanwen