On 8/14/08 11:16 AM, "Valentin Villenave" <[EMAIL PROTECTED]> wrote:
>
> Well, had I known it would make your day, I'd have spent less time
> looking at your code and asked my question sooner :-)
>
But looking at the code and hacking something together is what made your
question very useful!
>> If you really want to do this (why would users want to have values
>> greater than 1 or less than -1? I don't know harp music, so I can't say),
>
> You have a point. However, what Reinhold proposes is even sexier (see below).
>
I agree.
>> This requires you to use lambda expressions, which are kind of confusing.
>
> Are lambda expressions related to
> http://en.wikipedia.org/wiki/Lambda_calculus?
>
> If so, I have to confess I kinda gave up every time I tried to read
> the Wikipedia page... :(
Well, they're probably related to lambda calculus, but I don't understand
lambda calculus enough to do anything with it.
In my opinion, calling it lambda(x) makes it way hard for users to
understand. In my mind, I substitute temporary_function for lambda, and
then it makes sense to me
(temporary_function(adjustable-arg) (my-procedure adjustable-arg fixed-arg1
fixed-arg2)) makes a bit more sense to me. It's a way to call a procedure
with some fixed arguments and one (or more) variable arguments.
So if I say
(map ((lambda (x) (my-procedure x arg2 arg3)) mylist)
I get a result that is
(list
(my-procedure (list-ref mylist 1) arg2 arg3)
(my-procedure (list-ref mylist 2) arg2 arg3)
...
(my-procedure (list-ref mylist (length mylist)) arg2 arg3))
So lambda is really useful for doing something to every item in a list.
>> At the time I wrote fret-diagrams, constants like 4, 2, and 0.4
>> were frowned upon. So I used variables connected to properties
>> every time I needed a constant like this, and there was concern about
>> polluting the property name space, so I created fret-diagram-details.
>
> Yes indeed.
>
>> Also, LilyPond coding standards call for using full words rather than
>> abbreviations for variable names. x, y, a, b and so forth should only
>> be used as part of a lambda function definition.
>
> Actually, d c b and so on referred to the note of the pedals.
So you may want to use variables d-pedal, c-pedal, b-pedal, etc. It's not
the note that the variable is referring to, but the desired "status" of the
pedal.
>
>> I think the easiest and most Scheme-like way would be to loop through the
>> seven entries of the pedal list using recursive calls of a named let
>> clause... In particular:
>
> The problem is that the pedal boxes are not evenly spaced (there are
> three on one side, four on the other).
>
This should not be a problem. You just need to get the start position
(which I think you've already done) and then add an increment for each
pedal.
>> Actually, each entry in a harp diagram can only have three values, so I don't
>> like numeric representations too much (internally, lilypond uses integers for
>> directions, but that is hidden from the user as much as possible by #UP etc.
>> I don't think the users should be exposed to numbers as directions in harp
>> diagrams). What I was thinking of was a rough textual representation of the
>> states:
>> \harpPedals #"^--|v-^-" such a string with one letter per pedal is much
>> easier
>> to parse.
>
> This is just awesome! Can it be handled by pure Scheme though, or does
> this need to be dealt with on the C++ side?
Pure Scheme will do it -- no need to touch C++ as long as you only want to
use markups.
If you eventually want to get a context (like the FretBoards context),
you'll need to modify the parser and write some C++. But I think the
FretBoards context can serve as a pattern ...
Thanks for stirring the pot. I hope you have some harp pedals soon!
Carl
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user