bends: pre-implementation issues

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bends: pre-implementation issues

Marc Hohl
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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

David Stocker-2
Just to let you know, I have another round of graphics almost ready to
go (promised last week). I just need to finish up a few notes on some of
the examples.

David

Marc Hohl 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?
>
> 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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Carl Sorensen
In reply to this post by Marc Hohl



On 1/4/10 5:38 AM, "Marc Hohl" <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Marc Hohl
In reply to this post by Marc Hohl
Han-Wen Nienhuys schrieb:

> On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl <[hidden email]> 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.

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.

Thanks

Marc




bendtest.pdf (74K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Marc Hohl
In reply to this post by Carl Sorensen
Carl Sorensen schrieb:

>
> On 1/4/10 5:38 AM, "Marc Hohl" <[hidden email]> wrote:
>
>  
>> {[..]
>>
>> 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).
>  
Ok.
>  
>> 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 attached an example to my answer to Han-Wens mail. In measures
1 to 6, the is a bend/release bend combination, measure 7 is bend up
only, measure 9 is a single pre bend, and measure 10 is a pre bend followed
by a release bend.

The usage code in ly files should be easily understandable, so
I think I'll vote for \preBend, \bend and \releaseBend, but I don't know
if it is
wise to define three parser commands if there is a possibility of using
only one
(see below).

>  
>> 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.
>  
Yes, of course. It was just meant as a simple abbreviation.
Perhaps \^ might do the job? I mean, if I can use a symbol, then
I think it would be best to use *one* symbol for the whole bend stuff,
but if I have to use a word as a command, then I'd prefer to
use three different commands.
>
> 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.
>  
A bend will definitely be always between two notes.
>  
>
> 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.
>  
Perhaps it is a bit clearer now (?), but David will post some more
sophisticated examples of what should be doable with bends, so
perhaps clarification will have to wait until then.

Thanks

Marc



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Marc Hohl
In reply to this post by Marc Hohl
Oops, I just sent a mail with an attachment that seems to be too big
for -devel, I don't know where the limits are for the tablature list.
I'll upload it to my homepage:

http://www.hohlart.de/marc/bendtest.pdf

Marc


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

David Stocker-2
In reply to this post by Marc Hohl


Marc Hohl wrote:

> Carl Sorensen schrieb:
>>
>> On 1/4/10 5:38 AM, "Marc Hohl" <[hidden email]> wrote:
>>
>>  
>>> {[..]
>>>
>>> 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).
>>  
> Ok.
>>  
>>> 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 attached an example to my answer to Han-Wens mail. In measures
> 1 to 6, the is a bend/release bend combination, measure 7 is bend up
> only, measure 9 is a single pre bend, and measure 10 is a pre bend
> followed
> by a release bend.
>
> The usage code in ly files should be easily understandable, so
> I think I'll vote for \preBend, \bend and \releaseBend, but I don't
> know if it is
> wise to define three parser commands if there is a possibility of
> using only one
> (see below).
>>  
>>> 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.
>>  
> Yes, of course. It was just meant as a simple abbreviation.
> Perhaps \^ might do the job? I mean, if I can use a symbol, then
> I think it would be best to use *one* symbol for the whole bend stuff,
> but if I have to use a word as a command, then I'd prefer to
> use three different commands.
>>
>> 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.
>>  
> A bend will definitely be always between two notes.
 From a notational standpoint, this is not absolutely true. Some
quarter-tone bends are written on the note staff as a note followed by a
symbol that looks like a doit, and on the tab staff with a bend up arrow
with the "1/4" designation. It's intended usage is to convey a bend of
indeterminate pitch change less than 1/2 step -- a prevalent feature of
Blues and Blues-inspired idioms. I haven't put that example in the
second batch of examples, so I'll make a note to put one in the third batch.

>>  
>> 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.
>>  
> Perhaps it is a bit clearer now (?), but David will post some more
> sophisticated examples of what should be doable with bends, so
> perhaps clarification will have to wait until then.
Hope to have them done and posted tonight.
>
> Thanks
>
> Marc
David
>
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: bends: pre-implementation issues

Carl Sorensen
In reply to this post by Marc Hohl



On 1/4/10 12:29 PM, "Marc Hohl" <[hidden email]> wrote:

> Han-Wen Nienhuys schrieb:
>> On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl <[hidden email]> 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.

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.

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.

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.

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

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: bends: pre-implementation issues

Marc Hohl
Carl Sorensen schrieb:

>
> On 1/4/10 12:29 PM, "Marc Hohl" <[hidden email]> wrote:
>
>  
>> Han-Wen Nienhuys schrieb:
>>    
>>> On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl <[hidden email]> 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
>
>
>  



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: bends: pre-implementation issues

Carl Sorensen



On 1/4/10 3:28 PM, "Marc Hohl" <[hidden email]> wrote:

> Carl Sorensen schrieb:

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

A quarter-tone bend should just be an articulation on the note, it seems to
me.  But this could also be handled in the bend engraver.

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

Sounds like a good idea to me.

>
> Thanks for your ideas!


You're welcome.

Carl



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Patrick Horgan
In reply to this post by Marc Hohl
Marc Hohl 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.
You leave out the common case of a release bend without a pluck,
following a bend.  It's common in blues for example, to pluck, bend up a
whole step, then back down a half step without an intervening pluck, for
example leaving the string bent (and then of course shaking it all
around).  How would you notate that?
     _
    /  \ ~~~~~~~~~ note the ascii art won't work so well if you have
variable width chars;)
__/  

Patrick



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Marc Hohl
Patrick Horgan schrieb:

> Marc Hohl 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.
> You leave out the common case of a release bend without a pluck,
> following a bend.  It's common in blues for example, to pluck, bend up
> a whole step, then back down a half step without an intervening pluck,
> for example leaving the string bent (and then of course shaking it all
> around).  How would you notate that?
>     _    /  \ ~~~~~~~~~ note the ascii art won't work so well if you
> have variable width chars;)
> __/
> Patrick
Thanks for your hint! I wasn't referring to all possibilities, but
mainly the three fundamental parts
which can be combined to more complex bend fingures.

I would notate this as

e \bend fis \release f

(durations aside).

Thanks,

Marc
>
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Marc Hohl
In reply to this post by Marc Hohl
Han-Wen Nienhuys schrieb:
> I am confused here.  Are you trying to implement the symbols that are
> on the tab staff, or on the normal notation?
>  
Both. But first, I want to concentrate on the pointed slurs in the
normal notation,
make that the default for normal staves *and* tablature and then (as
tablature will
be changed to "numbers only" in ly/engraver-init.ly) overwrite the
engraver to
produce the arrows instead of the pointed slurs.

Would it be a sensible option to create a new slur style and activate it by

\override Slur #'style = #'pointed

or something similar? Then most parts of the slur computation
routines hadn't to be duplicated, just extended to draw pointed slurs.

Marc

> On Mon, Jan 4, 2010 at 5:44 PM, Marc Hohl <[hidden email]> wrote:
>  
>> Oops, I just sent a mail with an attachment that seems to be too big
>> for -devel, I don't know where the limits are for the tablature list.
>> I'll upload it to my homepage:
>>
>> http://www.hohlart.de/marc/bendtest.pdf
>>
>> Marc
>>
>>    
>
>
>
>  



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: bends: pre-implementation issues

Carl Sorensen



On 1/5/10 12:36 PM, "Marc Hohl" <[hidden email]> wrote:

> Han-Wen Nienhuys schrieb:
>> I am confused here.  Are you trying to implement the symbols that are
>> on the tab staff, or on the normal notation?
>>  
> Both. But first, I want to concentrate on the pointed slurs in the
> normal notation,
> make that the default for normal staves *and* tablature and then (as
> tablature will
> be changed to "numbers only" in ly/engraver-init.ly) overwrite the
> engraver to
> produce the arrows instead of the pointed slurs.
>
> Would it be a sensible option to create a new slur style and activate it by
>
> \override Slur #'style = #'pointed
>
> or something similar? Then most parts of the slur computation
> routines hadn't to be duplicated, just extended to draw pointed slurs.

I wouldn't recommend doing that as a way to start, because bend indications
always go between two sequential notes, and slurs can span as many notes as
desired.

For hacking on it, when you don't have a bend_engraver to create a different
kind of spanner, I can see that torturing the slur_engraver can be helpful.
But if you look at David's sheet, you'll see that sometimes bends are
enclosed inside of slurs, so losing the slur to the bend is probably not a
good approach.

Thanks,

Carl



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

Marc Hohl
In reply to this post by Marc Hohl
Han-Wen Nienhuys schrieb:

> On Tue, Jan 5, 2010 at 5:36 PM, Marc Hohl <[hidden email]> wrote:
>  
>> Han-Wen Nienhuys schrieb:
>>    
>>> I am confused here.  Are you trying to implement the symbols that are
>>> on the tab staff, or on the normal notation?
>>>
>>>      
>> Both. But first, I want to concentrate on the pointed slurs in the normal
>> notation,
>> make that the default for normal staves *and* tablature and then (as
>>    
>
> I wouldnt bother with the slurs at all, not in the last part because
> your bends will likely break if someone ever decides to refactor the
> slur code.
>  
Ok.
> Just write a simple grob that is composed of two line segments to make
> the pointed bend.  Have you already thought of how the spanner should
> behave when it crosses a line break?  
@ David: Can you give us a small example of how a bend across a line
break would look like?

(I know that strings can break after excessive bends, but that's another
issue :-)


>
> You'll probably need entirely different code for the tab version,
> including different grob code, and a different engraver.  I recommend
> worrying about that once the pointed-brace version is completely
> working.
>  
Yes, I didn't plan to do all at once, but I wanted to show where the
road will
eventually lead to.

Thanks for your hints!

Marc



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bends: pre-implementation issues

David Stocker-2


Marc Hohl wrote:

> Han-Wen Nienhuys schrieb:
>> On Tue, Jan 5, 2010 at 5:36 PM, Marc Hohl <[hidden email]> wrote:
>>  
>>> Han-Wen Nienhuys schrieb:
>>>    
>>>> I am confused here.  Are you trying to implement the symbols that are
>>>> on the tab staff, or on the normal notation?
>>>>
>>>>      
>>> Both. But first, I want to concentrate on the pointed slurs in the
>>> normal
>>> notation,
>>> make that the default for normal staves *and* tablature and then (as
>>>    
>>
>> I wouldnt bother with the slurs at all, not in the last part because
>> your bends will likely break if someone ever decides to refactor the
>> slur code.
>>  
> Ok.
>> Just write a simple grob that is composed of two line segments to make
>> the pointed bend.  Have you already thought of how the spanner should
>> behave when it crosses a line break?  
> @ David: Can you give us a small example of how a bend across a line
> break would look like?
>
> (I know that strings can break after excessive bends, but that's
> another issue :-)
I will try to get something out within the next 48 hours.

>
>
>>
>> You'll probably need entirely different code for the tab version,
>> including different grob code, and a different engraver.  I recommend
>> worrying about that once the pointed-brace version is completely
>> working.
>>  
> Yes, I didn't plan to do all at once, but I wanted to show where the
> road will
> eventually lead to.
>
> Thanks for your hints!
>
> Marc
>
>


Loading...