Re: RFC: new vertical layout engine

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 16. Juni 2009 11:52:09 schrieb Joe Neeman:
> On Mon, Jun 15, 2009 at 9:05 PM, Reinhold Kainhofer
> > - -) Being able to set stretching factors on a StaffGroup-level. In
> > particular,
> > for full scores there are staff groups for woodwind, brass, vocal voices,
> > strings etc. When the whole system is stretched vertically, there is more
> > space in printed scores between the groups than between the staves inside
> > the
> > individual groups (i.e. the instrumental staff groups use a different
> > spring
> > constant than the staff group for the whole system). See e.g. a modern
> > Bärenreiter edition:
> >
> > http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Schuber
> >t_StabatMater_0050.pdf<http://www.fam.tuwien.ac.at/%7Ereinhold/LilyPond/Ve
> >rticalStretching/Schubert_StabatMater_0050.pdf> Current bad lilypond
> > results (with huge stretching) are:
> >
> > http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretch
> >ing_oly_largestretch.pdf<http://www.fam.tuwien.ac.at/%7Ereinhold/LilyPond/
> >VerticalStretching/stretching_oly_largestretch.pdf>
> >
> > This is really necessary for full scores for the conductor to get a quick
> > overview over the instrument groups. In particular, look at the
> > stretching_oly_vocalstaves.pdf file (current results with lilypond!),
> > hide the
> > group brackets at the left and try to guess which staves belong
> > together... Sample file (with hardly any stretching):
> >
> > http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretch
> >ing_oly_vocalstaves.pdf<http://www.fam.tuwien.ac.at/%7Ereinhold/LilyPond/V
> >erticalStretching/stretching_oly_vocalstaves.pdf>
> >
> > You would never guess which staves belong together..
>
> This will certainly the possible in the layout code, but I don't see how to
> make it nicely accessible through properties. Currently, the information
> about staff groups doesn't make it as far as the backend. 

Then that's the main problem. The staff groups are the prime key to vertical 
spacing, since they group the score, which should also be reflected in the 
vertical layout.

Would it be possible to derive appropriate properties for each staff from the 
grouping when the grouping is still available, so that the vertical alignment 
then has the correct settings derived from the grouping?

> If I can't find a
> nice way to do this, the functionality will be available anyway by setting
> 'previous-space on the first staff and 'next-space on the last staff of a
> staff group.

This is exactly what makes it infeasible currently. I've been writing ~10 full 
orchestral scores (13-21 instruments!), with multiple movements each (e.g. the 
Stabat Mater has 12 movements) so far, and doing this manually is just too 
much work, in particular, since the different kinds of scores can be 
automatically generated, but the vertical stretching can't. That's one of the 
reasons (apart from the part combiner and the missing lyrics with cue notes) 
why none of the scores are yet publically available, since they don't look 
professional.
Having to manually adjust each and every staff will rule lilypond out for 
serious editions of large works...

What's even worse is that with harakiri staves, the top-most or bottom-most 
staff of a group might change during the movement, so simply setting previous-
space or next-space for a staff will not work. It really has to be a property 
of the group and the grouping needs to play a part in the vertical spacing.


> > - -) Fixed positioning of staves/contexts should be possible, even if
> > some contexts are killed (in particular, when there are several measures
> > where a vocal voice is quiet, the lyrics context is automatically killed
> > meanwhile and
> > the explicit positioning is messed up right now.
>
> I'm not sure exactly what you mean by this. Do you mean that
> 'alignment-offsets in 'line-break-system-details should include the
> position of dead staves as well as live ones? 

No, I'm not talking about staves, I'm talking mainly about lyrics line, which 
are also included in the alignment-offsets. As an example, take the following 
sample score, which does not have any explicit positioning yet:
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics_nosetting.pdf
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics_nosetting.ly

Now assume that you want the staves on the exact same position (i.e. the exact 
same spacing, e.g. starting at 0, -15, -30 and -40. The first two staves have 
lyrics to be placed at -5 and -20 (but also have some lines with only rests 
and no lyrics). 
I've run into this situation when writing Vierne's Messe Sollennelle, which 
has four choir voices and two organs. I wanted the staves to be in the exact 
same position on every page...
So, of course you would set the alignment-offsets to:
\layout {
  \context { \Score
    \override NonMusicalPaperColumn #'line-break-system-details = 
#'((alignment-offsets . (0 -5 -15 -20 -30 -40)))
  }
}

And now look at the result:
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics.pdf
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/alignment_offsets_lyrics.ly

The first system behaves as expected, but as soon as one staff does not have 
lyrics assigned in one line, the next staff will be placed where the lyrics 
should have been and the spacing is totally messed up.
Note that there is no setting to prevent the lyrics context from vanishing, so 
currently the explicit positioning is useless for vocal music.

That's what I wanted to point out.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKN4ccTqjEwhXvPN0RAnzyAJ4wLqC1Uy5pq+uSTKjAc/tt6pdhwACgh8LP
2836kNLsau6QLlF3eRRBRoo=
=pI+e
-----END PGP SIGNATURE-----