On Wed, Dec 02, 2009 at 03:41:06PM -0700, Carl Sorensen wrote:
>
> On 12/2/09 2:58 PM, "Mats Bengtsson" wrote:
>
> >> Because it's too many things to list in the body of the NR. We try to keep
> >> the body of the NR as short as feasible, and put exhaustive lists in the
> >> appendices.
> >>
On 12/2/09 2:58 PM, "Mats Bengtsson" wrote:
> Carl Sorensen wrote:
>>
>> On 12/2/09 1:40 PM, "Mats Bengtsson" wrote:
>>
>>
>>> Why not simply extend the current example so that it shows all the
>>> possibilities? No need to explain in words, especially since the names
>>> are more or less
Carl Sorensen wrote:
On 12/2/09 1:40 PM, "Mats Bengtsson" wrote:
Why not simply extend the current example so that it shows all the
possibilities? No need to explain in words, especially since the names
are more or less self-explanatory.
Because it's too many things to list in the b
On 12/2/09 1:40 PM, "Mats Bengtsson" wrote:
> Why not simply extend the current example so that it shows all the
> possibilities? No need to explain in words, especially since the names
> are more or less self-explanatory.
Because it's too many things to list in the body of the NR. We try to
Why not simply extend the current example so that it shows all the
possibilities? No need to explain in words, especially since the names
are more or less self-explanatory.
/Mats
Valentin Villenave wrote:
On Wed, Dec 2, 2009 at 5:38 PM, Carl Sorensen wrote:
Doing this right probably
On Wed, Dec 2, 2009 at 5:38 PM, Carl Sorensen wrote:
> Doing this right probably means a careful explanation of a few of these in
> the NR, and an appendix showing all of the possibilities.
I was about to suggest something like that, but aren't appendices
automatically generated? How would you im
On 12/2/09 2:47 AM, "Valentin Villenave" wrote:
> On Wed, Dec 2, 2009 at 9:04 AM, Mats Bengtsson
> wrote:
>> Running the command "grep format-mark- scm/translation-functions.scm" in
>> Linux gives the following list of functions:
>>
>> (define-public (format-mark-alphabet mark context)
>> (d
On Wed, Dec 2, 2009 at 9:04 AM, Mats Bengtsson wrote:
> Running the command "grep format-mark- scm/translation-functions.scm" in
> Linux gives the following list of functions:
>
> (define-public (format-mark-alphabet mark context)
> (define-public (format-mark-box-alphabet mark context)
> (define-
Anthony W. Youngman wrote:
\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
In message <4b0bc390.1080...@internode.on.net>, Nick Payne
writes
Carl Sorensen wrote:
On 11/24/09 2:57 AM, "Nick Payne" 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
On 11/24/09 4:56 AM, "David Kastrup" wrote:
> Nick Payne writes:
>
>> Carl Sorensen wrote:
>>>
>>> On 11/24/09 2:57 AM, "Nick Payne" wrote:
>>>
James Worlton wrote:
> Hi!
>
>
> In 2.13.6 I did a project and used:
> \set Score.markFormatter = #format-ma
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, w
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 wrote:
> Han-Wen Nienhuys writes:
>
>> On Tue, No
Han-Wen Nienhuys writes:
> On Tue, Nov 24, 2009 at 3:50 AM, David Kastrup 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_
On Tue, Nov 24, 2009 at 3:50 AM, David Kastrup 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 th
Nick Payne writes:
> Carl Sorensen wrote:
>>
>> On 11/24/09 2:57 AM, "Nick Payne" 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
Carl Sorensen wrote:
On 11/24/09 2:57 AM, "Nick Payne" 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
On 11/24/09 2:57 AM, "Nick Payne" 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
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
2009/11/24 Han-Wen Nienhuys :
> 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 hi
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 11:10 PM, David Kastrup wrote:
>
>>>
>>> * \override and \revert manipulate the defaults stored in said context
>>> property, pushing and popping values off the alist.
>>
>> This concise "hint&q
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
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
On Mon, Nov 23, 2009 at 11:10 PM, David Kastrup 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 "
ntext 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" document
On Mon, Nov 23, 2009 at 12:55 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup 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
Ian Hulin 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 d
Hi David,
David Kastrup wrote:
Han-Wen Nienhuys writes:
On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup 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 docume
Han-Wen Nienhuys writes:
> On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup 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,
r
On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup 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.
>>
Mats Bengtsson 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 simplif
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 difference
Mats Bengtsson 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
Han-Wen Nienhuys writes:
> On Sat, Nov 21, 2009 at 8:31 PM, David Kastrup 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 dis
On Sat, Nov 21, 2009 at 8:31 PM, David Kastrup 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 sugges
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:
Joe Neeman 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 i
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 explanati
On Sat, 2009-11-21 at 23:31 +0100, David Kastrup wrote:
> Joe Neeman 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 d
Graham Percival writes:
> 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 differenti
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
Joe Neeman 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 _speci
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."
>
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
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!
Th
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
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
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
"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
wan
> 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
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/mailma
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
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 fo
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,
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.
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://list
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 b
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 propertie
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.
> [...] 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
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 migh
> > 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 properti
> > 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 properti
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
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,
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 - Th
> \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/mailma
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, no
> 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.
Geof
\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'
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:/
71 matches
Mail list logo
