For what it's worth my use case was that I use the same variable names for
each instrument in a separate file for each movement of a piece. I
therefore need to \include the music for each movement immediately before
the \score for that movement, in order to redefine the variables with the
music for that movement. For the full score, that doesn't require
\parserDefine because each movement can be its own \bookpart. However, for
printing parts, I find it helpful to have all instruments output in the
same \book, with each instrument as a \bookpart. That means that I need to
be able to redefine the music variables within a \bookpart.
If I were willing to use different variable names for instruments in each
movement this wouldn't be needed, but I just find that ugly. I want my
violinI to always be called violinI. There might be other ways to
accomplish a similar goal but this has worked fine for me.
On Sun, Mar 12, 2023 at 4:45 PM Jean Abou Samra <j...@abou-samra.fr> wrote:
> Le dimanche 12 mars 2023 à 16:34 -0700, Saul Tobin a écrit :
>
> A slightly nicer syntax to workaround this limitation is to use the
> function:
> parserDefine =
> #(define-void-function (name val)(symbol? scheme?)
> (ly:parser-define! name val))
>
> Then instead of var = { ... } you can write \parserDefine var { ... }.
>
> I believe this was posted on the list a few years ago.
>
> Yes. However, if you end up finding this useful, I consider it likely that
> it indicates you should refactor your code. Off the top, I can't even think
> of a case where this is the best way to proceed.
>
