denemo-devel
[Top][All Lists]
Advanced

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

[Denemo-devel] Roadmap for Directives


From: Richard Shann
Subject: [Denemo-devel] Roadmap for Directives
Date: Sun, 15 Mar 2009 13:13:41 +0000

I think I see the road ahead for DenemoDirectives. Not the development
that will control MIDI but the aspects that control LilyPond print out.
We can arrange to attach directives to control the \paper block as
discussed before, but also we should attach them to the clefs and
keysignatures.
Now comes the interesting bit:
        The chord and note directives have two fields prefix and postfix which
do what they say on the label: they prefix and postfix the LilyPond that
is generated for the chord or note.
        In the case of Staff and Voice directives the semantics can be
expanded: the postfix comes after the \new Staff/Voice which gives the
context, while the prefix should, well not quite prefix but over-ride
the context. So if you set the prefix field you will need to introduce
the context you want. (An example would be the Vaticana context for
Gregorian chant, but there are many others, at present only accessible
by writing a custom scoreblock). 
        The same semantics can apply to the Clef directives - if you set the
prefix field then the default (i.e. built-in) initial clef will be
ignored, it won't be displayed in Denemo and you will provide your own
graphic. In this way we can support e.g. Drum clef without hard-wiring
it in to Denemo's C code. 
        Likewise we can support change of clef by putting in a clef change
object and attaching a directive to it to emit the correct LilyPond and
to display the correct graphic.
        Finally, the standalone DenemoDirectives (the original Lily Inserts of
previous releases) have also a redundant field & a requirement needing a
slot: as I have flagged up before, many LilyPond constructs have an open
and close aspect - that is they start something at one point in the
music and stop it later. We can use the prefix slot to hold the tag of
the corresponding part of the construct. Having given it some thought, I
think that we can live with the name "prefix" for this field internally;
for scheme scripting purposes we can do what is known as syntactic
sugaring, so, for example, we will write

(d-DirectivePut-standalone-matchingopen "EndRepeat" "StartRepeat")

Which will mark the EndRepeat standalone directive at the cursor to have
a sibling directive tagged StartRepeat. This will in fact be calling 
(d-DirectivePut-standalone-prefix "EndRepeat" "StartRepeat")
but the script writer does not need to know this. Note that we do not
(and do not need to) store in the Directive whether this is an open or
close: the edit script for EndRepeat knows that it is a close & will
search backwards to see if it has a corresponding StartRepeat. There may
be no such directive in some anomalous condition, but generally we will
write scripts to insert these in pairs, and perhaps have other features
to avoid unbalanced pairs. (We could, at the least, check for such
before printing).

At present the prefix field of a standalone directive is being output
with the postfix field in a redundant manner: I will stop this happening
& should anyone have written a script that depends on this, please put
all your LilyPond into the postfix field (as is normal) for standalone
directives.

comments welcome,

Richard







reply via email to

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