lilypond-devel
[Top][All Lists]
Advanced

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

Re: \change Voice


From: David Kastrup
Subject: Re: \change Voice
Date: Thu, 30 Apr 2015 09:16:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Dan Eble <address@hidden> writes:

> On Apr 26, 2015, at 16:04 , David Kastrup <address@hidden> wrote:
>> 
>> "Keith OHara" <address@hidden> writes:
>> 
>>> The wrapping context, though, means that we have to explicitly
>>> specify Voice in any overrides that should carry through to the
>>> combined part
>>> \partcombine { c'4 d'4 } {\slurDashed g'4( b') }
>>> \partcombine { c'4 d'4 } {\override Voice.Slur.dash-definition =
>>> #'((0 1 0.4 0.75)) g'4( b') }
>> 
>> Huh.  I changed the definition of "Bottom" context at one time to one
>> that does not have a \defaultchild rather than one that does not have an
>> actual child.  So I'd expect a Bottom override to arrive in a Voice when
>> emitted in a SubVoice that is accepted by Voice as long as Voice still
>> has no \defaultchild.
>
> SubVoice has no \defaultchild, therefore SubVoice is "a" Bottom
> context, right?

Correct.

>> But that does not happen.  One could argue that this may be a bug,
>> and that every context in the current parentage that considers itself
>> "Bottom" should be affected by Bottom overrides.
>
> The idea of multiple Bottoms in a hierarchy is bizarre.

I am not interested in bizarre or not.  The question is whether it is
consistent and/or useful.  "Bottom" is just a name, and its principal
implication is "no implicit context creation beyond this point".  Now
what is useful?

Moving a subbottom context back and forth between several bottom
contexts should likely not vacuum off overrides that would otherwise
arrive (and apparently that happens currently).  I'd rather have them
arrive properly.  So the question is more whether we let Bottom
overrides also apply to "sub-bottom" contexts, namely contexts that have
a "Bottom" context _somewhere_ in the hierarchy above them.

> It sounds like there are multiple concepts in need of distinction.
> (presence of default child v. actual child; navigation from top down
> to create default contexts v. bottom up to set properties; ...?)

Well, the fewer concepts come into play while still providing _useful_
semantics (some theoretical feeling of correctness is nice but not the
ultimate arbiter), the better we are off.

-- 
David Kastrup



reply via email to

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