lilypond-devel
[Top][All Lists]
Advanced

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

Re: \change Voice


From: Dan Eble
Subject: Re: \change Voice
Date: Sun, 3 May 2015 15:24:27 -0400

On Apr 30, 2015, at 08:26 , David Kastrup <address@hidden> wrote:
> 
> Dan Eble <address@hidden> 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




reply via email to

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