[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strange behaviour of \layout block variable
From: |
David Kastrup |
Subject: |
Re: strange behaviour of \layout block variable |
Date: |
Mon, 21 May 2012 21:17:27 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
Janek Warchoł <address@hidden> writes:
> David,
>
> On Mon, May 21, 2012 at 7:20 AM, David Kastrup <address@hidden> wrote:
>> I don't see anything wrong in the _written_ assumptions. Perhaps the
>> misunderstanding is that you consider context definitions as independent
>> from layout blocks, and just placed syntactically inside of them for
>> some unfathomable reason. But each layout variable (including
>> $defaultlayout) has its own set of context definitions. You can't
>> actually _change_ context definitions using LilyPond rather than Scheme
>> code. If you write something like
>>
>>> \context {
>>> \Score
>>> \override Hairpin #'thickness = 3
>>> }
>>
>> This creates a _copy_ of all definitions in the current Score context
>> def, adds an override to it, and uses the result as a new context def.
>> This new context def is then used for Score because it contains a
>> \name "Score" definition, from the copy of the original Score context
>> def.
>
> Thanks for the explanation! I think i now roughly understand how it
> works. However, i find this design somewhat confusing, and i'm
> wondering whether it would be possible to change it (if changing it is
> a good idea at all).
>
> Going back to what we have, i thought that defining "layoutVariable"
> in this way will solve the problem:
>
> layoutVariable = {
> \context {
> \Score
> \override Hairpin #'style = #'dashed-line
> }
> }
Uh what? That declares layoutVariable as sequential music. This
sequential music starts with a \context missing a name and an undefined
command called \Score, containing an \override inside.
> Interestingly, it works but issues a syntax error.
Only one syntax error?
> Surprisingly,
>
> layoutVariable = {
> \override Score.Hairpin #'style = #'dashed-line
> }
>
> (which is possible at all thanks to your work) doesn't issue any
> error, and does work.
But is anything but a layout variable. It is an override inside of
sequential music. You can leave off the braces so that it is only an
override, but it is still music.
> Does this mean that
>
> \override Score.Hairpin #'style = #'dashed-line
>
> is "better" than
>
> \context {
> \Score
> \override Hairpin #'style = #'dashed-line
> }
>
> when used in \layout?
No. It means that it is music rather than a context or layout
definition. The "problem" when storing a context or layout definition
is that you store something absolute rather than a modification. You
_can_ store context _modifications_ into variables as well, but they
don't carry a relation to a particular context definition.
There is no "layout modification", an incremental change to layouts.
The music has the advantage of containing just the wanted modification
_and_ the target of "Score".
> Until now i thought these two were equal.
They are. And the second form is more direct. The first form has the
advantage that it is easier to juggle around in variables.
--
David Kastrup
- strange behaviour of \layout block variable, Urs Liska, 2012/05/20
- Re: strange behaviour of \layout block variable, David Kastrup, 2012/05/20
- Re: strange behaviour of \layout block variable, Urs Liska, 2012/05/20
- Re: strange behaviour of \layout block variable, David Kastrup, 2012/05/21
- Re: strange behaviour of \layout block variable, Urs Liska, 2012/05/21
- Re: strange behaviour of \layout block variable, David Kastrup, 2012/05/21
- Re: strange behaviour of \layout block variable, Urs Liska, 2012/05/21
- Documentation suggestion (was: strange behaviour of \layout block variable), Urs Liska, 2012/05/21
- Re: Documentation suggestion (was: strange behaviour of \layout block variable), Marek Klein, 2012/05/23
- Re: strange behaviour of \layout block variable, Janek Warchoł, 2012/05/21
- Re: strange behaviour of \layout block variable,
David Kastrup <=