Re: [frogs] Music expressions and iterators (was: bend implementation)

[Marc Hohl <marc@xxxxxxxxxx>]

Neil, Carl, thanks for your explanations.

Carl Sorensen schrieb:
> [...]
> After crawling around through the source code, I decided that Neil was
> right, and it would be better to just create a string-bend-event after each
> note.
>
> So if you have a String_bend_engraver, it can catch each note-event, and
> each string-bend-event.
>   
So my first approach can be extended?

So, for clarification, what I already did was as follows:

1) created a new event type in ly/declarations-init.ly:

startBend = #(make-span-event 'StringBendEvent START)
stopBend = #(make-span-event 'StringBendEvent STOP)

2) added string-bend-event to list of span-events in 
scm/define-event-classes.scm

3)  added the StringBendEvent to scm/define-music-types.scm:

   (StringBendEvent
    . ((description . "Start or end a string bend.

Syntax: @var{note}@code{\\startBend} and @var{note}@code{\\stopBend}")
   (types . (general-music span-event event string-bend-event))
   ))

4) created a file lily/strng-bend-engraver.cc with mostly empty definitions
just to get the infrastructure.

Then I am able to do something like

c4 \startBend d e f \stopBend

and this compiles witout an error (and wihout a visible difference to c4 
d e f, of course).

I am not sure whether I am right, but I tried to do it the way slurs are 
integrated, so I
thought that the \startBend will add the make-span-event call to the 
previous note, i.e. the c;
so c is the first note that is "seen" by the engraver, and f being the last.

> If there is no string-bend-event, then the engraver sets base_note_ (a
> private variable of the string-bend-event engraver).
> Also, if the note_event_ has a grace_part, (i.e. it's a grace note), then
> set a private variable pre_bend_ to true. Otherwise, we set pre_bend_ to
> false.  The engraver also kills the existing bend-spanner grob if it exists,
> and starts a new bend-spanner grob.
>
> If there is a string-bend-event, then we calculate the bend relative to
> base_note_, and use that to adjust the tab-note-head.
>
> We also finish and publish the bend-spanner grob.  We then start a new
> bend-spanner grob.
>
> Note that we don't reset base_note_, because we're still bending from the
> original base note.
>   
Yes, I understand that.
> I think this will take care of all the bends that don't exist in chords, and
> I think you can start there.
>   
I am not sure how this should be handled generally - glissandos don't work
in chords either, and perhaps the right way to do this is to use seperate
voices in cases where some notes sound unbent while one string is bent -
but if this approach is extensible in the future anyway and we don't 
have to redo the whole
thing, I probably don't have to care about this right now.
>   
> > [...]
> >
> > Moreover, how can I let the engraver do its work on the structure? Via
> > the elements-callback?
> >     
>
> I don't recommend that you take this path any more.  I'm sorry for the
> confusion.  But let me answer this question, for the record rather than for
> this particular application.
>
>   
Thanks for your explanations - everything becomes clearer again ;-)
> But again, as Neil said, don't mess with this right now.  We'll approach the
> chord/non-chord stuff a bit later.
>   
Ok. How should I proceed with that? I think it would be easier for you 
and me
if I create patches that aren't meant to be pushed but to simplify the 
exchange of
ideas. Should I push to rietveld *without* announcing lilypond-devel, so 
you can easily
comment the whole thing?


Marc


---
----
Join the Frogs!