Re: box around notes

[David Nalesnik]

Hi Klaus.

On Mon, Apr 6, 2015 at 4:55 PM, Klaus Blum <address@hidden> wrote:

Hi David,

here's my first attempt to apply my drawing function to your project. Thanks
again for sharing this really cool tool!

You're very welcome.  What you've done with it is really impressive, and I hope that one day this will be trouble-free!

 

I've played around with some settings, and I also experimented with the
messed up dynamics problem when taking the engravers out of the score
context.
It works if you set outside-staff-priority to a value high enough:
   \override MusicBoxer.outside-staff-priority = #10000
   \override Box.outside-staff-priority = #10000
However, this leads to a warning:
"Ein Objekt außerhalb der Notenzeile sollte eine Richtung haben, Vorgabe ist
»nach oben«"
(Following the lilypond translation, this is the original warning message:
#: axis-group-interface.cc:786
msgid "an outside-staff object should have a direction, defaulting to up")

It seems that there is something taken into account for spacing
calculations, but LilyPond doesn't know if this mysterious something is
located above or below the score.

Well, the "mysterious somethings" are quite simply the boxes.  When you set outside-staff-priority, the object becomes an outside-staff object, and thus needs a direction to know how it should be moved when arranging outside-staff objects.

In the attached file, I put the relevant information into the grob description.  I lowered the outside-staff-priority from 10000 to 251 to show that (here at least) it only has to be larger than the dynamic which has a priority of 250.  How did you arrive at 10000?

  

By the way, if I put a box around an eighth note that is attached to a beam,
the beam completely disappears. With MusicBoxer this is not the case.

The warning is the key -- well, a first clue:

 programming error: minimise_least_squares ():  Nothing to minimise

This means that vertical spacing is triggered

before line breaking

Something somewhere has calculated vertical spacing too early, and this messes up the positioning of the Beam grob.

The problem is in the stencil callback for Box, which in your version is set to the same function as MusicBoxer.  When you request information about Y-extent, the function ly:relative-group-extent triggers vertical spacing routines before LilyPond is ready.  She must determine line breaks before the final stamp is put on the vertical aspect.

I believe what is needed is a "pure" callback for Y-extent, so that LilyPond can make a safe estimate (i.e., without side effects) to use for purposes of line-breaking.  Unfortunately, I'm having no luck with this.

You can read about purity here:

http://lilypond.org/doc/v2.19/Documentation/contributor/understanding-pure-properties

In the attached, I duplicated most of the code of music-boxer-stencil for box-stil with a small change.  This is not a solution, just a demonstration of what causes the programming error and the disappeared beam.  Note that I just hardcoded Y-extent so that no calculation happens -- obviously a non-solution ...

Possibly you can continue to use the same stencil callback for both objects. In any case I'm pretty sure you will have to move the determination of height to a separate group of functions.

 

Unfortunately I cannot be much of help for any explanation because the way
LilyPond acts behind the scenes is still a mystery to me...

I'd like to be able to say that it all becomes clear at some point, but alas...

Hope this helps somewhat!

David

boxer5.ly
Description: Text Data