Define absolute-dynamics as a customizable event-function

Define absolute-dynamics as a customizable event-function

This commit adds a \dynamic command that
- defines new dynamics in a easy way
- allows to specify an optional MIDI volume
- checks user-specified dynamics against
lists of known dynamics, and issues warnings
if the entered dynamic cannot be rendered in
MIDI, or looks unusual.

\dynamic is also used as a markup command, but since the new
command lives in a different scope there is no conflict AFAICS.

A new dynamic-string markup command has also been added,
in order to parse the string argument given to \dynamic.
This command accepts plain dynamics as well as text indications and
composite indications mixing dynamics, text and punctuation.

(See https://codereview.appspot.com/2220041 for a previous attempt.)

[dak, 2013-11-01 11:24:36]

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly
File ly/dynamic-scripts-init.ly (right):

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:7: #(define safe-dynamics ; see midi.scm
What's "safe" about them?

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:37: (map (lambda (str)
for-each if you don't want to return a value.

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:39: (ly:format "\"~a\" = \\dynamic \"~a\"" str str)))
Ugh.  I mean, really really ugh.

Why not use ly:parser-define! here?

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:66: ; we can.
You could just dig through the markup and see whether you find a \dynamic-string
inside.  That's not likely helpful for instructions like "definitely not ff",
but seems better than nothing.

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:79: (display "tataaaa :"))
I don't think that kind of output is usual for LilyPond.

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:89: (_ "Dynamic \"~a\" does not have an acceptable
volume: ~a") arg vol)))
Excessive output, isn't it?

https://codereview.appspot.com/20660044/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/20660044/diff/1/scm/define-markup-commands.scm...
scm/define-markup-commands.scm:2716: The dynamic font is only used in words that
contain no other
This is just too ugly and unreliable as an interface.

[Valentin Villenave, 2013-11-01 16:14:27]

Cleaning up (but there’s some work left)

[Valentin Villenave, 2013-11-01 16:23:38]

Slight update; thanks for your patience (I’ve never been good at this but now
I’m also quite a bit rusty).

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly
File ly/dynamic-scripts-init.ly (right):

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:37: (map (lambda (str)
On 2013/11/01 11:24:36, dak wrote:
> for-each if you don't want to return a value.

Done.

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:39: (ly:format "\"~a\" = \\dynamic \"~a\"" str str)))
On 2013/11/01 11:24:36, dak wrote:
> Why not use ly:parser-define! here?

Indeed! I had been dabbling with
(let ((sym (string->symbol (primitive-eval str)))
                 (def #{ \dynamic $str #}))
    `(define-public ,sym ,def)))
     ls))
but this is the way do go. Thanks!

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:66: ; we can.
On 2013/11/01 11:24:36, dak wrote:
> You could just dig through the markup and see whether you find a
\dynamic-string
> inside.  That's not likely helpful for instructions like "definitely not ff",
> but seems better than nothing.

In which case I’d forget about adding a markup command, and do everything in
here. Can’t it make the code unnecessarily heavy? (Side question: if we go this
way, is it really worth keeping all this as a .ly file rather than putting it in
scm/ ?)

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:79: (display "tataaaa :"))
On 2013/11/01 11:24:36, dak wrote:
> I don't think that kind of output is usual for LilyPond.

OMG. Done.

https://codereview.appspot.com/20660044/diff/1/ly/dynamic-scripts-init.ly#new...
ly/dynamic-scripts-init.ly:89: (_ "Dynamic \"~a\" does not have an acceptable
volume: ~a") arg vol)))
On 2013/11/01 11:24:36, dak wrote:
> Excessive output, isn't it?

I added these messages because of Carl’s suggestion a couple of years ago:
https://codereview.appspot.com/2220041/#msg4

Not really sure if we want to hold the user’s hand that much (removing it
altogether would make the code considerably lighter).

https://codereview.appspot.com/20660044/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/20660044/diff/1/scm/define-markup-commands.scm...
scm/define-markup-commands.scm:2716: The dynamic font is only used in words that
contain no other
On 2013/11/01 11:24:36, dak wrote:
> This is just too ugly and unreliable as an interface.

Can you elaborate? (Not the ugly part, that I get; but how you would do it if
anything?)