lilypond-devel
[Top][All Lists]
Advanced

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

Re: cadenza followed by a MMR is buggy


From: David Kastrup
Subject: Re: cadenza followed by a MMR is buggy
Date: Fri, 15 Jan 2021 16:47:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dan Eble <dan@faithful.be> writes:

> On Jan 15, 2021, at 06:53, David Kastrup <dak@gnu.org> wrote:
>> 
>> Werner LEMBERG <wl@gnu.org> writes:
>> 
>>>> Add issue #3640 to this discussion.  Accidentals, bar numbers, and
>>>> (now) multi-measure rests are all impacted by the fact that \bar "|"
>>>> does not create a new measure.
>>> 
>>> Maybe the whole thing is primarily a documentation issue that could be
>>> fixed with prominent warnings at appropriate places?
>> 
>> Maybe \bar "|" could just bump the bar number (and reset bar position)?
>
> If we went that way, I'd generalize it to \bar X when X ==
> Timing.defaultBarType.  Regardless, it is likely to be tricky to
> implement.
>
> Were you thinking of limiting this special effect to the end of a
> cadenza?

No, to any midbar position.  Which is a bit of a problem with
\endCadenza since \endCadenza often occurs at measurePos = 0.  So
"midbar" probably cannot rely on that for detection.

>> Can anyone think of a scenario where this would not make sense?
>
> What if the user wants to force a new measure and use a section bar
> line?  Would we suggest using \bar "|" \bar "||" to achieve that?
> That seems awkward.

I'd use any bar type except for \bar "" actually.  Though with regard to
accidental rules, a line break could independently bump the internal bar
number by one and in that way force a different behavior for accidentals
on ties over bar lines.

> On the whole, I'm not enthusiastic about adding special cases or new
> interactions to bar lines.

Not saying that there is a simple or straightforward implementation (and
counting line breaks as internal bar number advances would be hell to
implement since line break decisions are made much later than accidental
rules are applied, so the tally-keeping for accidental rules would need
to be a lot more complex in order to provide the necessary information
for _any_ line break combination).

Just that there is a somewhat natural expectation and interpretation.
Where the user ends up "I hoped that this would work though I cannot
imagine how it managed to do that".

> Recently, I've been trying to disentangle things to improve the
> chances of implementing a priority or layering scheme to address issue
> #3688.

Music typesetting is hard.

-- 
David Kastrup



reply via email to

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