Guide, node Updating translation committishes..
@end ignore
-@c \version "2.17.30"
+@c \version "2.19.7"
@node Changing defaults
@chapter Changing defaults
@strong{@emph{RhythmicStaff}}
-Like @code{Staff} but for printing rhythms. Pitches are ignored;
-the notes are printed on one line.
+Like @code{Staff} but for printing rhythms. Pitches are ignored
+when engraving; the notes are printed on one line. The MIDI
+rendition retains pitches unchanged.
@strong{@emph{TabStaff}}
time signature.
@cindex polymetric scores
-@cindex Time signatures, multiple
+@cindex time signature, multiple
@lilypond[quote,verbatim]
\score {
@seealso
Internals Reference:
-@rinternals{Engraver_group},
@rinternals{Note_heads_engraver},
@rinternals{Text_engraver},
@rinternals{Rhythmic_column_engraver},
within it.
The @qq{accepts} list of a context can be changed with the
-@code{\accepts} and @code{\denies} commands. @code{\accepts} adds a
+@code{\accepts} or @code{\denies} commands. @code{\accepts} adds a
context to the @qq{accepts} list and @code{\denies} removes a context
-from the list. For example, it would not normally be desirable for
-chord names to be nested within a @code{Staff} context, so the
-@code{ChordNames} context is not included by default in the @qq{accepts}
-list of the @code{Staff} context, but if this were to be required it can
-be done:
+from the list.
+
+For example, a square-braced staff group is not usually found within a
+curved-braced staff with connecting staff bars, and a @code{GrandStaff}
+does not accept a @code{StaffGroup} inside it by default.
@lilypond[verbatim,quote]
\score {
- \new Staff {
- c' d' e' f'
- \chords { d1:m7 b1:min7.5- }
- }
+ \new GrandStaff <<
+ \new StaffGroup <<
+ \new Staff { c'1 }
+ \new Staff { d'1 }
+ >>
+ \new Staff { \set Staff.instrumentName = bottom f'1 }
+ >>
}
@end lilypond
+However, by using the @code{\accepts} command, @code{StaffGroup} can be
+added to the @code{GrandStaff} context:
+
@lilypond[verbatim,quote]
\score {
- \new Staff {
- c' d' e' f'
- \chords { d1:m7 b1:min7.5- }
- }
+ \new GrandStaff <<
+ \new StaffGroup <<
+ \new Staff { c'1 }
+ \new Staff { d'1 }
+ >>
+ \new Staff { \set Staff.instrumentName = bottom f'1 }
+ >>
\layout {
\context {
- \Staff
- \accepts "ChordNames"
+ \GrandStaff
+ \accepts "StaffGroup"
}
}
}
Contexts properties are usually named in
@code{studlyCaps}. They mostly control the translation from
-music to notation, e.g. @code{localKeySignature} (for determining
+music to notation, e.g. @code{localAlterations} (for determining
whether to print accidentals), or @code{measurePosition} (for
determining when to print a bar line). Context properties can
change value over time while interpreting a piece of music;
@node set versus override
@subsection @code{\set} vs. @code{\override}
-@c TODO -- This section is probably unnecessary now.
-
-@ignore
-We have seen two methods of changing properties: @code{\set} and
-@code{\override}. There are actually two different kinds of
-properties.
-
-@code{fontSize} is a special property: it is equivalent to
-entering @code{\override @dots{} #'font-size} for all pertinent
-objects. Since this is a common change, the special
-property (modified with @code{\set}) was created.
-
-@end ignore
+@c TODO Should't a bunch of that be explained earlier?
+@funindex \set
+@funindex \override
+Both @code{\set} and @code{\override} manipulate properties
+associated with contexts. In either case, properties heed the
+hierarchy of contexts: properties not set in a context itself show
+the values of the respective parent context.
+
+Values and lifetime of context properties are dynamic and only
+available when music is being interpreted, @q{iterated}. At the
+time of context creation, properties are initialized from the
+corresponding context definition and possible context
+modifications. Afterwards, changes are achieved with
+property-setting commands in the music itself.
+
+Now grob definitions are a special category of context properties.
+Since their structure, bookkeeping and use is different from
+ordinary context properties, they are accessed with a different
+set of commands, and treated separately in the documentation.
+
+As opposed to plain context properties, grob definitions are
+subdivided into grob properties. A @qq{grob} (graphical object)
+is usually created by an engraver at the time of interpreting a
+music expression and receives its initial properties from the
+current grob definition of the engraver's context. The engraver
+(or other @q{backend} parts of LilyPond) may subsequently add or
+change properties to the grob, but that does not affect the
+context's grob definition.
+
+What we call @q{grob properties} in the context of user-level
+tweaking are actually the properties of a context's grob
+definition. In contrast to ordinary context properties, grob
+definitions have the bookkeeping required to keep track of its
+parts, the individual grob properties (and even subproperties of
+them) separately so that it is possible to define those parts in
+different contexts and have the overall grob definition at the
+time of grob creation be assembled from pieces provided in
+different contexts among the current context and its parents.
+
+Grob definitions are manipulated using @code{\override} and
+@code{\revert} and have a name starting with a capital letter
+(like @samp{NoteHead}) whereas ordinary context properties are
+manipulated using @code{\set} and @code{\unset} and are named
+starting with a lowercase letter.
+
+@cindex tweak, relation to @code{\override}
+@funindex \tweak
+@funindex \overrideProperty
+The special commands @code{\tweak} and @code{\overrideProperty}
+change grob properties bypassing context properties completely.
+Instead they catch grobs as they are being created and then
+directly set properties on them when they originate from a tweaked
+music event or are of a particular kind, respectively.
@node Modifying alists
@subsection Modifying alists
key-values individually with a nested declaration.
@warning{Nested declarations will not work for context property
-alists (such as @code{beamExceptions}, @code{keySignature},
+alists (such as @code{beamExceptions}, @code{keyAlterations},
@code{timeSignatureSettings}, etc.). These properties can only be
modified by completely re-defining them as alists.}
* Input modes::
* Direction and placement::
* Distances and measurements::
+* Dimensions::
* Staff symbol properties::
* Spanners::
* Visibility of objects::
The way in which the notation contained within an input file is
interpreted is determined by the current input mode.
-@strong{Chord mode}
+@subsubsubheading Chord mode
This is activated with the @code{\chordmode} command, and causes
input to be interpreted with the syntax of chord notation, see
chord notation and rendered as chord names in the @code{ChordNames}
context, see @ref{Printing chord names}.
-@strong{Drum mode}
+@subsubsubheading Drum mode
This is activated with the @code{\drummode} command, and causes
input to be interpreted with the syntax of drum notation, see
Drum mode is also activated with the @code{\drums} command.
This also creates a new @code{DrumStaff} context and causes the
following input to be interpreted with the syntax of drum notation
-and rendered as drum symbols on a drum staff, see @ref{Basic
-percussion notation}.
+and rendered as drum symbols on a drum staff, see
+@ref{Basic percussion notation}.
-@strong{Figure mode}
+@subsubsubheading Figure mode
This is activated with the @code{\figuremode} command, and causes
input to be interpreted with the syntax of figured bass, see
and rendered as figured bass symbols in the @code{FiguredBass}
context, see @ref{Introduction to figured bass}.
-@strong{Fret and tab modes}
+@subsubsubheading Fret and tab modes
There are no special input modes for entering fret and tab symbols.
above the notes using the @code{\fret-diagram} command (see
@ref{Fret diagram markups}).
-@strong{Lyrics mode}
+@subsubsubheading Lyrics mode
This is activated with the @code{\lyricmode} command, and causes
input to be interpreted as lyric syllables with optional durations
@code{\lyricsto} command which associates the following lyrics
with the preceding music.
-@strong{Markup mode}
+@subsubsubheading Markup mode
This is activated with the @code{\markup} command, and causes
input to be interpreted with the syntax of markup, see
@ref{Text markup commands}.
-@c silly work-around for texinfo broken-ness
-@c (@strong{Note...} causes a spurious cross-reference in Info)
-@b{Note mode}
+@subsubsubheading Note mode
This is the default mode or it may be activated with the
@code{\notemode} command. Input is interpreted as pitches,
are in lyric mode, chord mode or any other mode and want to insert
something that only can be done with note mode syntax.
-For example, to indicate dynamic markings for the verses of a
-choral pieces it is necessary to enter note mode to interpret
-the markings:
-
-@lilypond[verbatim,relative=2,quote]
-{ c4 c4 c4 c4 }
-\addlyrics {
- \notemode{\set stanza = \markup{ \dynamic f 1. } }
- To be sung loudly
-}
-\addlyrics {
- \notemode{\set stanza = \markup{ \dynamic p 2. } }
- To be sung quietly
-}
-@end lilypond
-
-
@node Direction and placement
@subsection Direction and placement
@ref{Setting the staff size}.
+@node Dimensions
+@subsection Dimensions
+
+@cindex dimensions
+@cindex bounding box
+
+The dimensions of a graphical object specify the positions of the left
+and right edges and the bottom and top edges of the objects' bounding
+box as distances from the objects' reference point in units of
+staff-spaces. These positions are usually coded as two Scheme pairs.
+For example, the text markup command @code{\with-dimensions} takes
+three arguments, the first two of which are a Scheme pair giving the
+left and right edge positions and a Scheme pair giving the bottom and
+top edge positions:
+
+@example
+\with-dimensions #'(-5 . 10) #'(-3 . 15) @var{arg}
+@end example
+
+This specifies a bounding box for @var{arg} with its left edge at -5,
+its right edge at 10, its bottom edge at -3 and its top edge at 15,
+all measured from the objects' reference point in units of
+staff-spaces.
+
+@seealso
+Notation Reference:
+@ref{Distances and measurements}.
+
+
@node Staff symbol properties
@subsection Staff symbol properties
@end itemize
The routine responsible for drawing the stencils for these spanners is
-@code{ly:line-interface::print}. This routine determines the
+@code{ly:line-spanner::print}. This routine determines the
exact location of the two end points and draws a line
between them, in the style requested. The locations of the two
end points of the spanner are computed on-the-fly, but it is
where the last three columns indicate whether the layout objects
will be visible in the positions shown at the head of the columns:
-@multitable {@code{begin-of-line-invisible}} {@code{'#(#t #t #t)}} {Before} {At no} {After}
-@headitem Function @tab Vector @tab Before @tab At no @tab After
-@headitem form @tab form @tab break @tab break @tab break
-
-@item @code{all-visible} @tab @code{'#(#t #t #t)} @tab yes @tab yes @tab yes
-@item @code{begin-of-line-visible} @tab @code{'#(#f #f #t)} @tab no @tab no @tab yes
-@item @code{center-visible} @tab @code{'#(#f #t #f)} @tab no @tab yes @tab no
-@item @code{end-of-line-visible} @tab @code{'#(#t #f #f)} @tab yes @tab no @tab no
-@item @code{begin-of-line-invisible} @tab @code{'#(#t #t #f)} @tab yes @tab yes @tab no
-@item @code{center-invisible} @tab @code{'#(#t #f #t)} @tab yes @tab no @tab yes
-@item @code{end-of-line-invisible} @tab @code{'#(#f #t #t)} @tab no @tab yes @tab yes
-@item @code{all-invisible} @tab @code{'#(#f #f #f)} @tab no @tab no @tab no
+@multitable {@code{begin-of-line-invisible}} {@code{#(#t #t #t)}} {Before} {At no} {After}
+@headitem Function @tab Vector @tab Before @tab At no @tab After
+@headitem form @tab form @tab break @tab break @tab break
+
+@item @code{all-visible} @tab @code{#(#t #t #t)} @tab yes @tab yes @tab yes
+@item @code{begin-of-line-visible} @tab @code{#(#f #f #t)} @tab no @tab no @tab yes
+@item @code{center-visible} @tab @code{#(#f #t #f)} @tab no @tab yes @tab no
+@item @code{end-of-line-visible} @tab @code{#(#t #f #f)} @tab yes @tab no @tab no
+@item @code{begin-of-line-invisible} @tab @code{#(#t #t #f)} @tab yes @tab yes @tab no
+@item @code{center-invisible} @tab @code{#(#t #f #t)} @tab yes @tab no @tab yes
+@item @code{end-of-line-invisible} @tab @code{#(#f #t #t)} @tab no @tab yes @tab yes
+@item @code{all-invisible} @tab @code{#(#f #f #f)} @tab no @tab no @tab no
@end multitable
The default settings of @code{break-visibility} depend on the
texts and the lines, and tuning their behavior is therefore also
done in the same way. It is done with a spanner, and the routine
responsible for drawing the spanners is
-@code{ly:line-interface::print}. This routine determines the
+@code{ly:line-spanner::print}. This routine determines the
exact location of the two @i{span points} and draws a line
between them, in the style requested.
@lilypond[verbatim,quote,relative=1]
<<
- { e1~ e }
+ { e1~ 1 }
\\
{ r4 <g c,> <g c,> <g c,> }
>>
<<
{
\shape #'((0 . 0.5) (0 . 0.5) (0 . 0.5) (0 . 0.5)) Tie
- e1~ e
+ e1~ 1
}
\\
{ r4 <g c,> <g c,> <g c,> }