> +COMMENT( \translator seems like a strange name for the second
> +operation, and is the overloading desireable? )
>
> No. suggestions welcome.
Well, what comes to mind initially would be to rename "\type" to
"\context" and then have something like "\shiftcontext" or
"\changecontext" for switching to a different context. (I think
probably changecontext is better.)
OK. That means we'll have to be certain about the name context, then.
> +dit(code(RhythmicStaff)) A context like code(Staff) but for printing
> +rhythms. Pitches are ignored; the notes are printed on one line.
> +It can contain code(Voice) or code(Lyrics) contexts.
>
> Only Voice, I think.
I confirmed that Lyrics works. (It probably should, in any case.
Somebody might want to notate chants with rhythm but no pitch.)
I think you are mistaken. If you do
\type RhythmicStaff <
\type Voice ...
\type Lyrics ...
>
the lyrics aren't placed within the RhythmicStaff, but in the context
containing that. What can be in a context is controlled through the
keyword \accepts.
> + description(
> + dit(code(maxVerticalAlign))
> + dit(code(minVerticalAlign))
> + )
>
> Set min/max distance between staffs.
What is the slack between the min and max distance used for?
LilyPond will space the staffs vertically to prevent collisions. Use
a lot of scripts, and it will take more space (and yes, this is not
Real-Engravers-behaviour, i know)
> + dit(code(SkipBars)) ???
>
> Do not expand multimeasure rests. Useful for separate parts of
> orchestral scores.
Looks like the name might be backwards. (Setting it to 1 supresses
skipping of bars.)
Umm. No the other way around (timing-translator.cc)
/* allbars == ! skipbars */
bool allbars = ! get_property ("SkipBars").to_bool ();
if (!time_.cadenza_b_ && allbars)
global_l->add_moment_to_process (time_.next_bar_moment ());
> +dynamic-engraver.cc: "dynamicdir"
> +span-bar-engraver.cc: "singleStaffBracket"
>
> do/don't bracket single staffs
>
> +stem-engraver.cc: "abbrev"
>
> automatically add tremolo
What does tremolo look like? It tried setting this to 0 and 1 and
didn't see any difference.
It must be like note duration (try 16).
I made a guess that assignments inside \translators are actually
setting properties, and that these settings take precedence over
\property keywords. This does seem to be true. But I am puzzled
by
they don't take precedence.
the behavior of the following where I tried to change the default clef
with \property. I made a Staff translator with no default clef, and
set the default clef elsewhere. The notes are all printed according
to my new default clef, but no clef symbol appears. (I'm using
1.0.9).
Actually, there is no clef at all (central c = center line). I'll look
into it.
> > +are: arglist, assignlist and musiclist. An arglist is a
> > +white space separated list of integers, reals and or strings surrounded
> > +by braces code({) and code(}). An assignlist is a list of
> > +identifier assignments, which have the form var(key)code(=)var(value).
> > +The simplest musiclist is a single note. More complicated music lists
>
> I disagree: a single something is not a list.
Well, generally computer scientists allow degenerate cases because it
simplifies descriptions of things. It seemed awkward not to use
the
But it isn't a degenerate case. The list is formed by the {} and <>.
term "list" in there because "music" doesn't seem to make an
acceptible noun. (I can say "this keyword takes an integer", or
"this integer..." But it seems wrong to say "this keyword takes a
music". I have to write "this keyword takes an argument of type
music", which seems overly long and wordy.)
How about: a chunk of music
Here's a question for contemplation:
How important are the different identifiers that are defined in the
init files? Are users likely to inadvertently overwrite them? And if
so, would the result be mysterious, or would the cause be obvious?
Would it be worthwhile to adopt some convention of giving the
internally defined identifiers a special form. (For example, in
LaTeX, internally defined identifiers contain the '@' sign.) Adopting
some convention like this could create a reserved name space for
internally defined identifiers thus preventing confusion. (The price
of this might be that typing the internally defined identifiers would
be more trouble.)
Hmm. I'll have to think some more about that. Right now I have some
teaching to do :)
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
