lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bends: pre-implementation issues


From: Marc Hohl
Subject: bends: pre-implementation issues
Date: Mon, 04 Jan 2010 13:38:32 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

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?

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

e4 \bend f \bend e2

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

Thanks in advance

Marc




reply via email to

[Prev in Thread] Current Thread [Next in Thread]