Re: [PATCH] Re: syntax change for \cresc

[Xavier Scheuer]

Thanks for this very useful reply.

2010/4/25 Reinhold Kainhofer <address@hidden>:

>
> [...]
>
> You can continue using that definition, of course.
>
> However, your approach has the problem(s) that (1) it only creates
> something that looks like a crescendo, but lilypond does not know
> this internally, so (2) MIDI won't be affected at all, and (3) should
> we ever get a MusicXML backend (or any converter to any other format)
> it will also not properly export the crescendo.

I basically knew all this, but (1) since it looks like what I want it's
ok for me, (2) I use LilyPond for its PDF output, I don't really care
about the MIDI and (3) I have never used MusicXML so far.  :)

But of course you are right and it would be better if this was handled
correctly.

Note that the same problem occurs with custom dynamics like "p subito",
"più f", "mp dolce", ...
Though I think Valentin told me that Graham's "make-dynamic-extra"
function take care of that (at least points (1) and (2)).

http://lilypond-french-users.1298960.n2.nabble.com/Texte-aligne-sur-dynamic-was-Utilisation-de-la-commande-make-dynamic-script-tp4105476p4105706.html

[Dreams} It would be great to have a simpler, more user-friendly way
to align text with dynamics.  [\Dreams]


> The \cresc, \dim, \decresc commands need to produce spanners
> internally, otherwise lilypond won't have that information available.
> Lilypond does not necessarily have to print a spanner line, though.

Well, I think I can trust you: words like "spanners" and "lilypond
internals" still sound like "dark mystic magic" for me.  ;D


> You know that you can (globally or locally) override the spanner type
> and even hide the line?
>    \override DynamicTextSpanner #'dash-period = #-1.0

Yes, I know.
But the problem is: what if I have a score with both "spanned" and
"non-spanned" textual crescendi?
I mean I don't want to add
  \once \override DynamicTextSpanner #'dash-period = #-1.0
before each that does not have an extension line.
And this still requires the \crescTextCresc, *each time* you switch from
"hairpin" to "text".

And above all both (\once \override ... and \crescTextCresc) need to be
placed *before* the note.
But, as I said:

> I hate these commands that requires to place something before the note!

:p


> It's just a question whether this should be made the default or not..

If there is a poll I definitely vote "yes".

But I still think it would be great to have 2 different syntaxes for
spanned and non-spanned crescendo texts.
Just to avoid to play with \once \override ... before the note.

And also a simple, user-friendly syntax for custom crescendo texts
(your music function is great but is Scheme-based and I was thinking at
a "LiliPond"-based syntax).
Hence the \crescText "cresc. blabla" and \crescTextSpan "cresc. poco a
poco" proposal, to be discussed during the GLISS?


> No, \cresc created a dashed spanner.

I was quite sure it didn't.
I haven't used the non-modified \cresc command for dozen of months now.

I should have checked before posting.


>
> [...]
>
> That won't work without modifying the parser and complicating the
> syntax. I don't think we have han-wen's support for this.
>
> AFAIR, there was no consensus about the exact output, so what you
> remember was a statement by one person, not a general agreement.

Again, you are right.
It was Frédéric's proposal.
http://lists.gnu.org/archive/html/lilypond-user/2009-02/msg00662.html
(another part of the discussion here, for the ones that may be
interested:
http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00426.html )


> See input/regression/dynamics-custom-text-spanner-postfix.ly for how
> to create dynamic text spanners with arbitrary texts.

Nice!
Is it possible to have the same without the extension line to be
printed?  I am never satisfied but I also would like to use it without
having to add the '-' before the \mycresc command.  As I use \p , \f or
\< without '-'.

Should I say that it would be useful for many people to see this in the
LSR and in the doc?
Or maybe you are just waiting for it to be implemented by default?


> Me too.
:D

Many many thanks,
Xavier

--
Xavier Scheuer <address@hidden>