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.