Re: GrandStaff vertical distance

[Thomas Morley]

Hi Lukas-Fabian,

Am So., 14. Okt. 2018 um 15:07 Uhr schrieb Lukas-Fabian Moser <address@hidden>:

> 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.

I would have said the affected spacing is because of different
spacing-values for each context.
Thus I've set up some test-code:

(1) Below reads and displays some spacing values from the StaffGrouper
in terminal

staffGrouperInfo =
\override StaffGrouper.after-line-breaking =
#(lambda (grob)
  (pretty-print
   (list
    (cons 'staff-staff-spacing
          (ly:grob-property grob 'staff-staff-spacing))
    (cons 'staffgroup-staff-spacing
          (ly:grob-property grob 'staff-staff-spacing)))))

mus = { c''1 }

\score {
  \new StaffGroup
    <<
      \new Staff \mus
      \new GrandStaff
        <<
          \new Staff \mus
          \new Staff \mus
        >>
      \new Staff \mus
    >>
  \layout {
        \context {
              \StaffGroup
              \staffGrouperInfo
      }
        \context {
              \GrandStaff
              \staffGrouperInfo
      }
  }
}

You'll get:
((staff-staff-spacing
   (basic-distance . 9)
   (minimum-distance . 7)
   (padding . 1)
   (stretchability . 5))
 (staffgroup-staff-spacing
   (basic-distance . 9)
   (minimum-distance . 7)
   (padding . 1)
   (stretchability . 5)))
((staff-staff-spacing
   (basic-distance . 9)
   (minimum-distance . 7)
   (padding . 1)
   (stretchability . 5))
 (staffgroup-staff-spacing
   (basic-distance . 9)
   (minimum-distance . 7)
   (padding . 1)
   (stretchability . 5)))

Four times the same numerical values, so far ok, I think.

(2) But using exactly those values like:

mus = { c''1 }

\score {
  \new StaffGroup
    <<
      \new Staff \mus
      \new GrandStaff
        <<
          \new Staff \mus
          \new Staff \mus
        >>
      \new Staff \mus
    >>
  \layout {
        \context {
              \StaffGroup
              \override SystemStartBracket.color = #cyan

          \override StaffGrouper.staff-staff-spacing =
            #'((basic-distance . 9)
               (minimum-distance . 7)
               (padding . 1)
               (stretchability . 5))
          \override StaffGrouper.staffgroup-staff-spacing =
            #'((basic-distance . 9)
               (minimum-distance . 7)
               (padding . 1)
               (stretchability . 5))
      }

        \context {
              \GrandStaff

              \override SystemStartBrace.color = #red

          \override StaffGrouper.staff-staff-spacing =
            #'((basic-distance . 9)
               (minimum-distance . 7)
               (padding . 1)
               (stretchability . 5))

          \override StaffGrouper.staffgroup-staff-spacing =
            #'((basic-distance . 9)
               (minimum-distance . 7)
               (padding . 1)
               (stretchability . 5))
      }
  }
}

returns a different image. See attached.
Did I fail to understand something, coded wrongly, or is this fishy??

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

Iiuc, this means to refuse any usage of container-contexts, setting
systemStartDelimiterHierarchy always manually.
With the consequence of loosing the possibility to use the
StaffGrouper-properties at all, need to care about SpanBar and the
Keep_alive_together_engraver. To mention the first three things which
came to my mind.

>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> (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).

And I'm not a progammer at all ;)
I'm a musician.

> For me, there are the following issues with the systemStartDelimiterHierarchy 
> design:
[...]
> What do you think?

I need a break. Will look into it later.

Cheers,
  Harm

atest-80.png
Description: PNG image