[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crescendo after custom dynamic marking
From: |
Lukas-Fabian Moser |
Subject: |
Re: Crescendo after custom dynamic marking |
Date: |
Mon, 13 Dec 2021 07:53:34 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
Hi all,
Am 12.12.21 um 22:52 schrieb Lukas-Fabian Moser:
Maybe I'm going too far in my belief that "standard tasks best should
not require # characters and scheme", but shouldn't we provide a
LilyPond syntax interface for this? It's not so uncommon to want
custom dynamic expressions after all:
dynamic =
#(define-music-function (text) (markup?) (make-dynamic-script text))
Thanks for your thoughts, everybody! Some questions/further thoughts:
1)
Right, it should be an event function. In fact, it's currently _the_
example of a custom event function in the documentation:
https://lilypond.org/doc/v2.23/Documentation/extending/event-functions.html
(which consequently should be replaced by something more interesting and
less standard). But the remark in the documentation that, if one uses a
music function instead of an event function, one would always have to
use it with -/_/^, seems to be obsolete now. In fact, the warning
applies to 2.19.83, but not to 2.20, which surprises me (as I had
thought that commits to 2.20 were a subset of those to 2.19.83.)
2)
What about the old make-dynamic-script? I agree that
\make-dynamic-script is not a nice name for a syntax function. If we
provide something like \dynamic, should make-dynamic-script be removed?
If so, would the following be the right thing to do in a convert-ly rule?
- Replace #(make-dynamic-script SOMETHING) by \dynamic #SOMETHING
- and (maybe) afterwards replace (make-dynamic-script SOMETHING) by
(dynamic SOMETHING) to catch uses inside scheme?
3)
I knew about Harm's highly complex dynamics function but didn't have it
at hand - thanks, Kieren, for providing the link to
https://lists.gnu.org/archive/html/lilypond-user/2019-09/txtoVtTEvm7jG.txt
I'd love to have this in the standard codebase (if Harm is fine with
this), but this makes the scope of my proposed addition explode. Since
perfect is the enemy of the good, I think I'd rather to the "easy" thing
first, although it would be nice if Harm's function, once added, gets
the name \dynamic. I see two options:
a): Add the proposed simple event function under a different name: \dyn
or \simpleDynamic, then later add Harm's function as \dynamic and maybe
see if it's reasonable to declare \dyn/\simpleDynamic obsolete?
b): Add \dynamic right now as the simple event function and later give
it a huge enhancement in Harm's function, while trying not to break
existing code (which might be hard).
and for the sake of completeness also:
c): Add \dynamic know and later find a special name for Harm's dynamic
engine.
Opinions?
Lukas
- Crescendo after custom dynamic marking, Ahanu Banerjee, 2021/12/12
- Re: Crescendo after custom dynamic marking, Jean Abou Samra, 2021/12/12
- Re: Crescendo after custom dynamic marking, Lukas-Fabian Moser, 2021/12/12
- Re: Crescendo after custom dynamic marking, Jean Abou Samra, 2021/12/12
- Re: Crescendo after custom dynamic marking, David Kastrup, 2021/12/12
- Re: Crescendo after custom dynamic marking, Aaron Hill, 2021/12/12
- Re: Crescendo after custom dynamic marking, David Kastrup, 2021/12/12
- Re: Crescendo after custom dynamic marking, Aaron Hill, 2021/12/12
- Re: Crescendo after custom dynamic marking, Kieren MacMillan, 2021/12/12
- Re: Crescendo after custom dynamic marking,
Lukas-Fabian Moser <=
- Re: Crescendo after custom dynamic marking, David Kastrup, 2021/12/13
- Re: Crescendo after custom dynamic marking, Lukas-Fabian Moser, 2021/12/13
- Re: Crescendo after custom dynamic marking, Werner LEMBERG, 2021/12/13