Dan Eble <d...@faithful.be> writes:
> On Apr 30, 2015, at 08:26 , David Kastrup <d...@gnu.org> wrote:
>>
>> Dan Eble <d...@faithful.be> writes:
>>
>>> What if we defined \override Grob.property as addressing the nearest
>>> enclosing context named “”, and aliased all contexts except
>>> part/sub-voice to “”. (Maybe I’ll try that tonight and see what
>>> happens.)
>>
>> That sounds like a recipe for disaster in connection with implicit
>> context creation since an \override does _not_ create implicit contexts
>> _unless_ it is needed for the override to succeed.
>>
>> So if you do things like
>> \new Staff { \voiceOne c d \oneVoice ...
>> then \oneVoice will no longer be able to cancel \voiceOne (with respect
>> to other voices) since \voiceOne will have registered at Staff level.
>> So a \new Voice { ... } will still be under the influence of \voiceOne.
>
> Thanks to both of you for your feedback. These are my current
> thoughts on \partcombine.
>
> Adding a wrapper context will have undesirable effects.
The question is what requirements or mechanisms we could employ in order
to remove the undesirable effects.
For example, it could be possible to define a special translator for
subcontexts that diverts (all? all but specified?) overrides to the
parent context. Or generally let "Bottom" overrides register at the
"topmost" "Bottom".
If a wrapper context would be a good tool except for "undesirable
effects", addressing those seems like a good idea, probably not just for
this application.
> I think I will experiment with a smaller step. I will try to make
> part-combine-iterator route events using one list of outlet-change
> instructions per part instead of a single split-list that ties the two
> parts together. The outlet-change instructions would still be
> separate from the music as the split-list is now. Turning the
> split-list into per-part lists would be done in scheme, thereby
> lowering the bar for experimentation and future improvements.
The part combiner is nowhere near where I consider it a smooth and
elegant tool in the box. There is a lot of room for experimentation but
also frustration and dead ends. Most current ways (or extensions) for
adapting its behavior to particular tasks are quite dissatisfactory all
with regard to the actions required by the user, with regard to the
mechanisms employed for implementing it, and somewhat related, with the
consistency and predictability of the results.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
