Re: Weird intermediate context creation

[David Kastrup]

Dan Eble <address@hidden> writes:

> On Jan 6, 2020, at 10:57, David Kastrup <address@hidden> wrote:
>>> the current result is strange
>> 
>> Can you explain why you feel that?
>
> I find it strange that this music produces these diverse results:
>
> music = << c' e' >>
>
> \new Score { % Case A: two notes in one voice
>   \new Voice \music
> }
>
> \new Score { % Case B: two voices in one staff
>   \new Staff \music
> }
>
> \new Score { % Case C: two staves
>   \new StaffGroup \music
> }
>
> \new Score { % Case D: two staves
>   \music
> }
>
> With my experimental changes, cases B, C, and D are rendered as two
> voices in one staff.  They are not rendered like case A (I believe)
> because I haven't touched the code that makes LilyPond create a new
> bottom context per item in \music.

At the current point of time, << ... >> is the way to create music that
will not cause a prioritised context to stick around indefinitely.

>> Implicit context creation is not going away.  Things like Global and
>> Score context are created implicitly all the time.
>
> I don't propose eliminating it.  Actually, I'm experimenting with
> generalizing some special handling of Score.  When LilyPond creates
> the implied intermediate contexts required for a new context, the
> current behavior is to avoid creating a new Score context if one
> already exists.  The question I asked myself is "What if LilyPond did
> the same for other intermediate contexts?"  Then I tried it and
> discovered the impact on the bend-bound test and some others.
>
>> If I write
>> 
>> << \new Staff { c' } \new Voice { d' } >>
>> 
>> should the d' insinuate itself into the same staff as the c' ?
>
> You didn't specify a staff for the d', so I don't see grounds for
> dissatisfaction if LilyPond were to do that.

It's the same as

<< \new StaffGroup { c' } \new Staff { d' } >>

where it clearly seems inappropriate to make the Staff be a part of the
StaffGroup .  I also suspect that your changes might take issue 34 to a
new level.  Not more than a hunch but this is not a simple area without
consequences and repercussions.

There's been some definition of the \after music function around and its
latest iterations contained an "artificial" simultaneous music
expression for "reasons", namely avoiding a persistent context like
described above.

> Having said that, my work in progress produces the same output as
> master for this case, so it might not be something we need to debate.
> I don't understand why yet, and I ought to, so thanks for this case.

-- 
David Kastrup