Hi,
I also noticed that StaffCollection probably shouldn't have the
Vertical_align_engraver, since this causes vertical spacing to be
different. The original idea was that uncommenting in
\version "2.23.4"
bla = \repeat unfold 30 c'1
<<
\new Staff \bla
%{
\new StaffCollection \with {
\override StaffSymbol.color = #blue
instrumentName = Test
}
%}
<<
\new Staff \bla
\new Staff \bla
>>
\new Staff \bla
>>
shouldn't change spacing at all.
Oh, was it? What is the point of StaffCollection then?
I thought it was meant to group staves from a logical
group of instruments. Don't you want to adjust the
vertical spacing for that?
That would be open for debate. I was thinking mainly of the possibility
of setting common properties for a group of staves (like the
StaffSymbol.color in my example) without any layout side-effects. While
this is merely a matter of convenience for Staff properties, it becomes
necessary for instrumentNames: As I was (and maybe still am, but I have
to get back to your email concerning this at a later point in time)
thinking of providing the bracketed instrument names as a variant of
instrumentName (maybe GroupName or CollectionName), it became necessary
to group staves without automatic SystemStartDelimiter's.
Or, in short: To be able to group staves logically, not visually - where
"logically" means "from the LilyPond perspective, not the musical
perspective".
But it might well turn out that every reasonable use of StaffCollection
also would deserve the vertical spacing implications of the
Vertical_align_engraver.
It could also be made configurable:
visualGrouping = \with {
\consists Vertical_align_engraver
}
\new StaffCollection \with { \visualGrouping }
<<
% etc.
>>
Homework for me: Find out more about the actual job done by the
Vertical_align_engraver.
My spontaneous reaction would be to think that, while
StaffGroup, ChoirStaff, GrandStaff and PianoStaff are
four different ways of grouping staves with no
conceptual hierarchy (even though I changed engraver-init.ly
so it used \StaffGroup to conveniently define the others,
but this does not end up as a relationship involving StaffGroup
as any kind of parent), StaffCollection encompasses all
four ways -- in OOP terms: a superclass with four
distinct subclasses.
Yes, that's convincing, I think. The question might be if users are
going to (or should) be aware that their StaffGroup's etc. are all
different kinds of StaffCollection's.
Lukas
