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

[Juergen Reuter]

On Sun, 26 Sep 2004, Han-Wen Nienhuys wrote:

> 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.
> 

Ok.  May I request to put this issue (or a workaround for it) on the TODO 
list for future versions of lilypond?

> > 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.
> 

That's what I would have guessed, though I was not at all sure about it.  
Maybe a short comment about simultaneous expressions should be added 
somewhere in the manual.

> 
> > 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.
> 

I disagree with your disagreement.  I am mainly talking about conflicting 
properties stemming from *different* contexts only (I should have been 
clearer about this).  Your "\voiceOne \stemDown" example should not 
produce a warning, since the two commands live in the same context.

Just think of (somewhat like) a race condition in parallel programming: 
Simultaneously setting conflicting properties in different contexts is 
conceptually bad, because in order to know which is evaluated when, you 
have to know the order in which lily *internally* handles the contexts 
(unless you clearly and exactly specify the behaviour in the docu, thus 
making it externally part of the syntax/semantcis).  For conflicting 
property settings within the same music expression of a single context 
however, it appears natural that the last one in the (sequential) 
expression wins, as *externally* specified by the user.

> > 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. 
> 

Maybe I will bring back this issue onto this list for lily 4.0. ;-)

Greetings,
Jürgen

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