lilypond-user
[Top][All Lists]
Advanced

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

Re: cleanly dealing with variables and reducing code duplication in mult


From: Jan-Peter Voigt
Subject: Re: cleanly dealing with variables and reducing code duplication in multimovement works
Date: Thu, 03 Apr 2014 09:39:42 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Hi Saul,

I faced the same situation you describe here. In a first ending there is
my personal framework lalily:
https://github.com/jpvoigt/lalily

There are templates, which are the score blocks to instantiate, which
reference the music in music-folders - or namespaces, if you like.
And there are functions to collect music for books and bookparts.
I extracted the template engine and the edition-engraver to the
openLilyLib-Snippets repo:
https://github.com/openlilylib/snippets/tree/master/templates/lalily
https://github.com/openlilylib/snippets/tree/master/editorial-tools/edition-engraver

I usually include the music first and then create the book. But if you
want "save" includes without toplevel variable definitions, you can use
a function like this:
https://github.com/openlilylib/snippets/blob/master/general-tools/scheme-wrapper/parserDefine/definitions.ily

In my template engine, the music is not stored in toplevel variables,
but in a module-wrapped tree-structure, where you can address elements
with a namespace- or directory-like path.

Header information is stored for each music-folder/namespace and
recalled and inserted with the book-generating functions. I am going to
create a demo on how to create a book with one or more
multi-movement-pieces soon.

Jan-Peter


Am 03.04.2014 08:57, schrieb Shevek:
> Hello,
> 
> I'm working on a multi-movement piece, so far using a separate file for the
> score of each movement. I'm trying to add a file to the project that
> compiles all the movements and frontmatter into a single pdf, using
> bookparts, and I'm having trouble figuring out the best way to do that. The
> nicest way would be if all I needed to do were:
> 
> \book {
>   \bookpart {
>     \include "movement1_score.ly"
>   }
>   \bookpart {
>     \include "movement2_score.ly"
>   }
> }
> 
> As you might guess, that fails because each of the included files itself
> includes a file (e.g. movement1_music.ly) containing variable declarations,
> and variable declarations aren't allowed inside bookparts. The solution to
> that problem is for me to include movement1_music.ly etc. outside the \book
> block. That causes another problem, though, because I am using the same
> variable naming scheme for each of the movements. Obviously, I could solve
> that problem by adding a prefix to all the variable names, but that seems
> really yucky to me. I find myself craving some way to reference same-named
> variables in different namespaces, like movement1.flute versus
> movement2.flute.
> 
> Related to that craving is the fact that the score blocks for each of the
> movements are identical, which makes me feel like there ought to be some way
> to get rid of that code duplication. Really, I want to define the structure
> of the score block once, and then instantiate it multiple times, feeding
> each instance a different namespace, so that the first score block instance
> looks up "flute" in the movement1 namespace, while the second score block
> instance looks up "flute" in the movement2 namespace.
> 
> I'm sure this can't be a unique use case. Any suggestions on the best way to
> accomplish some or all of this? Am I thinking too much like a Python
> programmer to see the natural way to approach these issues in
> Lilypond/Scheme? Are some of these issues unsolvable without changes to
> Lilypond?
> 
> Some similar questions:
> http://lilypond.1069038.n5.nabble.com/Books-bookparts-includes-what-td52157.html
> http://lilypond.1069038.n5.nabble.com/bookparts-with-paper-blocks-td145242.html
> http://stackoverflow.com/questions/20858042/define-function-inside-score-in-lilypond
> 
> Thanks,
> 
> Saul





reply via email to

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