Re: (de)cresendi syntax

[Carl D. Sorensen]

Frederic,

I have made some comments in your message below.  Thanks for taking on this
project.

This type of proposal probably should go to lilypond-devel, rather than
-user, so I'm cross-posting to -devel.


On 2/22/09 1:25 AM, "Frédéric Bron" <address@hidden> wrote:

> Hello,
> 
> I am in charge of the question of (de)crescendo syntax issue in 2.12.2.
> 
> Here is what lilypond 2.12.2 currently does (in ly/spanners-init.ly):
> 
> - \< and \cr are equivalent: they start a crescendo event on the
> previous note: #(make-span-event 'CrescendoEvent START)
> - \> and \decr are equivalent: they start a decrescendo event on the
> previous note: #(make-span-event 'DecrescendoEvent START)
> - \!, \endcr and \enddecr are equivalent: they stop of (de)cresendo
> event on the previous note: #(make-span-event 'CrescendoEvent STOP),
> #(make-span-event 'DecrescendoEvent STOP) (is it really equivalent?)
> 
> - the following commands set the (de)cresendo to be text with dashed
> line or hairpin forever (until changed to something else):
>    . crescTextCresc -> text "cresc."
>    . dimTextDecresc -> text "decresc."
>    . dimTextDecr -> text "decr."
>    . dimTextDim -> text "dim."
>    . crescHairpin -> hairpin
>    . dimHairpin -> hairpin
> 
> 
> - the following commands start a text (de)crescendo on the next note
> (affects only the next (de)crescendo):
>    . cresc -> text "cresc."
>    . dim -> text "dim."
> - the following commands stop a (de)crescendo on the next note:
>    . enddim
>    . endcresc
> 
> 
> Current syntax is not satisfactory because:
> 
> - syntax is different between \<, \>, \! and \cresc, \dim, \enddim,
> \endcresc (undocumented):
>    . \<, \>, \! apply to the previous note,
>    . \cresc, \dim, \enddim, \endcresc apply to the next note
> - there is no symmetry between \crescTextXXXX, \dimTextXXXX commands and
> \XXXX commands
> - some people just want cresc. to be printed without dashed line (spanner)
> - \endcresc does something different from \endcr which is confusing
> 
> 
> Here are my dreams:
> 
> - \<, \>, \! are used to start/stop (de)crescendo spanner (hairpin or text),
> - crescTextXXX, dimTextXXX, crescHairpin, dimHairpin decide if \<, \>,
> \! produce text or hairpin (applies for ever until changed to something
> else), I would prefer simpler syntax: \crescCresc, \crescHairpin,
> \dimDim, \dimDecr, \dimDecresc, i.e. remove Text

This part of the syntax got hashed out pretty heavily as part of 2.10.  I
think that the crescXXX and dimXXX syntax is where we want it.

The issue is that there are hairpin crescendos and decrescendos, and there
are text crescendos and decrescendos.  That's why the Text word was put in
there.  Perhaps we could make a change, but we ought to review this
carefully.

The previous conversation was at
http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/15693/focus=15696

This is all coupled together with the idea that there are dynamic markings
that aren't really spanners, but are just markups for the individual note.

> - \<"cresc.", \<"cresc. poco a poco", \>"dim."... produce a text spanner
> with corresponding text, the spanner is ended with \!, the text applies
> only once, i.e. next (de)crescendo produces hairpin if this is the
> current setting

I believe that this will require a rewrite of the parser.  It will be
challenging to identify the difference between \< which starts a crescendo
spanner in your  proposal above, and \<"my crescendo text here" which starts
a text spanner.

> - \cresc, \dim, \decr, \decresc produce a text without spanner, applies
> only once to the previous note, no need to finish with \! or \endcresc,
> this could be implemented with a \markup command

I don't like the idea of changing current syntax so dramatically, but I may
be in the minority here.

> - remove unnecessary \cr, \endcr, \decr, \enddecr

I'm not sure why we have both \cr and \<.  If the two really are equivalent,
one ought to be deprecated before it is ultimately removed.

> - remove unnecessary \enddim, \endcresc


> 
> I know that it is not possible to implement this only with scheme and
> lily code but I am sure it is possible in C++.
> 
> Could you please comment on these propositions and give any other ideas.
> 
> F. Bron
> 
> PS: attached is a file that show the behaviour of the commands.