Erik Sandberg <[EMAIL PROTECTED]> writes:
> Citerar Graham Percival <[EMAIL PROTECTED]>:
>
>> In Geoff's defense, this kind of construct _is_ more complicated (to
>> an end-user) than it needs to be -- why the define-music-function,
>
> I agree. The topic pops up often enough to prove that the syntax
> _does_ scare away users from using music functions. Even if users
> "shoudln't need" to be prohibited by the syntax, they are.
> Something like this can very easily be constructed with existing
> lilypond. It sacrifices flexibility (you can only use music
> parameters),
I've made some quick satistics on LilyPond music functions and mine: 33%
of music functions have only music arguments. Music functions with
markup arguments for instance, or strings, are usual. What are you
proposing for the 67% other cases? The way the LilyPond parser is made,
you still have to declare at some point what type the arguments should
have. No surprise here: there is nothing superfluous in
define-music-function.
> but is easier to
> use and to understand:
>
> foo = #(music-function 3 %{ c4 #1 r8 #2 g16 #3 %})
> (foo takes 3 music parameters, #1 #2 and #3).
Supposing that you meant something possible iso %{ and #n, it's still
a scheme expression, with a syntax no less ugly than the existing
one. People are complaining about having to use Scheme to make advanced
things. sigh.
>> That said, my opinion is that users can live with it. Do the blind
>> copy-and-paste thing; change the "TextScript" to "DynamicLineSpanner"
>> or whatever you need; it's not a big deal.
>
> I don't want to cut and paste things I don't understand; when I was
> new to lily
This is not about copy-and-pasting something that you don't
understand. This is about copy-and-pasting something that you could not
have made by yourself, trying to change it to make it work for you. The
first time you don't understand the details, the second maybe not, but
at some time you get it. Practicing is this called?
My point is that flexibility should not be sacrificied. And I don't see
the advantage of having a second zone music function definer, just for
music functions with music arguments. At some point you still want to
define a music function with a numeric or string argument. Obviously
if the docs on define-music-function suck, that can be remedied.
If someone is still reading this thread, and has an example of a
specific task that s-he would like to solve with a music function,
without finding out how, s-he could expose it here, and I'll use this
material to write examples in the docs.
nicolas
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
