Re: Header inside the score context

[David Wright]

On Wed 24 Nov 2021 at 19:44:59 (+0100), Paolo Prete wrote:

> > and then comment or comment out parts of the score that I don't need to
> > render. So, for example, if I need to render only section 2, I would
> > comment section 3 and section 1 but I have to comment the markup block
> > separately as well: this is unwanted, because the markup belongs to section
> > 1 context. Instead, it would be more appropriate to exclude automatically
> > the markup block when section one is not included.
> > Note that putting the sections into separate files, as you suggested, does
> > not solve the problem: instead of commenting blocks of code, I would have
> > to exclude both the file associated to the markup and the file associated
> > to section 1, if I want to render section 2.
> > Now, if I try to by-pass the problem with a \book context, I can embed the
> > markup into section 1:

> I see what you mean (thanks for your further explanation) but it would not
> work for what I want to achieve. I try to explain why.
> My example is focused on _rendering_. With your procedure, I would
> statically fix portions to be rendered separately, and each portion would
> be a separate file. This is good when writing parts, or when writing
> movements of a composition. But in my case, all the sections dynamically
> vary because they represents what to be rendered.
> This means that, for example, when a section takes too much time to be
> rendered, I can decide to shrink it. Then, for example, I fix a problem,  I
> verify the problem has fixed (---> rendering) and then I enlarge it to its
> original size ( == amount of rendered measures). This is what I do very
> often (it saves much time!) and this is why I comment/comment out portions
> of the score.

>From the description above, it seems as if you're manually
preprocessing your code by inserting %{ and %} strings at
appropriate places for the compilation concerned.

If you do this regularly, I would suggest that that's just
what you do, copy your source through a simple filter to a
temporary file and compile that.

Directives such as:

%%% PAOLO %%% +foo -bar

could turn on/off copying the source at multiple points so that
inclusions of related material occur when you run, say,

filter foo baz

Such a filter is very easy to construct because you have total
control over what it sees and reacts to. And I think it would
be less error-prone that fiddling with %{ %} strings.

Feel free to ignore this method.

Cheers,
David.