lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Learning Lilypond, comments invited - part 2


From: Kieren MacMillan
Subject: Re: Learning Lilypond, comments invited - part 2
Date: Fri, 3 Jan 2014 10:38:11 -0500

Hi Colin,

I will try to answer in a way that helps you.

> the keyword \new instructs Lilypond to create a new instance of a class. 

You clearly come from a programming background, which will help you scale the 
Lilypond learning curve in some ways.
However, don’t push that analogy too far, or you might find (as I did) that it 
can confuse matters.  =)

> \new StaffGroup creates an instance of the StaffGroup object.

In the way you’re thinking, \new StaffGroup does indeed “create” a new context 
("instance of an object”) which matches the StaffGroup definition.

> I surmise that the StaffGroup object inherits from the Score object, similar 
> to inheritence in object oriented programming.

Here, David does [with my judicious editing ;)] do a good job of explaining the 
situation:

> the parent relationship of contexts is not a type hierarchy:
> every context is created from its context description […]
> the parent relationship comes into play if we are looking at _properties_:
> when looking up a property (context/grob), looking up in some context
> a property that is not defined will instead get looked up
> in the parent context.
> 
> The parent relationship is only established when a context is created.
> While some guidelines are in the context definition (namely the types of
> subcontexts that would be acceptable, and a default type to create and
> delegate the subcontext creation to in case a context of the given type
> can' be found or created otherwise).

Is anything in there unclear?

> the property "forbid_line_break_engraver" is a property of the element Voice

More accurately, the Voice context, as defined by default, includes the 
forbid_line_break_engraver.

> If possible I want to avoid repeating commands. I don't want to put in the
> \remove "forbid_line_break_engraver" four times, for every voice in the score.

Correct — you can simply “redefine” or “extend” the definition of voice:

\layout {
  \context {
    \Voice
    \remove "forbid_line_break_engraver"
  }
}

Now, in any scores which use that layout definition, \new Voice [or \context 
Voice] will give you a Voice context [“instance”] which does not include the 
forbid_line_break_engraver.

> The accessor \context allows the property to be set centrally:
> \context { \Voice \remove "Forbid_line_break_engraver” }

The **reserved word** \context can indeed be used to add or remove an engraver 
in an abstracted (“central”) way.

> But is just a side effect? Is \context meant for something else entirely?

To the user’s eye, \context does two different things when used in two 
different places:
1. Inside a \layout definition, it starts the definition of a context.
2. Inside a score, it will look for an existing “instance” (by name) and create 
a new one (if not found).

Perhaps this is what you’re referring to?

> Can the property "forbid_line_break_engraver" also be accessed using a dot 
> notation? 

Not that I’m aware of: engravers can only be added (\consists) or removed 
(\remove) in a context definition.
There is no mechanism (e.g.) “Voice.forbid_line_break_engraver.foo”.

Hope this helps!
Kieren.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]