Re: [tablatures] bends: pre-implementation issues

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 1/4/10 5:38 AM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:

> Hello all,
> 
> 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?

Yes, you will need to add something to the parser, I believe.  It's because
bends need to be spanners (they connect notes, so they cover multiple
moments).

> 
> If this is true, it yields to the second question. Would it be better to
> create three new commands, like \bend, \releaseBend and \preBend, or to use
> one indicator/command and let lilypond decide what to do?
> 

I don't know enough about your plans to be able to answer this.

> I see two possible solutions: either
> 
> e4 \bend f \releaseBend e2
> 
> or
> 
> e4 ^ f ^ e2
> 
> The "^" sign isn't mandatory, but it would make sense, as the output looks
> similar in this case. The form
> 

I'm sorry, but you can't use ^.  That's already used to place markups,
slurs, ties, etc. in an up direction.



> e4 \bend f \bend e2
> 
> isn't not as easy to understand for the code reader.
> 

I think you ought to come up with something that is an "enclosure" type of
element, like slurs.  Perhaps something like ^( ^) (but I don't know if that
will work in the parser or not).

On the other hand, if a bend is always between two notes, something like a
tie symbol may work.   You might consider ~^ to be a bend between two notes..



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

You can do whatever you want in engravers.  I'm sure that you can make this
stuff work, but the exact mechanism isn't clear to me now, because I don't
have a picture in my mind of what you want the notation to look like.

Thanks,

Carl