lilypond-devel
[Top][All Lists]
Advanced

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

Re: Simultaneous \key markings behave differently to \clef or \time.


From: Richard Shann
Subject: Re: Simultaneous \key markings behave differently to \clef or \time.
Date: Tue, 28 Jun 2022 16:37:12 +0100
User-agent: Evolution 3.38.3-1

On Tue, 2022-06-28 at 16:45 +0200, Jean Abou Samra wrote:
> Le 28/06/2022 à 13:36, Richard Shann a écrit :
> > I've noticed that two \key in succession results in the first being
> > honored while the opposite is true for everything else I've tested.
> > Consider:
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > \version "2.22.0"
> > 
> > {
> >    \time 3/4 \time 5/4 c''
> > }
> > {
> >    \clef bass  \clef alto c''
> > }
> > {
> >    c'' \bar "||" \bar ":..:"
> > }
> > {
> >    \key f \major \key d \major c''
> > }
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > 
> > Not a problem except when using include files or (as in my case
> > generating the code programmatically.
> > 
> > Is there a good reason for this, or is it just a wrinkle that could
> > be
> > fixed?
> 
> Hi,
> 
> Could you elaborate on your actual problem? 
Well, that's not going to be easy or helpful - it has more to do with
the 20 year history of Denemo than anything else - Denemo gives a
special status to the initial key. 

> I don't immediately se
> why you would want to generate code that has simultaneous key changes
> like this. Similarly, I don't understand the problem with include
> files.

This was just a speculation of my part: if someone had a template file
for a symphony in Dmin and put the opening preamble about clefs and key
in an include file and then had one movement in Dmaj they might want to
override what was in the include file. But I can imagine this is pretty
far fetched as no one has complained about the inconsistency before
(?).

> 
> The wrinkle is actually on the side of \time, \clef and \bar.
> Most stuff warns on duplicated events and accepts the first
> (except if they are exactly the same, which masks this for the
> user in many cases):
> 
> { c'\p\f }
> { \mark "A" \mark "B" c' }
> { \tempo "A" \tempo "B" c' }
> { \tempo 4 = 120 \tempo 4 = 90 c' }
> {
>    c'\tweak bound-details.left.text "rit" \startTextSpan
>      \tweak bound-details.left.text "rall" \startTextSpan
>    c'\stopTextSpan
> }
> 
> The reason \time and \clef don't do this is that they are
> implemented in a peculiar way. They don't use events but
> set context properties. That allows them to work in \with
> and \layout { \context { ... } }. (I have some vague plans
> to allow events to work there, which would allow to make
> \time and \clef more usual.) In the case of \bar, it just
> appears to be a little less convenient than elsewhere due
> to the way it works internally, and therefore not done.
> 
> Personally, I think warning and rejecting the second event
> is a good idea. There are cases where might hope that you'd
> be able to combine those events (like with \mark and \startTextSpan).
> Duplicated events are the result of either a user error, or
> a hope from the user that LilyPond will not be able to fulfill.
> Either way, a warning is helpful.

Well, I guess I should go forward on the assumption that the behavior
may change in the future and try and ensure duplicates are not
emitted...

Thanks for the reply,

Richard




reply via email to

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