[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-devel
Subject:    Re: Some very rough attempts at improving Mark spacing
From:       Jean Abou Samra <jean () abou-samra ! fr>
Date:       2023-07-13 1:37:51
Message-ID: 3fee905db42e0735b7274fe05c4c0be177a6b653.camel () abou-samra ! fr
[Download RAW message or body]


Le mercredi 12 juillet 2023 à 17:44 -0700, Saul Tobin a écrit  :
> A custom grob MarkAlignSpanner, created by Mark_align_engraver. This is
> based very closely on DynamicLineSpanner and the example engraver here:
> https://extending-lilypond.gitlab.io/en/extending/translation.html#example-for-setting-bounds-align-all-dynamics-engraver
>                 
> .

So you want all marks from a context to be vertically align, or
at least most of them?

I agree that we should avoid the user having to create a custom context
(which should be a content matter) for alignment (a formatting matter).
I think we should consider making a somewhat more general mechanism
because we're starting to have quite a few *LineSpanner grobs though.


> Currently one issue is that when ledger lines or tall marks push the
> MarkAlignSpanner upward, the vertical extent of the system is not
> calculated correctly. I'm assuming this can be remedied by something in the
> grob definition.


It's been a while since I did any work in that area, but empirically
this appeared to work:

    (after-line-breaking . ,ly:side-position-interface::move-to-extremal-staff)

I don't really understand why -- it may mean that ly:system::calc-pure-relevant-grobs
has something broken? Not sure. (The pure stuff is *extremely* tricksy, to the extent
that determining if something is a clever technique or a nasty bug can be tough.)


> The nice thing about using a spanner rather than a custom MarkLine context
> is that, similar to DynamicLineSpanner, multiple MarkAlignSpanners could be
> created and broken allowing for multiple baselines, rather than just a
> single one for the entire score. Not sure exactly what criteria to use for
> breaking MarkAlignSpanners automatically – ideally I'd like for marks to
> align on the same axis spanner until a mark would require a different
> vertical offset beyond a threshold value, at which point the axis spanner
> would be broken. But that might require spacing information not available
> during translation. Maybe there is a clever solution?


No, you can't do that during translation. It might be possible in the
backend but you would first have to define what criterion you want.

It might necessitate some long-needed refactorings of outside-staff positioning.


> Idea 2:
> 
> A custom grob MarkSpaceSpanner, created by Mark_space_engraver (code
> included in the same attached file, despite the file name). The idea here
> is to create a spanner connecting each consecutive mark, and to avoid
> horizontal overlapping marks by setting spacing-rods and minimum length.
> This could avoid the issues with music spacing caused by just setting
> extra-spacing-width and extra-spacing-height as in markLengthOn; also
> markLengthOn does not guarantee that marks will not be stacked vertically,
> particularly in situations with longer tempo markings over compressed MMRs.


If I'm correctly reading between the lines, you want to avoid the likes
of https://gitlab.com/lilypond/lilypond/-/issues/6641 where marks affect
the spacing of the music. In essence, you want the spacing to be determined
by

1) determining the horizontal spacing constraints in the music
2) same thing in the line of marks
3) solving the spacing problem to find a solution satisfying both
   constraint sets
4) stacking the marks on top of the music

instead of the current

1) stack marks on top of the music approximately (with the extra-spacing-height
   hack from \markLengthOn to virtually raise the rehearsal marks so they don't
   affect the music too much)
2) find horizontal spacing constraints in this setting


I think that's reasonable, but I would try to bake it into the spacing algorithm
instead of piling more grobs on top. Should be a matter of changing
Paper_column::minimum_distance and some other routines. Admittedly, this
is going to be quite hard work if you're a newcomer to the codebase, since,
as I said, spacing is tricksy. But it is precisely because it's so complex
that I would be really wary of adding more complexity in this area.


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]