Re: Learning Lilypond, comments invited - part 2

[David Kastrup]

Colin Tennyson <address@hidden> writes:

> I'm creating a new thread because the previous one has become somewhat
> cluttered.
>
> My template is much better now, thank you for your suggestions.
>
> As emphasized by David Kastrup, the keyword \new instructs Lilypond to
> create a new instance of a class. 
> \new StaffGroup creates an instance of the StaffGroup object.

When you blindly exchange words and terms to the names of concepts of
which you have an understanding, that does not mean that stuff will
magically start behaving according to those concepts.  And it does not
facilitate communication.

> In this template several properties of the Score class are modified, such
> as:     
> \hide Score.SystemStartBracket
> \override Score.BarNumber.font-size = #1.5
>
> I surmise that the StaffGroup object inherits from the Score object,
> similar to inheritence in object oriented programming.

See, now you've muddled up your terminology to a degree where it does
not make any sense.

You call contexts "objects", but those don't inherit anything, and most
certainly not in the sense of object oriented programming.  In OOP, you
have a _type_ hierarchy based on inheritance.

However, the parent relationship of contexts is not a type hierarchy:
every context is created from its context description and _nothing_
else.

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).

> One thing remains: the property "forbid_line_break_engraver" is a property
> of the element Voice

No, it isn't.  Your use of "property" and "element" does not make any
sense.

> 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.

So do it in the layout definition.

> For the other properties I was able to use a dot notation access. Examples:
> \hide Score.SystemStartBracket
> \override Staff.InstrumentName.self-alignment-X = #RIGHT    
>
> The accessor \context allows the property to be set centrally:
> \context { \Voice \remove "Forbid_line_break_engraver" }

Again, you are wildly throwing terms around that have no sensible
relation or meaning.  \context is no "accessor".  It is a reserved word
that will, inside of a layout definition, start a context definition.

> But is just a side effect? Is \context meant for something else entirely?
> Can the property "forbid_line_break_engraver" also be accessed using a dot
> notation? 

I don't understand what you are trying to talk about.

-- 
David Kastrup