Re: can InstrumentName padding centered according to the longest instrument name?

[David Nalesnik]

Hi all,

I've attached an improved version of the file here.  It now handles single-staff situations (as when, for example, you remove non-active staves using \RemoveEmptyStaves), and it deals properly with name placement when a name relates to a grouping of staves (a piano part, for example).  Thank you, Kieren, for your troubleshooting!

[One drawback is that Y-positioning must now be consulted to arrive at a proper X-positioning.  This is needed here because our positioning needs a sense of the "topography" of the system start, and there is no other way for us to know which opening bars, brackets, and braces are directly to the right of a particular name.  Seems strange, but so it is as far as I can tell.

If pointers to brackets and such were added to InstrumentName, this would possibly be less problematic, and the attached code would be a little less hairy.

In any case, it appears to work!  So "leave well enough alone"?]

One problem that Kieren noticed is evident in the last example   When the padding is set to 0, all names are as far right as they can go and still be properly aligned one to another.  When, however, the padding is changed, inconsistencies are seen.  With padding = 1, we would expect "Sop./Bar." on the second system to be the same distance from the system-edge as "Piano" is from its bracket on the last system--that is the goal of this function.  Yet there is inconsistency, and this inconsistency varies when padding is adjusted.

It seems that padding is reckoned somewhere else by LilyPond, and that that reckoning is interfering with the usage of padding in this function.

Anyway, I've spent too much time with this and I can't see straight, so if anyone wants to take a crack at solving this, by all means jump in.  Any improvements would be much appreciated!

Best,

David

instrument-name-positioning3.ly
Description: Text Data