lilypond-devel
[Top][All Lists]
Advanced

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

Re: What to do when \> and \< produce text


From: Trevor Daniels
Subject: Re: What to do when \> and \< produce text
Date: Thu, 30 Oct 2008 10:03:35 -0000


Mats Bengtsson wrote Thursday, October 30, 2008 9:03 AM

Valentin Villenave wrote:
2008/10/29 Reinhold Kainhofer <address@hidden>:

\decresc ... Starts a text decrescendo

This one wasn't available earlier, but can of course easily be added if there's consensus about it. For the macros that change the layout of all future dynamic indications, we have \crescTextCresc, \dimTextDecresc, \dimTextDecr and \dimTextDim, so for symmetry we should then have \cresc, \decresc, \decr and \dim for the one-time versions. The problem
is that the command name \decr already is occupied and is a synonym to \>.

I like the proposed symmetry between persistent and one-time
versions!  This makes a confusing set of commands easier to
remember (and writing the docs easier too;)  I'm also in
favour of removing synonyms for the same reasons.

Before we make these macros "official" by including them in the docs, we should discuss if they should just print the "cresc." / "dim." or if they also should give a dashed line. I cannot say, without looking at my music collection, how common it is to have a cresc./dim. indication
without the following dashed line which tells how long it should last.

In my experience (vocal music), cresc and dim without a dashed
line is used almost universally.  Hairpins are used when an extent
is being indicated.

On the other hand, if we decide to add the dashed line, then it certainly matters.

I vote for not adding the dashed line to these commands.

Besides, we should also have a rule to delete \endcresc since this is
no longer needed in any way.

Well, it's a synonym to \! and \endcr.

Commands which exist but are not documented are a bad thing,
causing confusion just as \cresc has done.  We should decide
whether they are in or out, and apply that decision consistently
to action and documentation.  As there are so many cresc/dim-
related commands I would prefer a reduction whenever possible.

  /Mats

Trevor





reply via email to

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