Re: Transposing in modes??

[Erik Sandberg]

On Thursday 16 February 2006 18.40, Johannes Schindelin wrote:
> Hi,
>
> Next thing I'll do: Learn how to do tail recursion (I think I did that in
> Lisp already, but don't remember how).
>
> > (fold (lambda (x y tail) (cons (- x y) tail)) '() list1 list2)
>
> I didn't know that function (fold).

It's a handy function that handles the tail recursion for you.

> > - if it's essential for performance that a vector is used (i.e. if you
> > use direct indexing, rather than linearly searching the list) then the
> > list can be converted to a vector after it has been created.
>
> Problem is: I want to warn if a note was not translated, because it is not
> in the original mode. Example: you want to translate { c4 c e e g g e2 }
> to \minor, but mistakenly said that the source mode was \dorian. Then the
> "e"s would not be in the source mode. So I actually construct a
> translation mechanism for semitones.

You can use arbitrary functions as arguments to fold. It might be sufficient 
to replace the (cons (- x y) tail)) with a more complex expression, such as 
the essential parts of the while loop. E.g., you could have a look at the 
(begin ..) function.

> signatures, which are hard-coded, such as "scm-scm-music". I gather that
> this is needed in order to use flex/bison, but the different combinations
>  of up to, say, 5 parameters could at least be generated, no?
>
> In other words, would you gurus of lily look kindly upon an effort to
> simplify the signature parsing?

I think I could clean up the code quite much, it shouldn't be very difficult, 
using one token type per arity. The hard part is if we want to make an 
_arbitrary_ number of parameters possible (I think it's possible, but a bit 
dirty -- AFAICS it requires that the parser sends faked argument separation 
tokens to itself sometimes).

> I also found out -- the hard way -- that a definition like
>
>       (def-music-function blabla (parser location key music)
>               (ly:pitch? ly:music?) (...))
>
> gets a signature "scm-music", which is wrong. Of course, I want to call
> this function like in this manner:
>
>       \blabla fis \relative c' { c d e f g }

The problem is that the parser can't distinguish between fis (pitch) and fis 
(music expression). Further problems could arise in this case:
\blabla fis 4
is this a pitch followed by a number, or is it a single music expression 
(fis4)?

> Is my idea faulty? I do not particularly like scheme, as you might have
> noticed, but at least it provides a good means to extend LilyPond without
> recompiling it, and what is more important, in a form easily distributed
> to others. But I still want to write the music using LilyPond syntax.

I'm looking into a way to create a language using def-music-function and 
friends, in lilypond-style syntax (this would be a third party package, which 
probably wouldn't be bundled with lilypond). However, I need to do a few 
generalisations to the parser before I can write such package, and those 
changes might not make it into the official lilypond distribution.

-- 
Erik