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. I don't want to force
people have to specify a context where now they can just write \slurDashed, but
I still want to make the part-combine-iterator less of a nexus. Trying to turn
the input parts into segments of context-specific music as Keith suggested
would probably end in frustration.
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.
Regards,
—
Dan
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
