Re: Inheritance of MIDI settings into embedded contexts?

[Maurits Lamers]

Hi,

It might be here that the Lilypond syntax leads you up the proverbial garden 
path.
While voices are contexts within the scope of a staff, they are not nested 
within each other.
So, whenever a new voice is created, it is created equal to the other voices 
and consequently has only the Staff as a parent context.

Musically it makes a lot of sense to have the Dynamic_performer in the Voice 
context by default: most polyphonic uses of the Voice context are related to 
having two instruments or voices/vocals on a single staff, where each has their 
own dynamic signs. Only in keyboard music both voices will be performed by one 
performer and consequently most of the dynamics should be "inherited". In that 
case, it is more logical to move the Dynamic performer to the Staff context.

cheers

Maurits



> Op 22 aug. 2020, om 23:46 heeft Dr. Thomas Tensi <t.tensi@gmx.de> het 
> volgende geschreven:
> 
> Hello Aaron,
> 
> 
> thanks for the quick and detailed answer!
> 
> You wrote:
> > The Dynamic_performer is part of the Voice context; and the
> > construct << ... \\ ... >> implicitly creates new Voice contexts.
> 
> That is what I had assumed: the voice context _initializes_ its dynamics
> to the default value regardless of any outer contexts (that have no
> dynamic performer, by the way).
> 
> > [...]
> > \consisting the Dynamic_performer to the Staff (and \removing it
> > from the Voice) should apply the current logic to the wider scope
> 
> This sounds logical.
> 
> But what I do not get is why the contexts do not nest. A staff should
> have a dynamic performer that is _inherited_ by explicit and implicit
> voices within that staff.  The settings from the outer (staff) context
> are taken over unless the inner context (voice) changes some setting.
> The scope of this change is, of course, the inner context.
> 
> The same logic applies to variables in scoped programming languages:
> inner definitions shadow outer definitions, but if there is no inner
> definition, the outer definition is visible.
> 
> Hence: in my opinion the dynamics should be a setting that may be
> overridden in embedded contexts; if not, it retains the outer setting.
> 
> 
>       Best regards,
> 
>               Thomas
>