[ << Interfaces for programmers ] | [Top][Contents][Index] | [ LilyPond Scheme interfaces >> ] |
[ < Interfaces for programmers ] | [ Up : Interfaces for programmers ] | [ Scheme functions > ] |
2.1 LilyPond code blocks
Creating music expressions in Scheme can be tedious, as they are heavily nested and the resulting Scheme code is large. For some simple tasks this can be avoided by using LilyPond code blocks, which enable common LilyPond syntax to be used within Scheme.
LilyPond code blocks look like
#{ LilyPond code #}
Here is a trivial example:
ritpp = #(define-event-function () () #{ ^"rit." \pp #} ) { c'4 e'4\ritpp g'2 }
LilyPond code blocks can be used anywhere where you can write Scheme
code. The Scheme reader actually is changed for accommodating
LilyPond code blocks and can deal with embedded Scheme expressions
starting with $
and #
.
The reader extracts the LilyPond code block and generates a runtime
call to the LilyPond parser to interpret the LilyPond code.
Scheme expressions embedded in the LilyPond code are evaluated in the
lexical environment of the LilyPond code block, so all local variables
and function parameters available at the point the LilyPond code block
is written may be accessed. Variables defined in other Scheme modules,
like the modules containing \header
and \layout
blocks,
are not accessible as Scheme variables, i.e., prefixed
with #
, but they are accessible as LilyPond variables, i.e.
prefixed with \
.
All music generated inside the code block has its ‘origin’ set to the current input location.
A LilyPond code block may contain anything that you can use on the right side of an assignment. In addition, an empty LilyPond block corresponds to a void music expression, and a LilyPond block containing multiple music events gets turned into a sequential music expression.
[ << Interfaces for programmers ] | [Top][Contents][Index] | [ LilyPond Scheme interfaces >> ] |
[ < Interfaces for programmers ] | [ Up : Interfaces for programmers ] | [ Scheme functions > ] |