lilypond-user
[Top][All Lists]
Advanced

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

Re: (De)activate lilypond-source snippets based on whether a variable is


From: David Kastrup
Subject: Re: (De)activate lilypond-source snippets based on whether a variable is defined
Date: Mon, 20 May 2013 15:26:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Hans Aikema <address@hidden> writes:

> allMusic = {
>     \new ChoirStaff <<
>         %if defined variable soloOneMusic
>             \new Staff = soloOne \with {
>                   midiMinimumVolume = \volFullMin
>                   midiMaximumVolume = \volFullMax
>             }<<
>                 \new Voice = "voiceSoloOne" { << \global \soloOneMusic >> }
>             >>
>         %endif

Not necessarily fabulous, but you could likely work with

          $(if (defined? 'soloOneMusic)
            #{
             \new Staff = soloOne \with {
                   midiMinimumVolume = \volFullMin
                   midiMaximumVolume = \volFullMax
             }<<
                 \new Voice = "voiceSoloOne" { << \global \soloOneMusic >> }
             >>
             #})

Note that \soloOneMusic must not be evaluated by LilyPond if
soloOneMusic is not defined.  One way is to put it manually into a
conditionally evaluated string, but string syntax requires quoting of \
characters and quote marks.  #{ ... #} actually wraps stuff in a string
for later evaluation itself and works without similar quoting
requirements.

Because music function arguments are evaluated before the music function
is called, you can't let a music function do the same kind of job.  Also
LilyPond syntax, as opposed to most of Scheme syntax, is context
dependent, so the parsing already needs to know just what kind of
identifier \soloOneMusic is.

Note that the C preprocessor works textually and completely independent
from the underlying syntax.  It is conceivable to create some
specialized constructs for skipping LilyPond input right at the input
layer and regardless of nesting.  Using them reliably might prove to be
a challenge, though.  If you want to look for inspiration regarding
tampering with input, check out LilyPond's #{ #} processor in
scm/parser-ly-from-scheme.scm or the less complex #[ #] construct
defined in input/regression/display-lily-tests.ly: either way, the hard
word is done by using read-hash-extend for plugging into the Scheme
reader.

-- 
David Kastrup




reply via email to

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