[Top][All Lists]

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

Re: Issue 1089 in lilypond: DynamicTextSpanner not printed

From: Reinhold Kainhofer
Subject: Re: Issue 1089 in lilypond: DynamicTextSpanner not printed
Date: Sat, 29 May 2010 00:15:49 +0200
User-agent: KMail/1.13.3 (Linux/2.6.32-22-generic; KDE/4.4.3; i686; ; )

Am Freitag, 28. Mai 2010, um 20:04:41 schrieb Carl Sorensen:
> 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.

> So, what should LilyPond do when it encounters this situation?  I think we
> both agree that it *must* emit a warning message.  It's arrived at a
> situation where it can't do what is correct.  So it needs to make its best
> guess, and tell the user that something has gone wrong.
> 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.

Uhm, in a 100+ pages score it is much worse if anything is left out, because 
you will NOT  see it from the output. If you accidentally ship it to a 
printer/client, you will be up for a bad surprise. This is even worse, as the 
visibility of "cresc" would then dpeend on the spacing. Different line breaks 
might lead to larger/smaller spacing, which then leads to "cresc" being 
visible or not... So you can do three rounds of proof-reading, then change one 
small thing that changes some line breaks, and your proof-readings will be for 
naught and a cresc will be missing. (I had a similar situation with figured 
bass, which behaved differently when used in a FiguredBass context as opposed 
to inside a voice, so all figures on rests were silently discarded and I 
didn't notice....)

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 

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 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). 
I agree, this is not correct, but I suppose it is used more often than we 

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


Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

reply via email to

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