[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLISS] - alternative viewpoint
From: |
Keith OHara |
Subject: |
Re: [GLISS] - alternative viewpoint |
Date: |
Sat, 15 Sep 2012 20:50:24 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
David Kastrup <dak <at> gnu.org> writes:
> "Phil Holmes" <email <at> philholmes.net> writes:
>
> > What does get me more concerned is how hard
> > it is to find some of the correct ways of tweaking output. Using
> > voice.SomeValue (or is it Voice.someValue) when it should be
> > staff.Somevalue (or was it Staff.someValue) frequently results in no
> > change to the output.
>
As they say, "Me too." This is the reason I gave up on LilyPond, several
times now.
> Yup. Here is my multi-stage plan for that:
> b) our C++ engravers announce to the type system (and via that, to the
> documentation) which context properties they read, modify and write.
> There is no reason that this does not also include the Grob descriptions
> which are even now a special case of context property.
> d) \override xxx is equivalent to \override Bottom.xxx, with Bottom
> being a context without \defaultchild (to be recursively created from
> the current context, if that is not a bottom context, by creating the
> respective defaultchildren in sequence until hitting bottom). If all
> our engravers had correctly registered the context properties they read,
> \override xxx could instead set the property in the context closest to
> bottom that will actually _look_ at the changed property.
These two steps alone will drastically increase usability and the user-base.
> Of course, this is not without drawback either: if there are multiple
> engravers looking at that property at multiple levels
This 'drawback' is still an improvement relative to the current situation.
\once\override TimeSignature #'stencil = ##f
If the override has effect only for one staff when we wanted it to affect
a StaffGroup, it is easier to discover the solution than currently, where
the override is ignored entirely.
- Re: [GLISS] - alternative viewpoint, (continued)
- Re: [GLISS] - alternative viewpoint, Janek Warchoł, 2012/09/17
- Re: [GLISS] - alternative viewpoint, David Kastrup, 2012/09/15
- Re: [GLISS] - alternative viewpoint, Werner LEMBERG, 2012/09/15
- Re: [GLISS] - alternative viewpoint, Janek Warchoł, 2012/09/16
- Re: [GLISS] - alternative viewpoint, David Kastrup, 2012/09/16
- Re: [GLISS] - alternative viewpoint, Janek Warchoł, 2012/09/22
Re: [GLISS] - alternative viewpoint,
Keith OHara <=
Re: [GLISS] - alternative viewpoint, Janek Warchoł, 2012/09/16
Re: [GLISS] - alternative viewpoint, Janek Warchoł, 2012/09/22