Re: Transposing in modes??

[Johannes Schindelin]

Hi,

On Thu, 16 Feb 2006, Erik Sandberg wrote:

> On Wednesday 15 February 2006 03.49, Johannes Schindelin wrote:
> > Hi,
> >
> > I always wanted to learn how to transform music with scheme, so I
> > implemented half of it. If some of you experts could look at it and tell
> > me what could be done more elegantly (Scheme is not my native language),
> > and especially what needs to be done to make this easy to use, that would
> > be super!
> 
> In addition to Han-Wen's comments, I can say the following:

Completely forgot: Thank you, Han-Wen!

> Vectors, while constructs and side effects are not encouraged in Scheme; 
> lists and tail recursion are the preferred way of doing things. In 
> general, functions ending with ! should be avoided whenever possible. 
> This is just a convention, there is no penalty in performance or 
> anything like that, so there's no big point in rewriting your existing 
> code other than for educational purposes.

Yes, I remembered that much from when I was forced to program in Lithp ;-) 
However, in this case I wanted to do an indexed lookup, so the vector is 
probably the right thing to do.

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).

> - 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.

Note: If it wasn't for the darned locrian scale, I would not need the 
source mode at all (and therefore would not validate it anyway). Maybe I 
return to that approach and just ignore locrian (source) modes.

Completely different question: I wanted to convert all this into a proper 
music function. In the course, I found that the signature parsing is 
less-than-elegant. In particular, there are only a handful permitted 
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 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 }

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.

Ciao,
Dscho