Re: [frogs] bend implementation

[Carl Sorensen <c_sorensen@xxxxxxx>]

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

> Trevor Daniels schrieb:
>> 
>> Marc Hohl wrote Tuesday, January 26, 2010 8:42 AM
>>> 
>>> I think there will be more questions arising during the work, mostly
>>> silly ones (from a programmer's point of view), so I wonder whether I
>>> should fill up the
>>> frogs list with these questions, or does it make more sense to handle
>>> this similar to
>>> Graham's mentor proposals, so I fill up the mail inbox of just *one*
>>> person ;-)
>> 
>> Far better to keep the discussion on the frogs list.  That way we
>> all learn and others are able to correct any misconceptions.  I've
>> learnt quite a lot thinking about questions posed on -frogs.
>> 
>> And please don't worry about asking questions you think might
>> be silly.  We all should be more willing to do this.  It's often the
>> silly questions that stump us the longest.
>> 
>> Trevor
>> 
>> 
>> 
> So here I am again. I have established a new string-bend-event
> by editing
> 
> scm/define-music-types.scm
> scm/define-event-classes.scm and
> ly/declarations-init.ly
> 
> Moreover, I created lily/string-bend-engraver.cc which has
> mostly empty function declarations in it.
> 
> So far, I can compile a file containing stuff like
> 
> c \startBend d e f \stopBend   %(1)
> 
> (It looks the same as c d e f, of course, but the infrastructure seems
> to be working.)
> 
> For clarification: the output of (1) should look like
> c /\ d /\ e /\ f
> with pointed slurs over (or under) the note heads. I don't want to code
> the string bends
> between every pair of notes, but rather mark a note range with
> \startBend ... \stopBend.

I think this is a fundamentally wrong way of approaching this problem.  I
don't think that \startBend ... \stopBend is the right way of doing it.  And
I think that is the reason you're having a problem making this work.

If you're not going to add a bend-event to each note, e.g.

c d\bend-1 e\bend-2 f\bend-2.5

(which I think doesn't work well, because decimal bends is not a good idea)

then it may be better to define a bentMusic event (similar to relative)

c \bend c {d e f}

where the c following \bend defines the unbent pitch, and d e and f are all
bent notes.

> 
> Now I looked at slur-engraver.cc, tie-engraver.cc, tuplet-engraver.cc and
> episema-engraver.cc (which is on rietveld, but it is a small file which
> I think I understand
> roughly). I wanted to find out what has to be acknowledged.
> 
> If I understand correctly, the engraver is called when \startBend is
> processed,
> and he does the stuff defined in String_bend_engraver::listen_string_bend..
> 
> Then I want the engraver to draw a pointed slur from the previous note
> (if there is any)
> to the current note. Therefore, I have to use the ACKNOWLEDGER mechanism.
> So I add (amongst the initialisation stuff)
> String_bend_engraver::acknowledge_note_column.
> The routines defined here are called at any time the spanner has not
> been terminated
> yet and a note_column is processes. Is this correct? From here, I get
> the info about the note heads.
> So if the d in example (1) is processed, I  can get information about it
> via this mechanism.
> 
> Then, process_music() is called, and that's the place for telling the
> engraver
> "hey, there is a new note; draw your pointed slur to the previous
> one, save the current note and go on."
> 
> Then, we are at note e, and there it goes again, acknowledge_note_column
> is called,
> process_music () afterwards, and so on, until we reach the f.
> 
> What I don't understand is the need for start/stop_translation_timestep
> (). Some
> engravers use the one, some the other function, but it seems that they
> aren't mandatory.
> Reading CG 9.9.2, it seems to be as follows:
> 
> * an event is read
> * the acknowledge_* (9 functions (if any) are called
> * start_translation_timestep () is called before doing any property
> operations,
> * then the property operations (if any) are done
> * process_music () is called
> * stop_translation_timestep () is called
> * the next event is read
> 
> Is this true?

Yes, this is true. In the case of the bend engraver, I'm not sure if
stop_translation_timestep will do anything.
> 
> One final question (for now). Is note_column appropriate in my approach?
> I am not sure
> whether I understand the difference between note_column and note_head
> correctly.
> note_column includes stems and in < ...> constructs all the
> corresponding note heads,
> is that right?

I think I would have listened for notes, instead of acknowledging note
columns.  I'm not sure what the practical difference is.

I look forward to input from others.

Thanks,

Carl


---
----
Join the Frogs!