[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug] \once \override Score.SystemStartBracket holds forever
From: |
Juergen Reuter |
Subject: |
Re: [bug] \once \override Score.SystemStartBracket holds forever |
Date: |
Mon, 27 Sep 2004 01:09:37 +0200 (CEST) |
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
>