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

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 2/6/10 1:17 AM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:

> Carl Sorensen schrieb:
>> [...]
>> 
>> I'm not positive this is the right way, but I think it's getting closer. And
>> I think that defining a BendMusic or BentMusic music expression is the best
>> way I've thought of yet to get bends in the music tree.
>>  
> I have looked at scm/define-music-types.scm where all music expressions
> are defined.
> As I see it now, a StringBendMusic music expression should be much like the
> SequentialMusic music expression which an additional 'referencePitch
> that holds
> the reference pitch which the engraver uses to get the information of
> how the current
> note is bent relative to this value.

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.

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.

I think this will take care of all the bends that don't exist in chords, and
I think you can start there.


> 
> Looking at the definition for SequentialMusic, I find
> 
>     (SequentialMusic
>      . ((description . "Music expressions concatenated.
> 
> Syntax: @code{\\sequential @{ @dots{} @}} or simply @code{@{ @dots{} @}}")
>     (length-callback . ,ly:music-sequence::cumulative-length-callback)
>     (start-callback . ,ly:music-sequence::first-start-callback)
>     (elements-callback . ,(lambda (m) (ly:music-property m 'elements)))
>     (iterator-ctor . ,ly:sequential-iterator::constructor)
>     (types . (general-music sequential-music))
>     ))
> 
> I think the start-callback is executed each time lilypond enters the
> music expression.
> I am not sure what the length-callback does - does he calculate the
> length of whole expression?
> The elements-callback seems to filter the 'elements in the
> SequentialMusic tree via the
> lambda construct and acts upon its values.
> The iterator-ctor is some kind of constuctor which iterates over the
> music tree. I looked
> at lily/sequential-iterator.cc but didn't understand a lot.
> 
> Do I have to understand all this in order to go on with bends, or is it
> sufficient to copy most
> of the structures?
> 
> 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.

Where an iterator-ctor is defined, it's necessary to make a file
lily/*-iterator.cc.  This routine is responsible for iterating through the
structure, and passing events that are part of the structure (obtained using
the elements-callback procedure.

You can see all of the iterators by

ls lily/*-iterator.cc

Also, a lily/include/*-iterator.hh will need to be defined, so the
constructor can be public.

But again, as Neil said, don't mess with this right now.  We'll approach the
chord/non-chord stuff a bit later.

HTH,

Carl


---
----
Join the Frogs!