lilypond-user
[Top][All Lists]
Advanced

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

Re: \fine and \section across staves


From: Jean Abou Samra
Subject: Re: \fine and \section across staves
Date: Thu, 3 Nov 2022 18:41:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1

Le 03/11/2022 à 18:12, Joel C. Salomon a écrit :
There’s a change between 2.23.6 and 2.23.80 in how `\fine` and `\section` appear across staves.  Below is a near-minimal cut-down version of my score illustrating the change, and images showing the difference.

I normally put commands like `\bar "||"` in a single place (a Dynamics section, usually) and they take effect across all staves.  And in fact, replacing `\section` with `\bar "||'` does take effect across all staves.  So I would like to not have to repeat `\fine` and `\section` also.

Was this change intended?  (I am aware of other changes to `\fine` between 2.23.6 and the new release candidate.)




Yes, it was intended. This is the message of the commit where it was
done:


commit 8ae26d8330c603d249fec5953a887de9fbcbe31c
Author: Dan Eble <nine.fierce.ballads@gmail.com>
Date:   Thu Mar 10 20:08:31 2022 -0500

    Refactor BarLine engraving

    This change moves decisions from Default_bar_line_engraver and
    Repeat_acknowledge_engraver to Bar_engraver, allowing more options for
    configuring the creation of bar lines for various events. Bar_engravers
    are no longer constrained by a single decision recorded in
    Timing.whichBar, but make their own decisions using the local values
    of context properties.

    The previous implementation did offer some local configurability, but
    through a mapping kludge focused on obvious cases.

    In the previous implementation involving Timing.whichBar, one \section
    or \fine could cause a bar line to appear in every Staff under the
    Timing.  In the new implementation, Bar_engraver must observe the
    \section or \fine event.  This is the reason for the change in the code
    of regression test divisions-staff-override-staves.

    Engravers can no longer read whichBar and conclude that there is a bar
    line.  Bar lines may be created without Timing.whichBar being set.
    Engravers needing to know when bar lines are created should either
    acknowledge BarLine grobs (if they are in a Staff or enclosing context)
    or read currentBarLine (if they are in a Staff or enclosed context).


In general, it's always been a credo through repeat-related changes that
the repeat structure in the user input is expected to match across staves,
reflecting the actual music. If you do this, it will also be easier to
extract parts.

Best,
Jean

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

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