lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Some very rough attempts at improving Mark spacing


From: Saul Tobin
Subject: Some very rough attempts at improving Mark spacing
Date: Wed, 12 Jul 2023 17:44:00 -0700

Hi all,

Sharing here some extremely rough ideas on ways to potentially improve
spacing for MetronomeMarks, RehearsalMarks, etc. Please pardon the very
long message and rough code. Since I'm unsure how consistently I will be
able to work on this, I wanted to share my proof of concept/work in
progress.

Idea 1:

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
.

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.

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?

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.

The proof-of-concept basically works, though it currently does not account
for marks with horizontal extent to the left of the anchor point. I'm
assuming that is a solvable problem.

The more significant issue is that when I tried using this engraver in the
context of a real world instrumental part, I still saw places where long
marks over multi-measure rests were allowed to become stacked vertically,
like this:
[image: Screenshot 2023-07-12 at 5.39.44 PM.png]

I'm not sure why this happens even with minimum-length and spacing rods
set, and I haven't yet replicated the issue in a minimal test case. Perhaps
a bug that prevents the spanner from being created/attached to bounds in
certain cases? This is the first time I've attempted to create a custom
grob or mess around with spanners like this, so I'm not sure exactly how to
troubleshoot or what to look for.

This proof-of-concept also doesn't currently work for spacing marks that
occur at the same moment. I'm assuming this has to do with something
fundamental in how spanners work, but I'm not sure. Not a showstopper,
since Jean posted a very handy engraver to handle alignment and spacing of
RehearsalMark + MetronomeMark at the same moment (
https://www.mail-archive.com/lilypond-user@gnu.org/msg146068.html).

Another minor issue with this idea is that MarkSpaceSpanner should only
affect spacing when it is unbroken. The commented out after-line-breaking
callback in the grob definition was my attempt at resolving this, but it
doesn't appear to work. I'm guessing because by the time grob-suicide is
called, it has already affected the spacing? I'm assuming this is probably
solvable though.

PNG image

Attachment: mark-align-spanner.ily
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]