[Top][All Lists]

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

Re: Issue 1089 in lilypond: DynamicTextSpanner not printed

From: Xavier Scheuer
Subject: Re: Issue 1089 in lilypond: DynamicTextSpanner not printed
Date: Sat, 29 May 2010 16:07:44 +0200

2010/5/28 Carl Sorensen <address@hidden>:

> I think there are two questions here, and perhaps we agree on one and
> disagree on the other.
> The first question is: Does the 2.10.33 ouptut match what is asked for
> from the music, i.e. a text crescendo starting on the first note, and
> ending on the second note.  I think we both agree that it does not.
> If you think that the 2.10.33 output matches the input, please explain
> your reasoning to me.

Of course you are right, if you think LilyPond should do it in a strict
"stubborn" way.  :)

> [...]
> For the record, I don't think either situation is right!


> In my mind, it's probably best to *not* print the cresc. and to omit
> the warning, because the user will know (from the output) that
> something is missing, and then can go to the log file to figure out
> why.  On the other hand, if the cresc. is printed, the user may not
> notice from the output that the extent of the text crescendo is too
> long for the music.  Hence, I think that not printing is a better
> failure mode than printing, because it's more obvious.

There I don't agree anymore.
You are reasoning in a "developer-mind", where I'm reasoning as a
"lambda" user.  My idea is closer to Reinhold's thoughts (but not
exactly the same, see below).

> But I don't believe that it is a regression.  A regression means that
> music that used to print correctly now doesn't print correctly.
> Since it never printed correctly, it's not a regression.

I have no statement about this "cuisine interne"-stuffs.

2010/5/29 Reinhold Kainhofer <address@hidden>:

> On the other hand, if the "cresc" is printed, it is not such a
> problem if it goes beyond the second note, even though it might be not
> 100% correct interpretation.

That's exacly what I think!

> In my eyes, the strict solution would be to stretch the two notes so
> that the whole "cresc" can be printed and ends on the second note.

In a strict way, yes.
In a "practical" way, no.

Imagine somebody changes the text to "cresc. poco a poco" but still
ends it on the second note (which is an abhorrence, we all agree).
Then the second note would be incredibly shifted!
No, I don't think DynamicTextSpanner should behave like \textLengthOn .

> In reality, however, text crescendi should only be used for longer
> (de-)crescendi, so using a text crescendo and ending it on the next
> note is usually a shortcut of the engraver so he does not have to keep
> track of open crescendi (if no spanner line is printed, the output
> will be the same).

Yeah, that's what I meant by saying this is a pure "theorical case"
(but however could be used in practise).

BTW when  http://lists.gnu.org/archive/html/lilypond-user/2010-05/msg00171.html
will be fixed, I'll certainly come again to request
"*without dashed line*" cresc by default for \cresc ...  ;D

> So, I would print the "cresc" (even though it goes beyond the second
> note), but print out a warning, too.

Yes (but since it prints the "cresc." I'm not sure the warning is
really necessary).  OK, in strict way, yes it is.

Thanks everybody for your attention.


Xavier Scheuer <address@hidden>

reply via email to

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