]> git.donarmstrong.com Git - lilypond.git/commitdiff
Reminders.
authorGraham Percival <graham@percival-music.ca>
Fri, 16 Nov 2007 19:49:23 +0000 (11:49 -0800)
committerJohn Mandereau <john.mandereau@gmail.com>
Fri, 23 Nov 2007 06:01:58 +0000 (07:01 +0100)
Documentation/user/input.itely

index 7220aaf663de0c2dd4a7ae55c7d56bdacb2b1e70..ddeb12a37d0cd2554e55c4e1b7788aeae10cc937 100644 (file)
@@ -13,6 +13,9 @@
 This section deals with general lilypond input syntax issues,
 rather than specific notation.
 
+FIXME: don't complain about anything in this chapter.  It's still
+under heavy development.
+
 @menu
 * Input files::                 
 * Common syntax issues TODO name?::  
@@ -553,6 +556,8 @@ TODO: staff spaces, #UP #DOWN #LEFT #RIGHT.  Maybe move into tweaks?
 @menu
 * Displaying LilyPond notation::  
 * Skipping corrected music::    
+* context list FIXME::          
+* another thing FIXME::         
 @end menu
 
 @node Displaying LilyPond notation
@@ -629,4 +634,157 @@ In polyphonic music, @code{Score.skipTypesetting} will affect all
 voices and staves, saving even more time.
 
 
+@node context list FIXME
+@subsection context list FIXME
+
+The Master Of All Contexts
+==========================
+
+    * Score
+        This is the top level notation context. No other context
+can
+        contain a Score context. This context handles the
+        administration of time signatures. It also makes sure that
+        items such as clefs, time signatures, and key-signatures
+are
+        aligned across staves.
+        You cannot explicitly instantiate a Score context (since
+it is
+        not contained in any other context). It is instantiated
+        automatically when an output definition (a \score or
+\layout
+        block) is processed. 
+        (it should also be made clear somewhere what the
+difference is between
+        \score and \Score).
+
+Top-level contexts: Staff containers
+====================================
+    * StaffGroup
+        Groups staves while adding a bracket on the left side,
+        grouping the staves together. The bar lines of the
+contained
+        staves are connected vertically. StaffGroup only consists
+of a
+        collection of staves, with a bracket in front and spanning
+bar
+        lines.
+    * ChoirStaff
+        Identical to StaffGroup except that the contained staves
+are
+        not connected vertically.
+    * GrandStaff
+        A group of staves, with a brace on the left side, grouping
+the
+        staves together. The bar lines of the contained staves are
+        connected vertically.
+    * PianoStaff
+        Just like GrandStaff but with a forced distance between
+the
+        staves, so cross staff beaming and slurring can be used.
+    * DrumStaff
+        Handles typesetting for percussion. Can contain DrumVoice
+    * InnerStaffGroup
+    * InnerChoirStaff
+
+Staff-level contexts
+====================
+    * Staff
+        Handles clefs, bar lines, keys, accidentals. It can
+contain
+        Voice contexts.
+    * RhythmicStaff
+        Like Staff but for printing rhythms. Pitches are
+        ignored; the notes are printed on one line.
+    * TabStaff
+        Context for generating tablature. By default lays the
+music
+        expression out as a guitar tablature, printed on six
+lines.
+    * VaticanaStaff
+        Same as Staff, except that it is accommodated for
+        typesetting a piece in gregorian style. 
+    * MensuralStaff
+        Same as Staff, except that it is accommodated for
+        typesetting a piece in mensural style. 
+
+Voice-level (bottom) contexts
+=============================
+What is generated by default here?  The voice-level contexts
+initiate
+certain properties and start engravers. 
+
+    * Voice 
+        Corresponds to a voice on a staff. This context handles
+the
+        conversion of dynamic signs, stems, beams, super- and
+        subscripts, slurs, ties, and rests.
+        You have to instantiate this explicitly if you want to
+have
+        multiple voices on the same staff. 
+        Bottom context.
+    * VaticanaVoice
+        Same as Voice, except that it is accommodated for
+        typesetting a piece in gregorian style.  
+    * MensuralVoice
+        Same as Voice, except that it is accommodated for
+        typesetting a piece in mensural style. 
+    * Lyrics
+        Corresponds to a voice with lyrics. Handles the printing
+of a
+        single line of lyrics.
+        Bottom context.
+    * DrumVoice
+        A voice on a percussion staff.
+    * FiguredBass
+         
+    * ChordNames
+        Typesets chord names.  This context is a `bottom' context;
+it
+        cannot contain other contexts.
+
+------------------------------
+Then the following, which I don't know what to do with:
+
+    * TabVoice
+    * GregorianTranscriptionVoice
+    * GregorianTranscriptionStaff
+
+    * FretBoards
+        Engraves fretboards from chords. Not easy... Not
+documented.
+    * NoteNames
+
+    * CueVoice Not documented
+    * Global
+        Hard coded entry point for LilyPond. Cannot be tuned.
+    * Devnull
+        Silently discards all musical information given to this
+context.
+
+
+@node another thing FIXME
+@subsection another thing FIXME
+
+Another thing that is needed, is an overview of the various naming
+conventions: 
+
+    scheme functions: lowercase-with-hyphens (incl. one-word
+names)
+    scheme functions: ly:plus-scheme-style
+    music events, music classes and music properties:
+as-scheme-functions
+    Grob interfaces: scheme-style
+    backend properties: scheme-style (but X and Y!)
+    contexts (and MusicExpressions and grobs): Capitalized or
+CamelCase
+    context properties: lowercaseFollowedByCamelCase
+    engravers:
+Capitalized_followed_by_lowercase_and_with_underscores
+
+Which of these are conventions and which are rules?
+Which are rules of the underlying language, and which are
+LP-specific?
+
+