Re: Crescendo after custom dynamic marking

2021-12-13 Thread Werner LEMBERG


> c): Add \dynamic know and later find a special name for Harm's
> dynamic engine.

(d) You add now `\dynamic` in a first MR.  Eventually, Harm's stuff
gets applied in another MR under the same name, extending your
stuff.[*] IMHO there is no necessity to provide `convert-ly` rules
between development versions, especially since the LilyPond's
current micro version is still a single digit.


  Werner


[*] Under the assumption that this actually makes sense.



Re: Crescendo after custom dynamic marking

2021-12-12 Thread Lukas-Fabian Moser

Hi David,

Am 13.12.21 um 08:05 schrieb David Kastrup:

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.

No, it isn't.  Put \displayLilyMusic (or other music functions) before
either.  There is now a cleanup pass collecting loose pieces in
sequential expressions but it does not come in time for assembling the
arguments of music functions.


Ah, thanks for the explanation.

In other words, LilyPond is now so robust that it's gotten harder to 
demonstrate how things go wrong if one uses music functions instead of 
event functions. But 
https://lilypond.org/doc/v2.23/Documentation/extending/event-functions.html 
needs an overhaul anyway; I'll try to work on this.


Lukas




Re: Crescendo after custom dynamic marking

2021-12-12 Thread David Kastrup
Lukas-Fabian Moser  writes:

> 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.

No, it isn't.  Put \displayLilyMusic (or other music functions) before
either.  There is now a cleanup pass collecting loose pieces in
sequential expressions but it does not come in time for assembling the
arguments of music functions.

> 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.)

-- 
David Kastrup



Re: Crescendo after custom dynamic marking

2021-12-12 Thread Lukas-Fabian Moser

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




Re: Crescendo after custom dynamic marking

2021-12-12 Thread Kieren MacMillan
Hi Lukas,

> Maybe I'm going too far in my belief that "standard tasks best should not 
> require # characters and scheme"

The limit does not exist.  ;)

> but shouldn't we provide a LilyPond syntax interface for this?

Yes.

Do you know Harm's work in this direction?
https://lists.gnu.org/archive/html/lilypond-user/2019-09/txtoVtTEvm7jG.txt

Cheers,
Kieren.


Re: Crescendo after custom dynamic marking

2021-12-12 Thread Aaron Hill

On 2021-12-12 3:48 pm, David Kastrup wrote:

Aaron Hill  writes:


On 2021-12-12 3:19 pm, David Kastrup wrote:

and one could instead define it as
make-dynamic-script =
#(define-event-function (str) (ly:markup?)
   (make-music 'AbsoluteDynamicEvent 'text str))


Did you mean just markup? or is ly:markup? a special predicate?


Ouch.  Of course the former.


Just checking.  It would not have surprised me if I had overlooked 
something in the software.  When doing Scheme work especially, I find 
there is often something Guile provides as a built-in that I wasted time 
creating myself.



-- Aaron Hill



Re: Crescendo after custom dynamic marking

2021-12-12 Thread David Kastrup
Aaron Hill  writes:

> On 2021-12-12 3:19 pm, David Kastrup wrote:
>> and one could instead define it as
>> make-dynamic-script =
>> #(define-event-function (str) (ly:markup?)
>>(make-music 'AbsoluteDynamicEvent 'text str))
>
> Did you mean just markup? or is ly:markup? a special predicate?

Ouch.  Of course the former.

-- 
David Kastrup



Re: Crescendo after custom dynamic marking

2021-12-12 Thread Aaron Hill

On 2021-12-12 3:19 pm, David Kastrup wrote:

and one could instead define it as

make-dynamic-script =
#(define-event-function (str) (ly:markup?)
   (make-music 'AbsoluteDynamicEvent 'text str))


Did you mean just markup? or is ly:markup? a special predicate?


-- Aaron Hill



Re: Crescendo after custom dynamic marking

2021-12-12 Thread David Kastrup
Jean Abou Samra  writes:

> Le 12/12/2021 à 22:52, Lukas-Fabian Moser a écrit :
>> Hi Jean,
>>
>>> Use a real dynamic script. These care care of spacing for you.
>>>
>>> \version "2.22.1"
>>>
>>> psubito =
>>> #(make-dynamic-script #{ \markup { p \normal-text \italic "subito" } #})
>>>
>>> { d'16_\psubito \cresc \repeat unfold 14 d'16 d'\f | }
>>
>> 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))
>>
>> {
>>   c\dynamic sfpmf
>>   c\dynamic \markup { \normal-text \italic subito f }
>> }
>
>
>
> I was thinking exactly along the same lines ;-)
>
> I would approve a patch adding this function.

One could cheat: make-dynamic-script is currently defined as

#(define (make-dynamic-script str)
   (make-music 'AbsoluteDynamicEvent
  'text str))

and one could instead define it as

make-dynamic-script =
#(define-event-function (str) (ly:markup?)
   (make-music 'AbsoluteDynamicEvent 'text str))

which would retain the old functionality while also providing

\make-dynamic-script

which of course does not follow naming conventions.  Sigh.  At any rate,
it should be defined using define-event-function rather than
define-music-function .

-- 
David Kastrup



Re: Crescendo after custom dynamic marking

2021-12-12 Thread Jean Abou Samra

Le 12/12/2021 à 22:52, Lukas-Fabian Moser a écrit :

Hi Jean,


Use a real dynamic script. These care care of spacing for you.

\version "2.22.1"

psubito =
#(make-dynamic-script #{ \markup { p \normal-text \italic "subito" } #})

{ d'16_\psubito \cresc \repeat unfold 14 d'16 d'\f | }


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))

{
  c\dynamic sfpmf
  c\dynamic \markup { \normal-text \italic subito f }
}




I was thinking exactly along the same lines ;-)

I would approve a patch adding this function.

Best,
Jean



Re: Crescendo after custom dynamic marking

2021-12-12 Thread Lukas-Fabian Moser

Hi Jean,


Use a real dynamic script. These care care of spacing for you.

\version "2.22.1"

psubito =
#(make-dynamic-script #{ \markup { p \normal-text \italic "subito" } #})

{ d'16_\psubito \cresc \repeat unfold 14 d'16 d'\f | }


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))

{
  c\dynamic sfpmf
  c\dynamic \markup { \normal-text \italic subito f }
}

Lukas




Re: Crescendo after custom dynamic marking

2021-12-12 Thread Jean Abou Samra




Le 12/12/2021 à 21:24, Ahanu Banerjee a écrit :

Hello,

When creating a crescendo following a custom dynamic marking (e.g., 
piano subito), I am having trouble moving the start of the spanner to 
a point following the dynamic markup.


What would be the best way of doing this? Example below. Thanks!

\version "2.20.0"
{ d'16_\markup { \dynamic p \italic "subito" } \cresc \repeat
unfold 14 d'16 d'\f | }





Use a real dynamic script. These care care of spacing for you.

\version "2.22.1"

psubito =
#(make-dynamic-script #{ \markup { p \normal-text \italic "subito" } #})

{ d'16_\psubito \cresc \repeat unfold 14 d'16 d'\f | }


See
https://lilypond.org/doc/v2.22/Documentation/notation/expressive-marks-attached-to-notes#index-make_002ddynamic_002dscript-1

Regards,
Jean



Crescendo after custom dynamic marking

2021-12-12 Thread Ahanu Banerjee
Hello,

When creating a crescendo following a custom dynamic marking (e.g., piano
subito), I am having trouble moving the start of the spanner to a point
following the dynamic markup.

What would be the best way of doing this? Example below. Thanks!

\version "2.20.0"
{ d'16_\markup { \dynamic p \italic "subito" } \cresc \repeat unfold 14
d'16 d'\f | }

-Ahanu