lilypond-devel
[Top][All Lists]
Advanced

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

[bug] \once \override Score.SystemStartBracket holds forever


From: Han-Wen Nienhuys
Subject: [bug] \once \override Score.SystemStartBracket holds forever
Date: Sun, 26 Sep 2004 01:37:11 +0200

address@hidden writes:
> Hi!
> 
> Once Score.SystemStartBracket #'transparent has been overridden to ##t, it 
> seems it is not possible to revert the effect.  For an example, look at 
> section 3.4.2 in the manual (in recent CVS; this is not yet on the web 
> site) or, respectively, in the generated file
> Documentation/user/out-www/lilypond/lily-2054725167.ly.  As you can see, 
> the system start bracket is removed from both lines of score, not just the 
> first one.

This is intentional. The system start is a single big spanner. It is
possible to tweak different parts of the spanner, but that requires
some exotic code.

> On a similar vein, in the manual it does not get clear what happens 
> with contradicting \override or \set commands (at least I could not find 
> something about this issue).


> Imagine, for example, two voices that live 
> in the same staff.  The first voice sets some context property of the 
> staff context or overrides a grob property of a grob that lives in the 
> staff context.  The second voice touches the same properties at the same 
> score time, but with different values.  Which voice wins?

Commands are processed in the order that they appear within the music
expression. In this case, whichever voice comes last in the
simultaneous expression wins.


> The manual 
> probably should say something about this (or, even better, maybe in 3.1.x, 
> lily should issue a warning during interpreting phase about conflicting 
> property settings).

I disagree. That would create lots of spurious warnings, eg,

        \voiceOne
        \stemDown

which is IMO perfectly valid will produce a warning.

> Of course, the cleanest solution would be to allow 
> property settings only for the current scope of context (which would have 
> some major consequences for lily's syntax, though).

I think that this solution will create more problems than it intends
to solve. 

-- 

 Han-Wen Nienhuys   |   address@hidden   |   http://www.xs4all.nl/~hanwen 





reply via email to

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