Re: [frogs] bend implementation

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 2/2/10 1:34 PM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:

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

Well, I could be wrong on all this.  But \startBend comes *after* the c that
is the unbent note.  So the bend engraver would need to look backwards in
time to get the unbent note, which seems to me to be a difficult thing to
do.  Iterators move forward in time, not backward in time.

Secondly, the \startBend syntax doesn't allow for a prebend.

But 

c \bend d { e d}

allows me to do a pre bend without printing the note.

It's not so much the syntax that I'm talking about here; it's the music
structures I'm thinking about.  Just like there is RelativeOctaveMusic that
contains a bunch of note-events, I'm thinking that BendMusic could contain a
bunch of note-events, as well as a reference pitch.

It might be possible to do \bend similar to \relative, where with \relative
if you don't specify a pitch, the first pitch in the \relative music is the
reference pitch.

\bend {c d e f}

would do an unbent c, followed by a bent d, e, and f.

In contrast

\bend c {d e f} 

would do a prebend from c to d, then do a bent d, e, and f.

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.

HTH,

Carl


---
----
Join the Frogs!