Re: GrandStaff vertical distance

[Lukas-Fabian Moser]

Hi Harm,

thanks for your help in tidying up ;-).

Though, the whole thread mixes up different topics.

I'm not sure, tbh. Of course, setting delimiters and setting spacing should be thought of as mostly orthogonal aspects of setting up a score. The problem, I think, arises because (I think) it's tempting to think that the only way to get a braced sub-group of a StaffGroup is by nesting a new GrandStaff (or PianoStaff), which is bad since this also affects spacing.

Hence my claim that foxfanfare's second approach using the systemStartDelimiterHierarchy is the conceptual and right one - change only what you want to change.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
(2) Changing the systemStartDelimiterHierarchy
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

As already mentioned in this the user-interface for
systemStartDelimiterHierarchy is terrible. It always gives me a
headache when I need to use it.
So improvements in this regard would be highly welcome, imho.
Maybe Lukas-Fabian's code is a step in this direction. So far I have
not taken a closer look, though.

Probably not, I'm far from convinced of the quality of my code ("Montagsprogrammer", as one could say in German).

For me, there are the following issues with the systemStartDelimiterHierarchy design:

1) There's an overlap between systemStartDelimiter and systemStartDelimiterHierarchy, namely
systemStartDelimiterHierarchy = #'(SystemStartBrace)
is equivalent to (and in fact overrides, if there's a conflict)
systemStartDelimiter = #'SystemStartBrace
Might be ugly, might be convenient. Not sure.

2) The docs state that systemStartDelimiterHierarchy
"... takes an alphabetical list of the number of staves produced. Before each staff a system start delimiter can be given. It has to be enclosed in brackets and takes as much staves as the brackets enclose. Elements in the list can be omitted, but the first bracket takes always the complete number of staves. The possibilities are SystemStartBar, SystemStartBracket, SystemStartBrace, and SystemStartSquare."
First, this seems to be plain wrong ("brackets" instead of "parentheses"). Second, I have no idea what an "alphabetical list" is supposed to be. The example given in the docs uses a,b,c,d as placeholders for the staves, but in fact, any symbol (not equal to SystemStartBar etc.) may be used; they even may be identical. I use this heavily in my code (but tbh I did not look at the implementation of the systemStartDelimiterHierarchy interface).

3) systemStartDelimiterHierarchy allows for heavy nesting:

\new StaffGroup \with {
  systemStartDelimiterHierarchy = #'((a (a (SystemStartBrace a) a) a))
}
<<
  \new Staff a
  \new Staff a
  \new Staff a
  \new Staff a
  \new Staff a
  \new Staff a
  \new Staff a
  \new Staff a
>>

While this is neat (and I think the syntax is in fact quite well suited for constructions of this kind), I would assume that it is almost never used. Of course it should stay being supported, but I would expect 99% of all use cases comprise of <= 2 layers of nesting, most commonly one or several top-level Brackets with some sub-Braces/Squares.
The code I gave is tailored for a subset of this use-case, namely that in which there is only one top-lavel Bracket/Square/Bar... comprising the whole StaffGroup (and arbitrarily many first-order subgroups). If you want several disjunct top-level Brackets and still use my function, you have to create several StaffGroups - and hence you affect spacing. For the use cases I have in mind, this is fine, but maybe I'm wrong. Of course this might be changed.


So, basically I think we should
- keep systemStartDelimiterHierarchy as it is
- improve the docs for this (I could try and come up with an improved explanation)
- provide a simple function (like the \setDelimiters I proposed) that allows for easier setting of delimiters in the common use-case of <= 2 nesting levels.

What do you think?

Best
Lukas