lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial


From: David Kastrup
Subject: Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Date: Thu, 07 Jun 2012 06:31:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> So please, try again.  This time picking something that actually
> solves a task in LilyPond.
>
> Something like
> Documentation/snippets/adding-extra-fingering-with-scheme.ly (which
> actually does a ridiculous amount using Scheme rather than #{...#} but
> let's just assume that as a given).
>
> Or how would you write something like
>
> applyMusic =
> #(define-music-function (parser location func music) (procedure? ly:music?)
>    (_i"Apply procedure @var{func} to @var{music}.")
>    (func music))
>
> in LilyPond/D?  How would you call it from LilyPond?
>
> In the snippets I see the following (it is actually rather awful code:
> one would use music-is-of-type? rather than memq, and of course it does
> not do to copy all properties rather than just those supported by
> SkipEvent, namely duration and articulations).

The following being
#(define (notes-to-skip m)
  "Convert all stuff with duration (notes, lyrics, bass figures, etc.) to skips.
Scripts and dynamics are maintained.
"
  (if (memq 'rhythmic-event (ly:music-property m 'types))
   (let* ((newmus (make-music 'SkipEvent)))
    (map
     (lambda (x) (ly:music-set-property! newmus (car x) (cdr x)))
     (ly:music-mutable-properties m))
    newmus
  )
   m)
)


\layout { ragged-right= ##t }

foobar =  \transpose c c' { c4\>-^ c4-^ c4\!-^ c4-^  }


\relative c''  \context Voice {
  \foobar

  << \applyMusic #(lambda (x) (music-map notes-to-skip x))
     \foobar
     { d8 d d d d d d d  } >>
}

from input/regression/music-map.ly.

> But notes-to-skip is, in itself, general purpose programming.  That's
> not the interesting part.  The interesting part is how to tie things
> together, so assume that the function is already given.
>
>> This is a bit of an unfair case because it's obviously a function
>> where imperative programming is probably better suited.
>
> It is a bit unfair since you have not even _tried_ creating a LilyPond
> document where this function is defined and used.  You have created a
> scrap of source code dangling in the air.  That is not the hard part
> about an extension language.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]