Re: Harp Pedals?

[Carl D. Sorensen]

On 8/14/08 11:16 AM, "Valentin Villenave" <address@hidden> 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