Re: bends: pre-implementation issues

[Han-Wen Nienhuys]

On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl <address@hidden> wrote:
> I plan to work on the emplementation of bends for lilypond. Some preliminary
> tests with scheme were successful, so I want to go to the next stage soon
> and
> create some new engravers. But there are still some unsolved issues.
>
> But first, a brief explanation for all non-guitarists out there:
> a band is achieved by pressing down a string and moving it along the frets.
> The string gets bend, and the resulting tone gets higher. There are three
> variants:
> 1) the bend (or bend up): plucking the string, then doing the bend
> 2) release bend: plucking a already bent string. Sounds like a reverse bend.
> 3) pre bend: bend the unplucked string, pluck afterwards. Mostly (but not
> always)
> followed by a release bend.
>
> [Tablature guys: if I have missed something important, please join in and
> correct me!]
>
> In normal staves, bends are indicated by pointed slurs: "^"
> In tab staves, bends are indicated by arrows which start parallel to the
> staff lines
> and go upwards until they point perpendicular to the staff lines. The bend
> amount
> is indicated by numbers.
>
> As bends are musically and technically some sort of slurs, I think the
> best way to implement them is mainly to copy the slur engraver code and to
> adapt it properly. Internally, slurs cannot be created via
>
> slur = (make-music 'SlurEvent)
>
> so with bends, I have to add the commands to the parser. Is this correct?

Initially, you can define the appropriate events in
define-music-types.scm, and use an identifier to access them; see

  ly/declarations-init.ly

for examples on how to instantiate them.

You should focus on building the backend formatting before worrying
about the syntax.  It is ok to launch the feature with an experimental
syntax for one release or so, so don't worry about getting the syntax
right, as experimenting with syntax is the easy part.

You are worrying about the engravers, but in reality engravers are
simple classes which just connect grobs together, and the real
difficulty is in writing the formatting code that manipulates the
grobs.

Do not use the slur code for creating the bends.  Slurs have many
graphic peculiarities, and you will spend needless energy in switching
off the slur behavior.  The real question you need to resolve first is
item vs. spanner, i.e. if you have  a bend like this:

 <<
      { c4\bend d4\release }

      { f8 g8  a8 b8 }
 >>

will the bend traverse the 8th note to reach up to the following 4th
note (the D)?  Or is its shape more or less fixed?

> isn't not as easy to understand for the code reader.
>
> As I am not at all familiar with engravers, I have a last question
> concerning the
> capabilities of engravers:
>
> sometimes there are situations where bends are "concatenated", i.e.
>
> e4 \bend f \bend g \release e
>
> or
>
> e4 \bend g \release f \release e
>
> Can the engraver "foresee" when it is working on the e-g part that there are
> *two*
> release bends afterwards? Or in the former case, can the g-e release part be
> told
> that there were two bends upwards?
> (The slur engraver cannot do this, I know, but I want to know whether it is
> technically possible to store information of previous or following engraving
> actions, so they can influence the engraving process? I tried to use
> booleans
> while playing around with bends and scheme, but this didn't work very
> well/at all).

As said, the engravers are just for setting up grobs, and engravers
receive information in time-order, ie. when receiving the event for
the first bend, the engraver does not know about the 2nd bend.  Of
couse, you can alter the 1st bend on receiving the 2nd bend, but the
administration involved may be tricky, as it needs to work correctly
in polyphonic situations too, like the example I quoted above.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen