May I respectfully agree with the premise, but disagree with the
conclusion. Everything can be done in Scheme, I guess that this
is clear at this stage. After all, significant parts of Lilypond are
entirely written in this language.
However, Scheme is a sometimes arcane language.
Did not LISP stand for Lots of Insane Stupid Parenthesis ? If Lisp
(or Scheme, or even ML) is your computing lingua franca, I guess
you feel perfectly ok with Scheme. My understanding of Scheme is at
best cultural, and while I can decypher existing Scheme code in Lilypond
without too much trouble, it is also very clear to me that writing this
kind of stuff requires far more proficiency than what I can show, and
even more importantly, a deep understanding of Lily's internals,
My question - I would not dare call it a request... - was related to
something I see as very unsophisticated. My belief, and a number of
messages on this mailing list seem to agree with me on this matter -
is that a simplistic function-like facility would prove immensely
useful, even for users who are not committed up to a point where Scheme
becomes a viable option. In other words, IMHO, this function/macro/routine/
template stuff ought to be part of Lilypond, just as << \\ >> is a
shorthand for something more arcane. It would be a way of making Lilypond
even more usable to describe music in a structure and abstract way, which
is, in my view, its more important asset.
I do understand however that implementing this might not be a simple
task at all. This is why I am trying to see what might be a reasonable
set of simplifying assumptions that would make a basic version of such
a feature reasonably easy to provide, leaving more sophisticated stuff
to Scheme.
As an interesting meta-question, I always wondered in how far Lilypond
users were software people, or at least, technically oriented people.
Everytime I show my score to a musician, he/she
finds them beautiful - and, as a matter of principle, I never use anything
but Lilypond's default - and asks for more information about the software
I use. Then, after showing Lilypond and its input format,
depending on whether he/she is computer literate, I am told
that I spend too much time with computers (which is obviously
true) or that I come from a different planet altogether (which is
perhaps true as well :-) )
Cheers,
Darius.
Quoting Nicolas Sceaux <[EMAIL PROTECTED]>:
> Tue, 3 Feb 2004 15:58:07 +0100, Han-Wen a dit :
>
> > [EMAIL PROTECTED] writes:
> >> A cheap functionality, which would prove very useful in
> >> practice, would be the ability to declare Lilypond stuff
> >> in scheme, as in:
> >>
> >> (map myfunc {\notes { a b c d | a b c d}})
> >>
> >> which would be equivalent to:
> >>
> >> tempvar0981 = \notes { a b c d | a b c d}
> >>
> >> (map myfunc tempvar0981)
> >>
> >> Since we already have the ability to declare
> >> Scheme stuff within LilyPond, allowing for the
> >> reverse might be enough for most applications....
> >>
> >> Is this just nonsense, or is this reasonable to implement
> >> (I don't know whether one can plug language extensions in
> >> GUILE...) ?
>
> > I don't know how it can be done. Perhaps our Scheme macro expert can
> > chip in some ideas. Nicolas?
>
> sorry for the delay, I was not at home.
>
> What is easy, is to write a set of scheme operators that would reflect
> common LilyPond commands, for instance:
>
> (context-property-override Voice Stem thickness 2.0)
> ==> \property Voice.Stem \override #'thickness = #2.0
>
> or: (skip "1.*4/3") ==> s1.*4/3
> etc.
>
> Actually, I have started to build such a library on a per need basis
> for my scores. I am considering contributing a complete set of these
> scheme operators, aiming at programatically building any music
> expressions.
>
> As for reading a lilypond expression in scheme, it is not trivial. I
> once tried to hack my lilypond-program so that the lilypond-language
> compiler could be called within scheme via a call to a C function in a
> lily shared library, without real success. I didn't know enough of
> lilypond internals.
> It is feasible, however, but when I discovered
> what the \apply command could do, I definitely got rid of the idea of
> using lilypond expression in scheme. \apply is enough -- if you don't
> have to call a function with several music arguments. Some kind of
> multi-arguments apply would be cool.
>
> \apply-3 #bass-part
> { ...bass notes... }
> { ...figures... }
>
> > In the meantime, you can achieve the same thing with apply, albeit a
> > little more verbose
>
> > \apply #(lambda (m)
> > ..more stuff.. )
> > \notes { a b c d | a b c d}
>
> What could be also usefull is some specialized mapping functions:
>
> \apply #(lambda (music)
> (map-if mus:note?
> (lambda (note) (..do something on a note..))
> music))
> \notes { a b c d | a b c d}
>
> where `map-if' would look deeply into `music', and for each element
> satisfying the predicate (eg. `mus:note?') would apply the function
> on it.
> Oh, this is not very beautiful for a LilyPond score... macrology may
> help:
>
> \apply #(with-note-mapping (note)
> (..do something on a note..))
> \notes { a b c d | a b c d}
>
> etc.
>
> nicolas
>
>
>
>
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
_______________________________________________
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
