Re: \set vs \override
In message 4b0bc390.1080...@internode.on.net, Nick Payne nick.pa...@internode.on.net writes Carl Sorensen wrote: On 11/24/09 2:57 AM, Nick Payne nick.pa...@internode.on.net wrote: James Worlton wrote: Hi! In 2.13.6 I did a project and used: \set Score.markFormatter = #format-mark-box-alphabet and I got the boxes and the letter I (all in one command!) Thanks for that. That particular value for set (format-mark-box-alphabet) doesn't seem to appear anywhere in the documentation - or at least, I can't find it in the PDF documentation, which is what I use. This must be a bug in the documentation. Nick, could you figure out where it should go, and write a bit of text and a simple example, so we can add it to the docs? Well I only have/use the PDF documentation, and the section on Rehearsal marks is on p.74 of the 2.13.7 Notation reference. After the initial example, it presently says: == The letter ‘I’ is skipped in accordance with engraving traditions. If you wish to include the letter ‘I’, then use \set Score.markFormatter = #format-mark-alphabet == Following up a bit late, I know ... If you look back at when format-mark-alphabet first appeared, you'll find I featured prominently (and ineptly :-) I wanted the functionality, tried to write it and got into a mess. Somebody else kindly added it for me, along with various other features such as using bar numbers as rehearsal marks. And as part of that, I understand that ALL combinations of mark on its own, mark in a circle and mark in box crossed with bar-number, number, letter and alphabet were created. I can't remember the scheme file name, but iirc they are all in the same file, if anyone wants to check, but the documentation should say that ANY and ALL combinations of mark and mark-formatting should work, and if they don't it's a bug. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
2009/11/24 Han-Wen Nienhuys hanw...@gmail.com: I think you send a lot of mail. I suggest reading code; if it were easy, where would the fun be? Sorry if it sounds angry. My humble opinion is that it's absolutely NOT FUN to have a future without LilyPond because reading the code was not easy enough. As a hint: Every hint is immensely appreciated, of course. I agree in that labyrinths are fun to solve, but not if that means the project running out of developers and especially if somebody knows the path. Sorry again, I had to say it. -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
James Worlton wrote: Hi! On Nov 23, 2009, at 9:26 PM, Nick Payne wrote: On this subject of set vs override, if I want rehearsal marks to be boxed letters and also want to use the letter I as a rehearsal mark, how can I do that. Each set command overwrites the previous value of the context property, so if I use: \set Score.markFormatter = #format-mark-box-letters \set Score.markFormatter = #format-mark-alphabet then I get I as a rehearsal mark but the letters aren't boxed, and if I use: \set Score.markFormatter = #format-mark-alphabet \set Score.markFormatter = #format-mark-box-letters In 2.13.6 I did a project and used: \set Score.markFormatter = #format-mark-box-alphabet and I got the boxes and the letter I (all in one command!) Thanks for that. That particular value for set (format-mark-box-alphabet) doesn't seem to appear anywhere in the documentation - or at least, I can't find it in the PDF documentation, which is what I use. Nick ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On 11/24/09 2:57 AM, Nick Payne nick.pa...@internode.on.net wrote: James Worlton wrote: Hi! In 2.13.6 I did a project and used: \set Score.markFormatter = #format-mark-box-alphabet and I got the boxes and the letter I (all in one command!) Thanks for that. That particular value for set (format-mark-box-alphabet) doesn't seem to appear anywhere in the documentation - or at least, I can't find it in the PDF documentation, which is what I use. This must be a bug in the documentation. Nick, could you figure out where it should go, and write a bit of text and a simple example, so we can add it to the docs? Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Carl Sorensen wrote:
On 11/24/09 2:57 AM, Nick Payne nick.pa...@internode.on.net wrote:
James Worlton wrote:
Hi!
In 2.13.6 I did a project and used:
\set Score.markFormatter = #format-mark-box-alphabet
and I got the boxes and the letter I (all in one command!)
Thanks for that. That particular value for set
(format-mark-box-alphabet) doesn't seem to appear anywhere in the
documentation - or at least, I can't find it in the PDF documentation,
which is what I use.
This must be a bug in the documentation.
Nick, could you figure out where it should go, and write a bit of text and a
simple example, so we can add it to the docs?
Well I only have/use the PDF documentation, and the section on Rehearsal
marks is on p.74 of the 2.13.7 Notation reference. After the initial
example, it presently says:
==
The letter ‘I’ is skipped in accordance with engraving traditions. If
you wish to include the
letter ‘I’, then use
\set Score.markFormatter = #format-mark-alphabet
==
This should probably be changed to
==
The letter ‘I’ is skipped in accordance with engraving traditions. If
you wish to include the
letter ‘I’, then use one of the following commands, depending on which
style of rehearsal mark you want (letters only, letters in a hollow box,
or letters in a hollow circle)
\set Score.markFormatter = #format-mark-alphabet
\set Score.markFormatter = #format-mark-box-alphabet
\set Score.markFormatter = #format-mark-circle-alphabet
==
And a simple example (goes up to letter J, not much point to it if it
doesn't go past I)
\relative c'' {
\set Score.markFormatter = #format-mark-box-alphabet
c1 \mark \default
c1 \mark \default
c1 \mark \default
c1 \mark \default
c1 \mark \default
c1 \mark \default
c1 \mark \default
c1 \mark \default
c1 \mark \default
c1 \mark \default
}
Nick
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Nick Payne nick.pa...@internode.on.net writes: Carl Sorensen wrote: On 11/24/09 2:57 AM, Nick Payne nick.pa...@internode.on.net wrote: James Worlton wrote: Hi! In 2.13.6 I did a project and used: \set Score.markFormatter = #format-mark-box-alphabet and I got the boxes and the letter I (all in one command!) Thanks for that. That particular value for set (format-mark-box-alphabet) doesn't seem to appear anywhere in the documentation - or at least, I can't find it in the PDF documentation, which is what I use. This must be a bug in the documentation. Nick, could you figure out where it should go, and write a bit of text and a simple example, so we can add it to the docs? Well I only have/use the PDF documentation, and the section on Rehearsal marks is on p.74 of the 2.13.7 Notation reference. After the initial example, it presently says: That's a lot of orthogonal functionality. Maybe one should just make \set Score.markFormatter = #(format-mark-alphabet format-mark-box) work by letting format-mark-alphabet checking its argument, and if it is a function, create a closure from it that transforms the number properly? Being able to stack closures in that manner might be convenient in other cases as well. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Tue, Nov 24, 2009 at 3:50 AM, David Kastrup d...@gnu.org wrote: Sigh. I guess I give up. Yes, I understood that. Pretty much from the get-go, and also from the manual. The unanswered question is _why_ you want only _one_ of the two different things happen to _one_ half of the properties, and the _other_ of the two different things happen to the _other_. Because that's what people want? \override Script #'direction = #UP is useful. \set Script = #(blah) is ridiculous, because it would overwrite (Script . ( (cross-staff . ,ly:script-interface::calc-cross-staff) (direction . ,ly:script-interface::calc-direction) (font-encoding . fetaMusic) (positioning-done . ,ly:script-interface::calc-positioning-done) (side-axis . ,Y) ;; padding set in script definitions. (staff-padding . 0.25) (stencil . ,ly:script-interface::print) (X-offset . ,script-interface::calc-x-offset) (Y-offset . ,ly:side-position-interface::y-aligned-side) (meta . ((class . Item) (interfaces . (font-interface script-interface side-position-interface)) thereby removing all of its functionality, including appearance of the symbol in the output. If this is so unlogical to you that it needs to be explained, I give up explaining things to you. At some point we had \set Foo.Bar \override #'x = #y syntax for this, but it was deemed to confusing, so we gave it a different syntax. I'm fine with the two different syntaxes for the two different actions. But why is one action only for context properties, the other only for grob properties (which are also pre-registered in the context)? -- David Kastrup -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Han-Wen Nienhuys hanw...@gmail.com writes: On Tue, Nov 24, 2009 at 3:50 AM, David Kastrup d...@gnu.org wrote: Sigh. I guess I give up. Yes, I understood that. Pretty much from the get-go, and also from the manual. The unanswered question is _why_ you want only _one_ of the two different things happen to _one_ half of the properties, and the _other_ of the two different things happen to the _other_. Because that's what people want? You have not convinced me that I want it. \override Script #'direction = #UP is useful. \set Script = #(blah) is ridiculous, because it would overwrite Indeed ridiculous. How about using comparable things? We are talking about something like \override Script #'staff-padding = #3 vs \set Script.staff-padding = #3 Why should I not use the second one rather than the first if I am out for establishing a global default? thereby removing all of its functionality, including appearance of the symbol in the output. If this is so unlogical to you that it needs to be explained, I give up explaining things to you. Explaining things to me can't be much fun. It might be worth cutting the exercise short by explaining what I am asking about rather than something else. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Grammatically \set Context.Property = #value \set Grob.GrobProperty = #value both look like \set STRING . STRING = SCHEME ie. you can't distinguish between both actions if you unify the syntax. On Tue, Nov 24, 2009 at 11:26 AM, David Kastrup d...@gnu.org wrote: Han-Wen Nienhuys hanw...@gmail.com writes: On Tue, Nov 24, 2009 at 3:50 AM, David Kastrup d...@gnu.org wrote: Sigh. I guess I give up. Yes, I understood that. Pretty much from the get-go, and also from the manual. The unanswered question is _why_ you want only _one_ of the two different things happen to _one_ half of the properties, and the _other_ of the two different things happen to the _other_. Because that's what people want? You have not convinced me that I want it. \override Script #'direction = #UP is useful. \set Script = #(blah) is ridiculous, because it would overwrite Indeed ridiculous. How about using comparable things? We are talking about something like \override Script #'staff-padding = #3 vs \set Script.staff-padding = #3 Why should I not use the second one rather than the first if I am out for establishing a global default? thereby removing all of its functionality, including appearance of the symbol in the output. If this is so unlogical to you that it needs to be explained, I give up explaining things to you. Explaining things to me can't be much fun. It might be worth cutting the exercise short by explaining what I am asking about rather than something else. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Op dinsdag 24-11-2009 om 12:23 uur [tijdzone -0200], schreef Han-Wen Nienhuys: Grammatically \set Context.Property = #value \set Grob.GrobProperty = #value both look like \set STRING . STRING = SCHEME ie. you can't distinguish between both actions if you unify the syntax. Hmm, why is this destinction necessary? Why can't we determine from the first STRING used whether we're seting a context or grob property? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On 11/24/09 4:56 AM, David Kastrup d...@gnu.org wrote: Nick Payne nick.pa...@internode.on.net writes: Carl Sorensen wrote: On 11/24/09 2:57 AM, Nick Payne nick.pa...@internode.on.net wrote: James Worlton wrote: Hi! In 2.13.6 I did a project and used: \set Score.markFormatter = #format-mark-box-alphabet and I got the boxes and the letter I (all in one command!) Thanks for that. That particular value for set (format-mark-box-alphabet) doesn't seem to appear anywhere in the documentation - or at least, I can't find it in the PDF documentation, which is what I use. This must be a bug in the documentation. Nick, could you figure out where it should go, and write a bit of text and a simple example, so we can add it to the docs? Well I only have/use the PDF documentation, and the section on Rehearsal marks is on p.74 of the 2.13.7 Notation reference. After the initial example, it presently says: That's a lot of orthogonal functionality. Maybe one should just make \set Score.markFormatter = #(format-mark-alphabet format-mark-box) work by letting format-mark-alphabet checking its argument, and if it is a function, create a closure from it that transforms the number properly? Being able to stack closures in that manner might be convenient in other cases as well. I'm sure that a patch that demonstrates this possibility would be examined. It may or may not be accepted, depending on how the development group feels about that particular syntax. If you are willing to write such a patch, or to have the discussion about the revised syntax, please start a new thread about it on -devel. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Mats Bengtsson mats.bengts...@ee.kth.se writes: Joe Neeman wrote: On Sat, 2009-11-21 at 22:45 +, Graham Percival wrote: On Sat, Nov 21, 2009 at 11:31:40PM +0100, David Kastrup wrote: I don't see a good rationale why \set, \override, \revert, \tweak should not work on the same set of properties (including subproperties). I don't see an explanation why it makes sense to differentiate between them. I can't speak to the programming side of things, but as an (ex-)user, documentation editor, and upcoming GLISS manager, I would *love* it if we could condense these commands into a single one. (wrapping the revert into something like \override Slur #'direction = #'revert although we'd probably want to choose a different \command to avoid confusion with the old syntax.) However, I'm not at all certain that this would be an easy (or even possible) change. It would certainly be possible, but I think it would be a bad idea. I think that having two separate commands is much clearer than having a command with two distinct behaviours depending on what its argument is. We used to have the same command for setting both context and object properties, see http://lilypond.org/doc/v2.2/Documentation/topdocs/out-www/NEWS.html I read The syntax for setting properties has been simplified: the following table lists the differences: (old) (new) \property A.B = #C\set A.B = #C \property A.B \unset \unset A.B \property A.B \set #C = #D\override A.B #C = #D \property A.B \override #C = #D (removed) \property A.B \revert #C \revert A.B #C There is no differentiation between context and object properties here. If you want to bring this issue up again, don't forget to read the discussions that lead to the current syntax. I am not complaining about the syntax: I find all of the commands introduced in the above news entry sensible and with a purpose of their own. What I don't get is why, apparently afterwards, it has been declared that one half of the commands is to be used only for one set of properties, and the other for the other. _That_ does not make sense to the user. Because the different semantics of those commands are not related at the user level to the different sets of properties that you _now_ are supposed to be using them for, respectively. And the difference apparently is hard enough to explain that I don't consider the information I have now sufficient. And we are talking about _user_ level commands here. I've been told that I am probably among the 10 top active experts with Lilypond syntax. While I refuse to believe this, there is enough substance to the statement that it is a bad idea if this evades my understanding. I have no doubt that in a few days of research I might get what led to that decision. And if I try to change the code accordingly, I'll likely run into problems. Technical problems. If those technical problems are completely unsurmountable also conceptually, then it means that the command names and concepts should be changed to reflect the fundamental differences in those properties. I don't believe this yet. I'll try finding pointers about past discussions, yes. But you can't expect every user to do the same. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
David Kastrup wrote:
We used to have the same command for setting both context and object
properties, see
http://lilypond.org/doc/v2.2/Documentation/topdocs/out-www/NEWS.html
I read
The syntax for setting properties has been simplified: the following
table lists the differences:
(old) (new)
\property A.B = #C\set A.B = #C
\property A.B \unset \unset A.B
\property A.B \set #C = #D\override A.B #C = #D
\property A.B \override #C = #D (removed)
\property A.B \revert #C \revert A.B #C
There is no differentiation between context and object properties
here.
Of course there is! The \property A.B = #C syntax was used for context
properties (called translation properties in the 2.0 documentation)
whereas the \property A.B {\set,\override} #C = #D was used for object
properties (called layout properties in the 2.0 documentation). See
for example
http://lilypond.org/doc/v2.0/Documentation/user/out-www/lilypond/Tuning-output.html#Tuning-output
which explicitly states that you should not confuse layout properties
with translation properties. In
http://lists.gnu.org/archive/html/lilypond-user/2003-10/msg00195.html
you can find an attempt I did at that time to introduce the different
kinds of properties and how to set them. I'm still missing this kind of
overview in the Learning manual, but haven't really had the time to
write it down.
I share your concerns that there's no clear-cut distinction between what
is handled by layout properties and and what's handled by context
properties, but it used to be much worse in old LilyPond versions, where
we had more context properties that de facto dealt with only one
particular layout object.
/Mats
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: mats.bengts...@ee.kth.se
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Mats Bengtsson mats.bengts...@ee.kth.se writes:
David Kastrup wrote:
We used to have the same command for setting both context and object
properties, see
http://lilypond.org/doc/v2.2/Documentation/topdocs/out-www/NEWS.html
I read
The syntax for setting properties has been simplified: the following
table lists the differences:
(old) (new)
\property A.B = #C\set A.B = #C
\property A.B \unset \unset A.B
\property A.B \set #C = #D\override A.B #C = #D
\property A.B \override #C = #D (removed)
\property A.B \revert #C \revert A.B #C
There is no differentiation between context and object
properties
here.
Of course there is! The \property A.B = #C syntax was used for context
properties (called translation properties in the 2.0 documentation)
whereas the \property A.B {\set,\override} #C = #D was used for object
properties (called layout properties in the 2.0 documentation). See
for example
http://lilypond.org/doc/v2.0/Documentation/user/out-www/lilypond/Tuning-output.html#Tuning-output
which explicitly states that you should not confuse layout properties
with translation properties.
Sigh. Sure. It tells
Do not confuse layout properties with translation
properties. Translation properties always use a mixed caps style
naming, and are manipulated using \property:
\property Context.propertyName = value
Layout properties are use Scheme style variable naming, i.e. lower
case words separated with dashes. They are symbols, and should
always be quoted using #'.
But that tells nothing about the actual difference. It just tells you
that they have different naming conventions and should be manipulated
using different commands.
But WHY?!?!?!?!?!
In
http://lists.gnu.org/archive/html/lilypond-user/2003-10/msg00195.html
you can find an attempt I did at that time to introduce the different
kinds of properties and how to set them.
Again, this lists different properties but does not mention at _all_ why
one would want to have different commands for setting different
properties.
I share your concerns that there's no clear-cut distinction between
what is handled by layout properties and and what's handled by context
properties, but it used to be much worse in old LilyPond versions,
where we had more context properties that de facto dealt with only one
particular layout object.
But why different commands for setting properties? I don't use
different commands for setting array values depending on what I am going
to use the array for. I don't use different commands for setting list
values depending on what I am going to use the list for.
Why for properties? The sort of oh, it works anyway if you ignore the
classification (perhaps with a warning), but that's being naughty.
What is the point behind enforcing some discipline that apparently does
not a have a coherent reason that could be explained in one or several
dozen sentences?
I don't get it. And the more answers I get that don't address my
question, the more suspicious I grow that there is no actual point.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup d...@gnu.org wrote: And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. I suggest to try to really understand the current design before you set out to modify it. While that may cost you some time, I am certain that it is less time than rewriting a lot of code and finding out it wont work afterwards. Sure. But it is my opinion that if the difference has technical/implementation reasons rather than being a logical, non-artificial distinction at user level, it may be better to _make_ it work. And if there is a logical, non-artificial distinction at user level, the docs need to get improved, and possibly better names be chosen that _reflect_ the logical distinction rather than implementation details. I am willing to work on either once I am convinced of one course. Right now I don't have the necessary clue level. Merely a gut hunch. Why dont you invest some time to find out how it really works, and then improve the documentation? That would help many more people than just you. Thanks, -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup d...@gnu.org wrote: Right now I don't have the necessary clue level. Merely a gut hunch. Why dont you invest some time to find out how it really works, What do you think I am doing? Reading documentation, getting nowhere, reading code, getting nowhere, asking on the list, getting pointed do documentation, getting nowhere... Seems like I need to find a capable investment banker for my time. My own choices of investment don't show promising returns. and then improve the documentation? That would help many more people than just you. I will not doctor the documentation before I consider myself having a clue. And I am nowhere near that yet. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Hi David,
David Kastrup wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup d...@gnu.org wrote:
Right now I don't have the necessary clue level. Merely a gut hunch.
Why dont you invest some time to find out how it really works,
What do you think I am doing? Reading documentation, getting nowhere,
reading code, getting nowhere, asking on the list, getting pointed do
documentation, getting nowhere...
Seems like I need to find a capable investment banker for my time. My
own choices of investment don't show promising returns.
and then improve the documentation? That would help many more people
than just you.
I will not doctor the documentation before I consider myself having a
clue. And I am nowhere near that yet.
From the bread-crumb trail of your posts on the various lists, it looks
like you're exploring a similar set of avenues I was going down earlier
this year.
I wanted to add some properties for things at either \book block level
or the implicit \book level (i.e. a file where a \score or \relative has
no enclosing \book block). I notice you have just posted some questions
re top-level on one of the other lists.
I was nearly able to add some score-level contexts for what I wanted to
do but as my properties related to the output file-names for generating
the back-end files it was felt contexts were not appropriate for the job.
I had a look at the context*.cc /.hh files and it looked like this was
the distinction
\set simply assigns a value to the property
\unset - clear any value previous value given to this property by a
prior \set.
\override - set the property to the new value and push the old value
onto an internal stack
\revert - pop any previously saved value from the internal stack and
assign it to the property
If there are bells and whistles depending on whether its a grob or a
music translation property being manipulated, maybe do something like
property-statement :==
'\' property-verb property-keyword property-set-or-unset-clause
property-verb :== 'set' | 'unset' | 'override' | 'revert'
propert-keyword :== 'grob' | 'music' (maybe choose better keywords)
property-set-or-unset-clause :==
property-specifier | property-specifier '=' property-value
so you'd get something like
\set music Autobeaming = #t or \set music Voice.Autobeaming = #t
\set music Staff.ADueText = \markup { \italic à 2}
\override grob Stem #'(details beamed-lengths) = #'(4 4 3)
\revert grob Stem #'(details beamed-lengths)
Anyhow, at this point by brain began to overheat with trying to juggle
too many new concepts at once and I decided to go for the simple
approach and do what I wanted using functions.
It looks like you're made of sterner stuff than me, so if you do keep at
it and get a handle on the concepts, let us know what you've worked out
on the Frogs list, please, so we can get all these bells and whistles
recorded in the documentation.
Cheers,
Ian Hulin
(a Frog - still swimming in the shallow end of the Lilypond)
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Ian Hulin i...@hulin.org.uk writes: David Kastrup wrote: I will not doctor the documentation before I consider myself having a clue. And I am nowhere near that yet. From the bread-crumb trail of your posts on the various lists, it looks like you're exploring a similar set of avenues I was going down earlier this year. Looks like developer time and resources can be saved by blocking those avenues. I had a look at the context*.cc /.hh files and it looked like this was the distinction \set simply assigns a value to the property \unset - clear any value previous value given to this property by a prior \set. \override - set the property to the new value and push the old value onto an internal stack \revert - pop any previously saved value from the internal stack and assign it to the property Yes, and the names and documentation reflect these functionalities quite well. What they don't reflect is why properties ending in grobs and context properties should be manipulated with different commands. Anyhow, at this point by brain began to overheat with trying to juggle too many new concepts at once and I decided to go for the simple approach and do what I wanted using functions. It looks like you're made of sterner stuff than me, so if you do keep at it and get a handle on the concepts, let us know what you've worked out on the Frogs list, please, so we can get all these bells and whistles recorded in the documentation. I hate bells and whistles, so at the moment I am more bent on obliterating rather than recording them. We'll see how much of that I find myself able to do. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Mon, Nov 23, 2009 at 12:55 PM, David Kastrup d...@gnu.org wrote: Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup d...@gnu.org wrote: Right now I don't have the necessary clue level. Merely a gut hunch. Why dont you invest some time to find out how it really works, What do you think I am doing? I think you send a lot of mail. I suggest reading code; if it were easy, where would the fun be? As a hint: * context properties are time-dependent, exist per Context, and have different values during the translation process (eg. the key signature, which is at staff level and changes if you change the keysig). * grob-properties are part of the formatting process, and are per graphic object. Formatting the score is computing the value of each grob property * grob properties have defaults (an alist, one per grob type), and those defaults are stored in a context property. see scm/define-grobs.scm * \override and \revert manipulate the defaults stored in said context property, pushing and popping values off the alist. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Nov 23, 2009 at 12:55 PM, David Kastrup d...@gnu.org wrote: Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup d...@gnu.org wrote: Right now I don't have the necessary clue level. Merely a gut hunch. Why dont you invest some time to find out how it really works, What do you think I am doing? I think you send a lot of mail. I suggest reading code; if it were easy, where would the fun be? I read the code. I read the documentation. I wrote stuff that worked in contradiction to the documentation. As a hint: * context properties are time-dependent, exist per Context, and have different values during the translation process (eg. the key signature, which is at staff level and changes if you change the keysig). * grob-properties are part of the formatting process, and are per graphic object. Formatting the score is computing the value of each grob property * grob properties have defaults (an alist, one per grob type), and those defaults are stored in a context property. see scm/define-grobs.scm * \override and \revert manipulate the defaults stored in said context property, pushing and popping values off the alist. This concise hint is wagonloads clearer than what is in the \set vs \override documentation node. The documentation can be strictly improved by throwing out what is there and putting this hint in. But while the hint addresses the difference and relation between those properties much much clearer than the manual, it still does not mention why one set of properties should only be manipulated with \set, and the other only with \override/\revert. It does not appear that there is an actual technical necessity for this, but rather it would appear that the basic nature of the different properties makes one or the other typically more feasible. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Mon, Nov 23, 2009 at 11:10 PM, David Kastrup d...@gnu.org wrote: * \override and \revert manipulate the defaults stored in said context property, pushing and popping values off the alist. This concise hint is wagonloads clearer than what is in the \set vs \override documentation node. The documentation can be strictly improved by throwing out what is there and putting this hint in. But while the hint addresses the difference and relation between those properties much much clearer than the manual, it still does not mention why one set of properties should only be manipulated with \set, and the other only with \override/\revert. It does not appear that there is an actual technical necessity for this, but rather it would appear that the basic nature of the different properties makes one or the other typically more feasible. \set overwrites the value of the context property. \override by its nature takes the value of the context property (an alist) and prepends a (symbol . value) pair. Since something different happens at runtime, it needs a different syntax. At some point we had \set Foo.Bar \override #'x = #y syntax for this, but it was deemed to confusing, so we gave it a different syntax. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On this subject of set vs override, if I want rehearsal marks to be
boxed letters and also want to use the letter I as a rehearsal mark, how
can I do that. Each set command overwrites the previous value of the
context property, so if I use:
\set Score.markFormatter = #format-mark-box-letters
\set Score.markFormatter = #format-mark-alphabet
then I get I as a rehearsal mark but the letters aren't boxed, and if
I use:
\set Score.markFormatter = #format-mark-alphabet
\set Score.markFormatter = #format-mark-box-letters
then I is skipped as a rehearsal mark. I suppose, to answer my own
question, I can keep count of the rehearsal marks and manually enter I
myself:
\relative c' {
\set Score.markFormatter = #format-mark-box-letters
c c c c \mark \default
c c c c \mark \default
c c c c \mark \default
c c c c \mark \default
c c c c \mark \default
c c c c \mark \default
c c c c \mark \default
c c c c \mark \default
c c c c \mark\markup { \box I }
c c c c \mark \default
c c c c \mark \default
}
Nick
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Hi! On Nov 23, 2009, at 9:26 PM, Nick Payne wrote: On this subject of set vs override, if I want rehearsal marks to be boxed letters and also want to use the letter I as a rehearsal mark, how can I do that. Each set command overwrites the previous value of the context property, so if I use: \set Score.markFormatter = #format-mark-box-letters \set Score.markFormatter = #format-mark-alphabet then I get I as a rehearsal mark but the letters aren't boxed, and if I use: \set Score.markFormatter = #format-mark-alphabet \set Score.markFormatter = #format-mark-box-letters In 2.13.6 I did a project and used: \set Score.markFormatter = #format-mark-box-alphabet and I got the boxes and the letter I (all in one command!) James Worlton ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Nov 23, 2009 at 11:10 PM, David Kastrup d...@gnu.org wrote: * \override and \revert manipulate the defaults stored in said context property, pushing and popping values off the alist. This concise hint is wagonloads clearer than what is in the \set vs \override documentation node. The documentation can be strictly improved by throwing out what is there and putting this hint in. But while the hint addresses the difference and relation between those properties much much clearer than the manual, it still does not mention why one set of properties should only be manipulated with \set, and the other only with \override/\revert. It does not appear that there is an actual technical necessity for this, but rather it would appear that the basic nature of the different properties makes one or the other typically more feasible. \set overwrites the value of the context property. \override by its nature takes the value of the context property (an alist) and prepends a (symbol . value) pair. Since something different happens at runtime, it needs a different syntax. Sigh. I guess I give up. Yes, I understood that. Pretty much from the get-go, and also from the manual. The unanswered question is _why_ you want only _one_ of the two different things happen to _one_ half of the properties, and the _other_ of the two different things happen to the _other_. At some point we had \set Foo.Bar \override #'x = #y syntax for this, but it was deemed to confusing, so we gave it a different syntax. I'm fine with the two different syntaxes for the two different actions. But why is one action only for context properties, the other only for grob properties (which are also pre-registered in the context)? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Joe Neeman joenee...@gmail.com writes: It would certainly be possible, but I think it would be a bad idea. I think that having two separate commands is much clearer than having a command with two distinct behaviours depending on what its argument is. If the things that happen are conceptually the same, it is easier to have commands that are conceptually the same. Even if they are just named \setgrob and \setcontext or so. But calling them \set and \override does not give the impression that they are used for different kinds of data, but for different kinds of action. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
We used to have the same command for setting both context and object properties, see http://lilypond.org/doc/v2.2/Documentation/topdocs/out-www/NEWS.html If you want to bring this issue up again, don't forget to read the discussions that lead to the current syntax. /Mats Joe Neeman wrote: On Sat, 2009-11-21 at 22:45 +, Graham Percival wrote: On Sat, Nov 21, 2009 at 11:31:40PM +0100, David Kastrup wrote: I don't see a good rationale why \set, \override, \revert, \tweak should not work on the same set of properties (including subproperties). I don't see an explanation why it makes sense to differentiate between them. And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. I can't speak to the programming side of things, but as an (ex-)user, documentation editor, and upcoming GLISS manager, I would *love* it if we could condense these commands into a single one. (wrapping the revert into something like \override Slur #'direction = #'revert although we'd probably want to choose a different \command to avoid confusion with the old syntax.) However, I'm not at all certain that this would be an easy (or even possible) change. It would certainly be possible, but I think it would be a bad idea. I think that having two separate commands is much clearer than having a command with two distinct behaviours depending on what its argument is. Cheers, Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing School of Electrical Engineering Royal Institute of Technology (KTH) SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: mats.bengts...@ee.kth.se WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Sat, Nov 21, 2009 at 8:31 PM, David Kastrup d...@gnu.org wrote: And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. I suggest to try to really understand the current design before you set out to modify it. While that may cost you some time, I am certain that it is less time than rewriting a lot of code and finding out it wont work afterwards. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Han-Wen Nienhuys hanw...@gmail.com writes: On Sat, Nov 21, 2009 at 8:31 PM, David Kastrup d...@gnu.org wrote: And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. I suggest to try to really understand the current design before you set out to modify it. While that may cost you some time, I am certain that it is less time than rewriting a lot of code and finding out it wont work afterwards. Sure. But it is my opinion that if the difference has technical/implementation reasons rather than being a logical, non-artificial distinction at user level, it may be better to _make_ it work. And if there is a logical, non-artificial distinction at user level, the docs need to get improved, and possibly better names be chosen that _reflect_ the logical distinction rather than implementation details. I am willing to work on either once I am convinced of one course. Right now I don't have the necessary clue level. Merely a gut hunch. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Sat, 2009-11-21 at 17:22 +0100, David Kastrup wrote: There is a chapter set vs override in the manual. I am afraid that I fail to grasp the difference from the chapter. It says: There are actually two different kinds of properties. But then it says Context properties can change value over time while interpreting a piece of music; `measurePosition' is an obvious example of this. Context properties are modified with `\set'. So far so good. There is a special type of context property: the element description. If the element description is a _special_ type of context property, that would imply that there is just _one_ different kind of properties. It completely fails to mention _what_ makes the element descriptions special and not settable with \set. These properties are named in `StudlyCaps' (starting with capital letters). They contain the `default settings' for said graphical object as an association list. See `scm/define-grobs.scm' to see what kind of settings there are. Element descriptions may be modified with `\override'. So why can't we use \set with element descriptions? And where is the difference to context properties changing values? After all, the principal purpose of \override is also to change the value, and \once\override very obviously changes behavior over time while interpreting music. Since \override works by modifying special context properties, you can actually use \set for setting grob properties. However, \override does some extra useful work: for a start, it appends new overrides to a list of overrides for a grob so that they can be easily reverted (\set just clobbers the existing variable). Also, \override supports nested properties (useful for things like 'bound-details). The type-checking mechanisms are also different for \override and \set. The implementation of \override is in context-property.cc, if you want to look at it. Cheers, Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
Joe Neeman joenee...@gmail.com writes: On Sat, 2009-11-21 at 17:22 +0100, David Kastrup wrote: There is a chapter set vs override in the manual. I am afraid that I fail to grasp the difference from the chapter. [...] If the element description is a _special_ type of context property, that would imply that there is just _one_ different kind of properties. It completely fails to mention _what_ makes the element descriptions special and not settable with \set. These properties are named in `StudlyCaps' (starting with capital letters). They contain the `default settings' for said graphical object as an association list. See `scm/define-grobs.scm' to see what kind of settings there are. Element descriptions may be modified with `\override'. So why can't we use \set with element descriptions? And where is the difference to context properties changing values? After all, the principal purpose of \override is also to change the value, and \once\override very obviously changes behavior over time while interpreting music. Since \override works by modifying special context properties, you can actually use \set for setting grob properties. However, \override does some extra useful work: for a start, it appends new overrides to a list of overrides for a grob so that they can be easily reverted (\set just clobbers the existing variable). Also, \override supports nested properties (useful for things like 'bound-details). The type-checking mechanisms are also different for \override and \set. You describe different semantics for \set and \override. Then you describe different restrictions. And then you say that they have different type-checking mechanisms. The problem is that the different type-checking mechanisms are there for the two different kinds of properties, but the whole thing appears completely arbitrary: it is not clear why you would want to permit one kind of command just with one set of properties, and the other with the other. I see no connection between the type of command you should use and the kind of properties that are affected. If you take a look at a recent proposal URL:http://codereview.appspot.com/152127/patch/1004/5, \tweak (another setter) is proposed to support nested properties. I don't see a good rationale why \set, \override, \revert, \tweak should not work on the same set of properties (including subproperties). I don't see an explanation why it makes sense to differentiate between them. And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Sat, Nov 21, 2009 at 11:31:40PM +0100, David Kastrup wrote: I don't see a good rationale why \set, \override, \revert, \tweak should not work on the same set of properties (including subproperties). I don't see an explanation why it makes sense to differentiate between them. And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. I can't speak to the programming side of things, but as an (ex-)user, documentation editor, and upcoming GLISS manager, I would *love* it if we could condense these commands into a single one. (wrapping the revert into something like \override Slur #'direction = #'revert although we'd probably want to choose a different \command to avoid confusion with the old syntax.) However, I'm not at all certain that this would be an easy (or even possible) change. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Sat, 2009-11-21 at 23:31 +0100, David Kastrup wrote: Joe Neeman joenee...@gmail.com writes: On Sat, 2009-11-21 at 17:22 +0100, David Kastrup wrote: There is a chapter set vs override in the manual. I am afraid that I fail to grasp the difference from the chapter. [...] If the element description is a _special_ type of context property, that would imply that there is just _one_ different kind of properties. It completely fails to mention _what_ makes the element descriptions special and not settable with \set. These properties are named in `StudlyCaps' (starting with capital letters). They contain the `default settings' for said graphical object as an association list. See `scm/define-grobs.scm' to see what kind of settings there are. Element descriptions may be modified with `\override'. So why can't we use \set with element descriptions? And where is the difference to context properties changing values? After all, the principal purpose of \override is also to change the value, and \once\override very obviously changes behavior over time while interpreting music. Since \override works by modifying special context properties, you can actually use \set for setting grob properties. However, \override does some extra useful work: for a start, it appends new overrides to a list of overrides for a grob so that they can be easily reverted (\set just clobbers the existing variable). Also, \override supports nested properties (useful for things like 'bound-details). The type-checking mechanisms are also different for \override and \set. You describe different semantics for \set and \override. Then you describe different restrictions. And then you say that they have different type-checking mechanisms. The problem is that the different type-checking mechanisms are there for the two different kinds of properties, but the whole thing appears completely arbitrary: it is not clear why you would want to permit one kind of command just with one set of properties, and the other with the other. I see no connection between the type of command you should use and the kind of properties that are affected. If you take a look at a recent proposal URL:http://codereview.appspot.com/152127/patch/1004/5, \tweak (another setter) is proposed to support nested properties. \tweak works on the same set of properties, more or less, as \override. I don't see a good rationale why \set, \override, \revert, \tweak should not work on the same set of properties (including subproperties). I don't see an explanation why it makes sense to differentiate between them. \override works on grob properties. \set works on context properties. They are distinguished by the fact that the properties belong to different objects with different purposes (contexts exist to create grobs; grobs are the graphical objects that are drawn in the end). In the _implementation_, \override sets a context property which tells the context that all future grobs should have those settings. So there is a little bit of overlap between the two notions, but there are also differences. For example, the beam-related context properties would not make sense as grob properties because they are needed in order to decide how many beams there should be, so once the beams have been created they aren't needed anymore. And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. I think you would have a lot of trouble abolishing them, since there are several grob properties that would not work as context properties and vice versa. Cheers, Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \set vs \override
On Sat, 2009-11-21 at 22:45 +, Graham Percival wrote: On Sat, Nov 21, 2009 at 11:31:40PM +0100, David Kastrup wrote: I don't see a good rationale why \set, \override, \revert, \tweak should not work on the same set of properties (including subproperties). I don't see an explanation why it makes sense to differentiate between them. And I am arrogant enough to believe that if I don't understand a design decision after a few days of trying, it is likely that ultimately a lot of people other than myself will be better off if the distinction gets abolished. I can't speak to the programming side of things, but as an (ex-)user, documentation editor, and upcoming GLISS manager, I would *love* it if we could condense these commands into a single one. (wrapping the revert into something like \override Slur #'direction = #'revert although we'd probably want to choose a different \command to avoid confusion with the old syntax.) However, I'm not at all certain that this would be an easy (or even possible) change. It would certainly be possible, but I think it would be a bad idea. I think that having two separate commands is much clearer than having a command with two distinct behaviours depending on what its argument is. Cheers, Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
On Thursday 04 May 2006 06:21, Arjan Bos wrote: Erik, That's a great document! I've read about half of it now and it does a very good job to explain to me how LilyPond works. And seeing the date on the title page, I think I have to congratulate you on your Masters Degree! Well Done! Thanks! Off topic, but are your music streams implemented in the current 2.9 branch? Working on it. From a structural point of view, it looks like a cleaner way of doing things. You might even add the syllables of lyrics to the music stream and do away with the current implementation. The implementation of lyricsto is one of the things that msuic streams happen to clean up; however, large parts of the current implementation are kept unchanged. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
Erik, That's a great document! I've read about half of it now and it does a very good job to explain to me how LilyPond works. And seeing the date on the title page, I think I have to congratulate you on your Masters Degree! Well Done! Off topic, but are your music streams implemented in the current 2.9 branch? From a structural point of view, it looks like a cleaner way of doing things. You might even add the syllables of lyrics to the music stream and do away with the current implementation. (Obviously, I've never looked hard at the lily source code, but as a data modeller, I like to see nice structured designs) Congrats, Arjan On 27 apr 2006, at 13:58, Erik Sandberg wrote: Citerar Tomas Valusek [EMAIL PROTECTED]: Hello, When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. Context - another topic of my interest. It seems to me I haven't understood them fully yet. I generally know what they are for, but the role of them is not fully clear to me. You can read my master thesis if you like, it tries to explain the context concept (the appendix music streams for the impatient might be a good choice if you're in a hurry) http://home.student.uu.se/ersa9195/report.pdf BTW: Graham, feel free to incorporate anything you like from the report into the manual. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user --- The shortest unit of time in the universe is the New York Second, defined as the period of time between the traffic lights turning green and the cab behind you honking. -- (Terry Pratchett, Lords and Ladies) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
grob is just a silly abbreviation for graphical object. On one hand, David is absolutely right that far too much of the implementation structure is visible in the user interface. On the other hand, unless the current approach to do settings in LilyPond is revised completely, each user who wants to do some changes to the default layout has to learn that properties are organized around the concept of graphical objects. /Mats Quoting David Feuer [EMAIL PROTECTED]: On 4/27/06, Rick Hansen (aka RickH) [EMAIL PROTECTED] wrote: Whats a grob? I agree. The user absolutely should not have to know that there is any such thing. David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Erik Sandberg wrote: Great! You now officially know more about this area than me, because I don't have a clue when to use \override or \set. Please take a few minutes to send me some clarifications or additions for the manual: http://lilypond.org/web/devel/participating/documentation-adding My simple understanding of it is that: \set sets a property for the whole context, and the objects contained in that context while \override is for a particular graphical object. Just a little explanation like that, that separates them would be good to have in the docs, or better yet, Eric's more thorough explanation below. Hm. Here's my understanding of it: You can say it's all about the granularity of the setting. \override manipulates settings which are specific to one graphical object/grob (e.g. a NoteHead). \set changes settings on a higher level, and can modify more than one type of grob. For example, fontSize is a context property (modified with \set) because it changes the behaviour of several different types of grobs (e.g., noteheads and rests). You can also change the fontsize of all noteheads only, by overriding a grob property of NoteHead grobs only. Or you can modify the fontsize of a single notehead using \tweak. You can notice that \set and \override use different syntaxes: \set ctx.prop = val \override ctx Grob.prop = val Rule of thumb is: If you can figure out a type of Grob that the tweak is specific to, then it's probably an \override. This rule requires a rough knowledge of which grob types that exist. The only way I know to get this knowledge is by reading the internals reference. Erik What is a \tweak? I can't recall reading about it in the manual. You say that you can modify the fontsize of a single notehead with \tweak. Would that give any difference than using a \once \override NoteHead #'font-size = size ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Quoting Michael Brennan [EMAIL PROTECTED]: My simple understanding of it is that: \set sets a property for the whole context, and the objects contained in that context while \override is for a particular graphical object. Just a little explanation like that, that separates them would be good to have in the docs, or better yet, Eric's more thorough explanation below. I'm afraid a simplified explanation like that might give the impression that the same properties can be set both for the context and for a particular graphical object, which of course is completely wrong. Also, \override by default sets a property for a particular type of object within the current context, so the concept of contexts is important also for \override. What is a \tweak? I can't recall reading about it in the manual. You say that you can modify the fontsize of a single notehead with \tweak. Would that give any difference than using a \once \override NoteHead #'font-size = size See the NEWS in the documentation for version 2.8. The information from the NEWS file is in the process of being incorporated into the manual. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
On 26-Apr-06, at 10:36 PM, Michael Brennan wrote: David Feuer wrote: On 4/19/06, Erik Sandberg [EMAIL PROTECTED] wrote: In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. Actually it helps me, as a new user. When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. Great! You now officially know more about this area than me, because I don't have a clue when to use \override or \set. Please take a few minutes to send me some clarifications or additions for the manual: http://lilypond.org/web/devel/participating/documentation-adding Cheers, - Graham Percival, LilyPond Documentation Editor ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
Hi, I too find the context/grob property distinction not clear and I did not find the online doc any help in getting through this barrier of understanding. It is the one most powerful aspect of Lilypond, but the one aspect which is treated the most meanly in the introductory docs. Even user doing basic stuff need to get into settings and stuff when changing default behaviour so I think it should be touched on earlier in the documentation. If the tutorial could be beefed up somewhat in this area, I think there would be far fewer questions regarding how to find tweaks and settings through the advanced doc, given that users would be armed with this important information beforehand. Wish I had the time to do it myself but sadly I do not :( Good luck to whoever gets the job ;) Regards, Ralph TRIBAL TECHNOLOGY IS A MEMBER OF THE TRIBAL GROUP plc www.tribalgroup.co.uk This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Access, copying, dissemination or re-use of information in it by anyone else is unauthorised. If you have received this message in error, please contact the sender as soon as possible. This message has been scanned for viruses by Viatel MailControl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
For some time, I have been thinking about adding an introductory text to the Changing Defaults chapter, which introduces all the main methods to set context and grob properties with one example for each and links to the more detailed sections. This would be something along the lines of http://lists.gnu.org/archive/html/lilypond-user/2003-10/msg00195.html (which of course is outdated now). My idea was that this should be placed as an introductory section of the Changing Defaults chapter and I think that there is place for some similar introductions also in other parts of the reference manual. For example, we could have a short introduction summarizing text scripts, text marks and markup. Now there is one section on each and it's really hard to get the whole picture. Of course, an alternative is to add these introductory texts in the tutorial, but then many people who think that they have passed the tutorial stage will never find it. The target group here is not the beginner but the somewhat experienced user (as most of us are). /Mats Ralph Little wrote: Hi, I too find the context/grob property distinction not clear and I did not find the online doc any help in getting through this barrier of understanding. It is the one most powerful aspect of Lilypond, but the one aspect which is treated the most meanly in the introductory docs. Even user doing basic stuff need to get into settings and stuff when changing default behaviour so I think it should be touched on earlier in the documentation. If the tutorial could be beefed up somewhat in this area, I think there would be far fewer questions regarding how to find tweaks and settings through the advanced doc, given that users would be armed with this important information beforehand. Wish I had the time to do it myself but sadly I do not :( Good luck to whoever gets the job ;) Regards, Ralph TRIBAL TECHNOLOGY IS A MEMBER OF THE TRIBAL GROUP plc www.tribalgroup.co.uk This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Access, copying, dissemination or re-use of information in it by anyone else is unauthorised. If you have received this message in error, please contact the sender as soon as possible. This message has been scanned for viruses by Viatel MailControl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
On 27-Apr-06, at 2:20 AM, Mats Bengtsson wrote: For some time, I have been thinking about adding an introductory text to the Changing Defaults chapter, which introduces all the main methods to set context and grob properties with one example for each and links to the more detailed sections. Wait until I've finished the doc reorg (probably next week). - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
Citerar Tomas Valusek [EMAIL PROTECTED]: Hello, When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. Context - another topic of my interest. It seems to me I haven't understood them fully yet. I generally know what they are for, but the role of them is not fully clear to me. You can read my master thesis if you like, it tries to explain the context concept (the appendix music streams for the impatient might be a good choice if you're in a hurry) http://home.student.uu.se/ersa9195/report.pdf BTW: Graham, feel free to incorporate anything you like from the report into the manual. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Citerar Graham Percival [EMAIL PROTECTED]: On 26-Apr-06, at 10:36 PM, Michael Brennan wrote: David Feuer wrote: On 4/19/06, Erik Sandberg [EMAIL PROTECTED] wrote: In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. Actually it helps me, as a new user. When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. Great! You now officially know more about this area than me, because I don't have a clue when to use \override or \set. Please take a few minutes to send me some clarifications or additions for the manual: http://lilypond.org/web/devel/participating/documentation-adding Hm. Here's my understanding of it: You can say it's all about the granularity of the setting. \override manipulates settings which are specific to one graphical object/grob (e.g. a NoteHead). \set changes settings on a higher level, and can modify more than one type of grob. For example, fontSize is a context property (modified with \set) because it changes the behaviour of several different types of grobs (e.g., noteheads and rests). You can also change the fontsize of all noteheads only, by overriding a grob property of NoteHead grobs only. Or you can modify the fontsize of a single notehead using \tweak. You can notice that \set and \override use different syntaxes: \set ctx.prop = val \override ctx Grob.prop = val Rule of thumb is: If you can figure out a type of Grob that the tweak is specific to, then it's probably an \override. This rule requires a rough knowledge of which grob types that exist. The only way I know to get this knowledge is by reading the internals reference. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Whats a grob? -- View this message in context: http://www.nabble.com/Set-vs.-Override---I%27m-confused-t1433228.html#a4124826 Sent from the Gnu - Lilypond - User forum at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
On 4/27/06, Rick Hansen (aka RickH) [EMAIL PROTECTED] wrote: Whats a grob? I agree. The user absolutely should not have to know that there is any such thing. David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Hm. Here's my understanding of it: You can say it's all about the granularity of the setting. \override manipulates settings which are specific to one graphical object/grob (e.g. a NoteHead). \set changes settings on a higher level, and can modify more than one type of grob. There is at least one other distinction -- since context properties take effect during the interpretation step, they can affect which grobs are created. \set tupletSpannerDuration, for example couldn't be a grob property because it doesn't change the grobs. Instead it tells the engraver how many grobs to create and where. Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
On Tuesday 11 April 2006 23:56, Werner LEMBERG wrote: \set: set the value of a context property \override: set the value of a layout object property I've always wondered why it isn't possible to unify them... In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
On 4/19/06, Erik Sandberg [EMAIL PROTECTED] wrote: In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. Might, but doesn't. David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. Might, but doesn't. Hehe, I second this. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. Might, but doesn't. I have to agree. It seems an arbitrary distinction. Geoff ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
David Feuer wrote: On 4/19/06, Erik Sandberg [EMAIL PROTECTED] wrote: In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. Might, but doesn't. David Actually it helps me, as a new user. When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. /Michael ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
[...] when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. A big help would be a simple means to distinguish grobs and context properties. For example, context property names could always start with `c-', whereas grob properties don't have this prefix. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Contexts (Was Re: Set vs. Override - I'm confused)
Hello, When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. Context - another topic of my interest. It seems to me I haven't understood them fully yet. I generally know what they are for, but the role of them is not fully clear to me. Tomas Valusek ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Werner LEMBERG writes: \set: set the value of a context property \override: set the value of a layout object property I've always wondered why it isn't possible to unify them... Or until that time have explicit naming. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
\set: set the value of a context property \override: set the value of a layout object property The followup question is obvious, but I leave it to you to think about it and see if you get any further. /Mats Tomas Valusek wrote: Hello, I've read thoroughly LilyPond's Users Manual and I don't understand what's the difference between \set and \override commands. Can someone explain me this? Thank you. Tomas Valusek ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
The followup question is obvious, but I leave it to you to think about it and see if you get any further. I've been wondering for some time if the distinction is a helpful one, but I suspect changing it now would involve too much internal tinkering, not to mention breaking of old scores. Geoff ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Quoting Geoff Horton [EMAIL PROTECTED]: The followup question is obvious, but I leave it to you to think about it and see if you get any further. I've been wondering for some time if the distinction is a helpful one, but I suspect changing it now would involve too much internal tinkering, not to mention breaking of old scores. Geoff Actually, it used to be the same command for setting both types of properties, which did cause quite some confusion. However, the distinction between the two kinds of properties is often fairly arbitrary and many properties that earlier were context properties have now been converted to object properties (and probably the other way around as well). /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
\set: set the value of a context property \override: set the value of a layout object property I've always wondered why it isn't possible to unify them... Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
