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

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 2/7/10 2:48 AM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:

> 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.

I did not imagine using bend as a span event.  I imagined using it as an
event on each note that needed to be bent, like a string-number event.

So it would be 

c4 d\bend e\bend f\bend

This seems more right to me, but I can't give strong reasons for it.  I do
have an argument for extensibility below.

>> 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.

That's the key question -- is this approach extensible in the future?

The only approach that I'm positive is extensible in the future and to any
construct is to have \bend have an argument containing a pitch, which would
be the amount a pitch should be bent by:

c4 d\bend #'(ly:make-pitch 0 1 0) e\bend #'(ly:make-pitch 0 2 0) f\bend
#'(ly:make-pitch 0 3 0)

This kind of approach would work in chords; we could easily write

<c\bend #'(ly:make-pitch 0 1 0) e\bend #'(ly+make-pitch 0 1 0)>4

or perhaps even 

<c e>4 \bend #'(ly:make-pitch 0 1 0)

But this syntax is awful and unworkable.

Hence my thought of creating bendMusic expressions.

We might be able to make \bend take an optional pitch argument, so that if
there were no pitch argument it would use the base_note_ variable to
calculate the amount of bend.  This seems promising to me, but I don't know
how it would be implemented in the parser.  But it does argue for having
\bend be an event per note, rather than a span event.

I think for right now, as a working approach, go with what works.  If there
are extensibility issues, we cross that bridge when we get there.
>> 
>>  
>>> [...]
>>> 
>>> 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?

That sounds like a good idea.  And as we got closer, if you wanted to, you
could announce the patches on -devel to get ideas from other developers,
instead of just me and Neil.

Thanks,

Carl


---
----
Join the Frogs!