On Fri, 2006-06-02 at 11:12 -0400, Kieren MacMillan wrote:
> Hi, Han-Wen --
>
> > I think it should work to define a context TimeSignatureContext that'
> > contains only Time_signature_engraver and Axis_group_engraver.
>
> If I understand what you're suggesting, this is exactly what the docs
> trick/example does (see <http://lilypond.org/doc/v2.9/input/test/
> lily-517782458.ly>).
>
> Unfortunately, there are two irritations that I've run into that I'm
> trying to solve (in a score I'm currently engraving, but I'm sure
> I'll run into it again):
>
> 1. The *content* of the TimeSig needs to be explicitly defined (using
> skipped notes, etc.) -- it would be better if the TimeSig staff just
> "did the right thing". [A minor irritation, I admit!]
>
> 2. The TimeSig staff cannot be "synchronized" with one of the other
> staves
This could be a cool feature -- a way to synchronize two contexts
(warning: half-baked idea ahead). It could work like
<<
\new Staff {a16 b c \receive "EndOfCadenza" d4 e f}
\new Staff {a4 b c d e f g a b c d d \send "EndOfCandenza" d4 e f}
>>
and the first staff will automatically have spacer rests inserted so
that the "d4 e f" lines up. You could apply it to your problem like this
\new PianoStaff {
<<
\new TimeSig {\receive "EndOfPiece"}
\new Staff {\rightHand \send "EndOfPiece"}
\new Staff {\leftHand}
>>
}
thereby solving the "counting out spacer rests" problem.
(btw, putting the TimeSig context inside the PianoStaff instead of the
GrandStaff should solve the "hanging TimeSig context" problem)
I imagine this would be handy for entering lyrics as well, when there is
a long instrumental interlude that you don't want to bother counting the
duration of.
> -- e.g., if you have [pseudocode]
>
> TimeSig
> Staff "fl"
> Staff "ob"
> ...
> TimeSig
> PianoStaff
> Staff "pianoUpper"
> Staff "pianoLower"
>
> then when you French the score, the systems that have no piano music
> still have the "extra" TimeSig staff hanging off the bottom of the
> system -- not very attractive! [This is the principal irritation, and
> the one that made me come up with my hack in the first place...]
>
> Does the approach you're thinking of overcome these two obstacles in
> a way the doc trick/example doesn't (or at least that I don't know
> how to overcome by simply extending the doc trick/example)?
>
> Thanks!
> Kieren.
>
>
> _______________________________________________
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
