Re: Harp Pedals?

[Carl D. Sorensen]

On 8/14/08 10:56 AM, "Reinhold Kainhofer" <address@hidden> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Donnerstag, 14. August 2008 schrieb Valentin Villenave:
>> 2007/7/8 Dewdman42 <address@hidden>:
>>> I can't seem to find anything in the Lilypond manual about creating harp
>>> pedal symbols.  I would think this issue has been covered a lot by users
>>> of Lilypond.  how do I do it, or something like it:
>>>
>>> http://www.nabble.com/file/p11492013/ScreenHunter_03%2BJul.%2B08%2B12.40.
>>> jpg
>>
>> I've been trying to implement this harp diagrams feature for a while,
>> but my implementation is quite dirty and not fully working.
>
> Nice to see that I'm not the only one interested in implementing harp pedal
> diagrams
> (http://www.mail-archive.com/lilypond-devel%40gnu.org/msg15542.html).
>
>> Basically,
>> I tried to write a markup command that would take seven arguments, one
>> for each pedal. However, for some reason I cannot pass more than three
>> arguments to the markup command (see below).
>>
>> 1 - What I'd really like to achieve is to have one single argument
>> containing the whole set of pedals, like you do with your diagrams,
>> such as
>> \harp #"0;-1;0;1;0;0;1;"
>> instead of
>> \harp #0 #-1 #0 #1 #0 #0 #1
>>
>> However, I cannot parse the string to extract the values (I've tried
>> to figure it out from your code, but it's way over my skills).
>
> I'll try to come up with a proper parser.
>
>> 2 - The implementation I provide is very dirty, as I said. [...]
>> and  inside the function I don't know how I can increment the values for
>> the horizontal placement of the boxes in an elegant way.
>
> 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:
>
> (let process-pedal ((remaining-pedals initial-pedals)
>                             (xpos 0))
>     ; print the box for the (car remaining-pedals)
>     ;
>     ; now call the process-pedal loop with the cdr (unless we are finished)
>     ;
>     (if (not (empty? (cdr remaining-pedals)))
>       (process-pedal (cdr remaining-pedals) (+ xpos width-of-this-pedal))
>     )
> )

This is a nice Scheme-like way to do it.  However, the problem is that you
can't just do a recursive call.  You have to do a stencil-add for each
pedal.  And you can't have a null list as an argument to stencil-add.

So one way out of the problem is a look-ahead to see if
the _next_ element is
the last element; your recursive function then looks like:

  (if (next-element-is-last)
      (ly:add-stencil (make-stencil current-pedal)
                      (make-stencil (cadr remaining-pedals)))
      (ly:add-stencil (make-stencil current-pedal)
         (process-pedal (cdr remaining-pedals)...))

The key here is that you can't just return a stencil (which would be very
easy to do recursively); you need to return an add-stencil function.

I used code like this in the fret-diagrams module.

Another way to do it, while less Scheme-like, is more straightforward.
You initialize the stencil with the first element, then do a set! for
the rest of the elements.  Abelson and Sussman would have a heart attack
about doing it, but this seems to be the LilyPond way of doing it.
LilyPond is full of set! assignments.


However, I can see that you (Reinhold) are a better LilyPond programmer
than me, so you may know how to do it better than I do.  Feel free to ignore
anything I say.


>
> 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. Of course, we can have two versions, a terse one with #"^--|v-^-"
> and a "normal" one with "1;0;0;-1;0;1;0". That's just a matter of two
> different string parsers before the same function is called, similar to the
> fret-parse-definition-string function and the subsequent call to the function
> that really generates the fret diagram.

If I were you, I'd avoid having multiple syntaxes.  I did it in fret
diagrams because I came up with the normal syntax and implemented it, then
Han-Wen wanted a list-based syntax to be compatible with the normal LilyPond
structure (everything is lists) so I came up with verbose, and users
proposed the terse format because it was easier to enter.

If I were starting from scratch, I would have only the terse format for
markups, and the list format for internal LilyPond grob calls.  I would not
have a list-based markup interface; it's not useful for users in my opinion.
I would not need the "normal" interface, because now I know how to set all
the desired fret-diagram properties using override, instead of putting them
in the markup string.  If you look, you'll see that I used the
fret-diagram-terse format for all of the user interface in the
predefined-diagram code, and the alist format for the grob properties.

I'd recommend that you think about a format string that will have all the
capability needed for harps and be easy for users to understand.  Based on
what I've seen proposed so far, I'd recommend your terse format.  And for
future compatibility I'd recommend that your markup function parse the
string to a list, and pass the list to a list-based routine, so if it's
desirable to later add a HarpPedals context you're ready to do so.

Thanks for listening,

Carl