Re: [tablatures] Re: bends: pre-implementation issues

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

Carl Sorensen schrieb:


On 1/4/10 12:29 PM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:


Han-Wen Nienhuys schrieb:

On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl <marc@xxxxxxxxxx> wrote:

[...]

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.

Ok, thanks for the hint!

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.

To be honest: I do not worry about the engravers alone, I am
frighened by the whole task, but I need bends, so ...

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?

Sorry for not having an example attached. As I said, bends are
just a special case for slurs, and I defined a scheme function which uses
the control points for the bezier curve (let's call them z1, z2, z3 and z4),
computes the point in the middle between z2 and z3 (z23) and draws a line
from z1 to z23 and from z23 to z4. The slur routine takes care of all stems,
accidentals and stuff, so it seemed natural to me to use this code as a
base.
Please look at the attached pdf, especially pointed slurs in the normal
staves.

(At first, I tried to implement bends only with scheme, but there are
problems
arising when a bend is followed by a "real" slur, so I decided to do it
in a cleaner way.)

By the way: what is the difference between a spanner and an item? I strongly
feel bends *must* be spanners, but honestly, I don't know the reason.


A spanner has a start event and an end event, and covers the time in between
those events.

Thanks for explanation, this is quite identical to what I assumed,
but brought into a clear shape.

Nearly all of the bends that you have drawn must be spanners, I think.

I'm curious about measures 8 and 9 of the example you posted.  In the first
beat of each note, you have a grace note bent up to a note.  In measure 8,
the grace and the note have a different horizontal position in the tab; in
measure 9 they have the same horizontal position.

Measure 8 is a bend which is audible (kind of grace note, the stem is
missing - this is probably an error in my definitions), while measure 9 shows 
a pre bend. The string is bent before plucking it, so it sounds at the
higher pitch.

As I look at this notation more clearly, it seems that the amount of bend is
an attribute of a note.  You might consider just specifying the string and
fret of a note, and then given a string tuning, string, and fret, the amount
of bend can be calculated.

Hm, never thought of that. I would have implemented it as a function
of the surrounding notes, i.e. the note where it starts and the note
it reaches, but your approach may be able to cover blues bends as well.
But I have to take into account the duration of the bent note.

As I implemented it via scheme, I used the spanner bounds of a slur
to calculate the right amount automatically. So actually, I code
\bendOn c\5 ( d\5 ) \bendOff
for a bend.

Bend curves could then be drawn between successive notes at the same fret on
the same string, and the amount of bend can be calculated automatically.
With that kind of architecture, you'd just have the bend engraver catch 
notes, and it would spit out a spanner whenever the string and fret were the
same and the note differed.

This is fairly similar to how the autobeam engraver works.  It checks a
note, and provisionally starts a beam.  If the beam shouldn't be created, it
junks it.

This mechanism could come in handy especially when bends are hold.
For example, in measure 9, there is a pre Bend, in measure 10 there is
a pre bend followed by a release bend. With your mechanism, I could
draw the horizontal line just in case, and if there is no release, I'll junk it. 
So what would happen in the beam engraver is that every note would be
caught, along with its fret and string.  The note, fret, and string would be
stored in internal variables.  Then, if the note is different, but the fret
and string are the same, a bend would be engraved.  Otherwise, the previous
bend would be junked.
Once the disposition of the previous potential bend has been completed, a
new bend would be started, with the note, fret, and string of the current
note.  This bend could either be finished or junked according to the next
note.

An alternative way to handle the bend is to just add an optional bend amount
to the note (the default of which would be zero).  Then you'd have a similar
algorithm, but with slightly different details.

Get a note.  If the string and fret are the same, but the bend is different,
finish and print the bend.  Otherwise, junk the bend.

Then, start a new bend with the given string, fret, and bend.


But to answer your question: there are situations where two strings are
plucked
together, the lower one being bent, while the other one sounds unchanged for
the whole duration.
[...] 
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.

Hm. Another possibility would be to leave it to the user to draw.
consecutive bends etc. by overriding some properties. Then,
it would be cleaner to use different commands for bend and
release bend.


With the architecture above, I don't think you need to specify bend and
release bend.  All of the bends you show have a note at each end of the bend
(either a real note or a grace note).

Yes, but there are quarter tone bends, as David pointed out, which aren't
followed by a note. But perhaps they should be handled seperately.
Lilypond does provide doits and falls, so perhaps these features have only to 
be adapted for tablature. On the other hand, when there is a consistent
approach for handling all cases, it should be bundled together.
I'll wait for David's work on bend constellations and try to make a list of all relevant combinations/cases. Perhaps the situation can be clarified thereafter. 

Thanks for your ideas!

Marc

You'd also need to have the note engraver somehow decide whether or not to
parenthesize the notehead.  This could be done by saving the last fret,
string, and bend inside the tabnote engraver.

HTH,

Carl

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