Re: [frogs] bend implementation

[ Thread Index | Date Index | More lilynet.net/frogs Archives ] 

Carl Sorensen schrieb:


[...]

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. 
Wow. Then I misunderstood your proposals and comparisons in terms of
handling bends similarly to  the autobeaming mechanism. No, wait -
I misinterpreted it and went too far with the similarities. I think I understood 
the autobeaming comparison, but with beams, I had the [ ... ] construct
in mind and thought I should handle bends in a similar manner which means
defining a range of notes which should be handled by the engraver and *not*
coding the bends manually between *every* pair of notes.

 And
I think that is the reason you're having a problem making this work.
No, I don't have problems (yet) - all I did was to enable some infrastructure 
according to Han-Wens proposals (how to define a new event class etc.).
My engraver does nothing at the moment because I still try to understand the
principles - at least there I seem to be on the right track (see your comments below). 
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)
This seems not to be very useful - I wanted to let lilypond do the work, i.e. 
computing the bend amount, deciding whether the bend arrow points
upwards or downwards (in case of tablature, of course), and this is what you
proposed with your "autobend" approach, isn't it?

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.


But then, what's the difference between

c \bend c { d e f }
where the second c resembles the note from which the bend amount is calculated, 
and my

c\startBend d e f\stopBend

where the first c is used a) to print the note c and b) to tell the
engraver that everything following the c is to be considered as a bent note,
relative to the c? Ok, it's another syntax form and I am unsure which is better (for example, what would be the cleverest way to code a pre bend in both approaches?) 
but the fundamental principle is the same in my opinion.


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, [...]

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.

Great! I seem to understand :-)

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.


Trying to read some lily/*-engraver.cc files, I found the
acknowledger approach.

I look forward to input from others.

Thanks for your answers!

Marc


---
----
Join the Frogs!

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/