Enhancement: string bends

Enhancement: string bends

First steps: a new event called string-bend-event is instantiated
  and a new engraver is established which does nothing at the moment.
  Hopefully this will change soon ;-)

The main roadmap is in the (temporary) file bend-implementation-roadmap.txt
where I collected the main ideas and conclusions of former discussions.

[Neil Puttock, 2010-02-20 17:01:12]

http://codereview.appspot.com/216051/diff/1/2
File bend-implementation-roadmap.txt (right):

http://codereview.appspot.com/216051/diff/1/2#newcode21
bend-implementation-roadmap.txt:21: c4 d\bend
I see why you want to use this syntax, but it goes against the convention for
postfix notation.  Since you're creating a spanner, one would expect the \bend
command to follow the c4 (like a glissando or tie)

Furthermore, it's rather inefficient since it requires the engraver to cache
every note in case a string-bend-event arrives at the next timestep.

http://codereview.appspot.com/216051/diff/1/3
File lily/string-bend-engraver.cc (right):

http://codereview.appspot.com/216051/diff/1/3#newcode21
lily/string-bend-engraver.cc:21: #include "international.hh"
insert

#include "spanner.hh"

http://codereview.appspot.com/216051/diff/1/3#newcode33
lily/string-bend-engraver.cc:33: virtual void finalize();
finalize ()

http://codereview.appspot.com/216051/diff/1/3#newcode95
lily/string-bend-engraver.cc:95: "String_bend ",
StringBend

http://codereview.appspot.com/216051/diff/1/5
File ly/script-init.ly (right):

http://codereview.appspot.com/216051/diff/1/5#newcode14
ly/script-init.ly:14: bend = #(make-music 'StringBendEvent)
This should go in declarations-init.ly or property-init.ly (it's not really
clear which, since we have several similar make-music definitions in both files)

[marc, 2010-02-20 18:34:45]

Hello Neil,

n.puttock@gmail.com schrieb:
>
> http://codereview.appspot.com/216051/diff/1/2
> File bend-implementation-roadmap.txt (right):
>
> http://codereview.appspot.com/216051/diff/1/2#newcode21
> bend-implementation-roadmap.txt:21: c4 d\bend
> I see why you want to use this syntax, but it goes against the
> convention for postfix notation.  Since you're creating a spanner, one
> would expect the \bend command to follow the c4 (like a glissando or
> tie)
I don't know whether you followed the discussion between Carl and me 
closely,
but we ended up making \bend an *articulation* of a note (I wanted to 
use \bend
as a spanner, but Carl convinced me not to do so). The main advantage is
- as far as I can see - that it is possible to play intermediate notes 
between two
bent notes by using the string information without explicitly creating 
spanners
which would mean to use separate voices for each separate string involved.

But I think Carl can explain this far better than me...
>
> Furthermore, it's rather inefficient since it requires the engraver to
> cache every note in case a string-bend-event arrives at the next
> timestep.
Does this influence the performance very much? The engraver looks for a
bend-event and saves a pitch information when there is none, otherwise
he draws the bend.

>
> http://codereview.appspot.com/216051/diff/1/3
> File lily/string-bend-engraver.cc (right):
>
> http://codereview.appspot.com/216051/diff/1/3#newcode21
> lily/string-bend-engraver.cc:21: #include "international.hh"
> insert
>
> #include "spanner.hh"
>
> http://codereview.appspot.com/216051/diff/1/3#newcode33
> lily/string-bend-engraver.cc:33: virtual void finalize();
> finalize ()
>
> http://codereview.appspot.com/216051/diff/1/3#newcode95
> lily/string-bend-engraver.cc:95: "String_bend ",
> StringBend
Ok.

The whole c++ story is still not very clear to me - I just wanted to get 
the basics
done, and still it looks as if the bend implementation is far from being 
settled down.
I pushed the patch as a discussion platform and furthermore, I want to
archieve consensus before going further - I don't want to write an 
engraver if it is
then told I should do it the other way.
>
> http://codereview.appspot.com/216051/diff/1/5
> File ly/script-init.ly (right):
>
> http://codereview.appspot.com/216051/diff/1/5#newcode14
> ly/script-init.ly:14: bend = #(make-music 'StringBendEvent)
> This should go in declarations-init.ly or property-init.ly (it's not
> really clear which, since we have several similar make-music definitions
> in both files)
Ok, I looked for "articulations" and placed the \bend definition there.
>
> http://codereview.appspot.com/216051/show
>
> ---
> ----
> Join the Frogs!
>
>

[Neil Puttock, 2010-02-20 22:04:10]

On 20 February 2010 18:34, Marc Hohl <marc@hohlart.de> wrote:

> I don't know whether you followed the discussion between Carl and me
> closely,

I tried to, though it was difficult keeping up. :)

> but we ended up making \bend an *articulation* of a note (I wanted to use
> \bend
> as a spanner, but Carl convinced me not to do so). The main advantage is
> - as far as I can see - that it is possible to play intermediate notes
> between two
> bent notes by using the string information without explicitly creating
> spanners
> which would mean to use separate voices for each separate string involved.

But you're bending (sorry :) the implementation of the (much simpler)
String_bend_engraver to suit features you require for a TabStaff,
which seems to me an unnecessary complication.

I definitely think you'd be better off using a music function to
delimit the start and end points, then you can send individual
string-bend-events as required (either directly in the music function,
or via an iterator).

> Does this influence the performance very much? The engraver looks for a
> bend-event and saves a pitch information when there is none, otherwise
> he draws the bend.

Probably not.

> I pushed the patch as a discussion platform and furthermore, I want to
> archieve consensus before going further - I don't want to write an engraver
> if it is
> then told I should do it the other way.

What other way?

You'll definitely have to write an engraver in C++, since it won't be
possible using a scheme engraver (you can't set spanner bounds in
scheme).

Regards,
Neil

[marc, 2010-02-21 09:47:18]

Neil Puttock schrieb:
> On 20 February 2010 18:34, Marc Hohl <marc@hohlart.de> wrote:
>
>   
>> I don't know whether you followed the discussion between Carl and me
>> closely,
>>     
>
> I tried to, though it was difficult keeping up. :)
>   
Yes, for me too.
>   
>> but we ended up making \bend an *articulation* of a note (I wanted to use
>> \bend
>> as a spanner, but Carl convinced me not to do so). The main advantage is
>> - as far as I can see - that it is possible to play intermediate notes
>> between two
>> bent notes by using the string information without explicitly creating
>> spanners
>> which would mean to use separate voices for each separate string involved.
>>     
>
> But you're bending (sorry :) the implementation of the (much simpler)
> String_bend_engraver to suit features you require for a TabStaff,
> which seems to me an unnecessary complication.
>   
I don't think so.
First, the String_bend_engraver will mostly be used in guitar-like 
situations
and in combination with a Tab Staff. Second, since it is important for 
the player to know
which string (s)he should bend, this information has to be in the input 
file as well.

> I definitely think you'd be better off using a music function to
> delimit the start and end points, then you can send individual
> string-bend-events as required (either directly in the music function,
> or via an iterator).
>   
Carl and I went through the whole story by trying to code some of
David Stocker's examples in the (not yet implemented) bend input
method, and the "articulation way" seemed to be the best solution.

At first sight, I thought about bends as simple spanners between two notes,
but as you can hold one string in a bent state, play another string, 
then pluck the
still bent string and do some more complicated stuff, we'll have to separate
different bend situations (which may happen simultaneously) by the string
on which they happen.

Then, semantically, a bend is some information about the style in which the
the note is played, therefore an articulation. You can pre-bend a string,
pluck it and dampen it again, so it will sound like a normal tone, but it is
handled in a special way, therefore articulated differently.

Another point is the simplicity of the usage. If you don't have chord 
constructs,
you can type c4 d\bend and get a bend from c to d. In cases where more 
than one string
is affected, the syntax is the same:

< c\2 e\1 >4 f\1\bend

e4\1  <c\2  f\1\bend>

or even

<c\2 e\1 >4 < d\2\bend f\1\bend>

(note that the bend amounts differ for the two strings!)

And coding hold-bend situations is easy:

c8\2 d\1 d\2\bend d\1 d\2\bend d1 \d2\bend

Here, the engraver should take care of the different strings for drawing the
spanners, so it needs the detailed information.
>   
>> Does this influence the performance very much? The engraver looks for a
>> bend-event and saves a pitch information when there is none, otherwise
>> he draws the bend.
>>     
>
> Probably not.
>
>   
>> I pushed the patch as a discussion platform and furthermore, I want to
>> archieve consensus before going further - I don't want to write an engraver
>> if it is
>> then told I should do it the other way.
>>     
>
> What other way?
>
> You'll definitely have to write an engraver in C++, since it won't be
> possible using a scheme engraver (you can't set spanner bounds in
> scheme).
>   
I didn't mean doing it in scheme, but as I am very unsure about and slow in
writing stuff in C++, I want to be sure I am on the right track, i.e. 
got the
right structures and algorithms before I start coding. For smaller projects
or in cases where I am familiar with the language, I can work the other way
though: hacking some lines, test it, dump it and start from scratch etc.,
but in bigger projects, I like to know (nearly) exactly what to do 
before I start.
So I want to get the input structure ready before starting on the 
engraver, so I didn't
have to rewrite everything from scratch because I missed something 
essential.
I know this slows things down, but that's the way I feel most comfortable.

Thanks,

Marc
> Regards,
> Neil
>
>   

[Carl, 2010-03-06 16:59:59]

Marc,

I'm sorry I was so slow on this.  My life has been crazy recently.

I think your work on this is headed down the right path.

Thanks,

Carl

http://codereview.appspot.com/216051/diff/1/2
File bend-implementation-roadmap.txt (right):

http://codereview.appspot.com/216051/diff/1/2#newcode43
bend-implementation-roadmap.txt:43: Step 1: Creating the basic infrastructure
Excellent!

http://codereview.appspot.com/216051/diff/1/2#newcode47
bend-implementation-roadmap.txt:47: Step 2: Building the StringBend engraver for
normal staves
Yes.  The string bend engraver creates the string bend indication as a spanner.

http://codereview.appspot.com/216051/diff/1/2#newcode56
bend-implementation-roadmap.txt:56: Step 4: Extending properties for TabNoteHead
No, we don't need a 'style property.  We have the bend amount as an articulation
or from a string-bend-event.  What would the style do

http://codereview.appspot.com/216051/diff/1/2#newcode59
bend-implementation-roadmap.txt:59: read the bend-reference-pitch vector
(provided by the
The bend-reference-pitch vector should be stored as a private member of the
Tab_note_heads engraver, rather than in the String_bend_engraver.

All the String_bend_engraver has to do is draw a pointy slur between two
note-heads, and the Tab_string_bend_engraver draws a curved arrow between two
tab-note-heads.

http://codereview.appspot.com/216051/diff/1/2#newcode65
bend-implementation-roadmap.txt:65: - provides the bend-reference-pitch vector
(TabStringBend #'bend-reference-pitch)
I don't think this is the right way to go.  The easiest thing to do is to store
the reference pitches in the Tab_note_heads engraver, since that engraver
already has to listen to the pitches and change the notes as necessary.

http://codereview.appspot.com/216051/diff/2001/2002#newcode95
bend-implementation-roadmap.txt:95: 
This seems reasonable to me.  You may want to have chord_bend_reference_pitches
and note_bend_reference_pitch

http://codereview.appspot.com/216051/diff/2001/2002#newcode135
bend-implementation-roadmap.txt:135: and if *every* TabNoteHead in a note column
has the style 'parenthezied, the
Yes, I agree with this change.  The TabNoteHeads engraver should just look for
bend-events in order to change the note head.

[marc, 2010-03-07 09:13:40]

Carl.D.Sorensen@gmail.com schrieb:
> Marc,
>
> I'm sorry I was so slow on this.  My life has been crazy recently.
No problem at all! I hope it's getting less crazy now ...
>
> I think your work on this is headed down the right path.
>
> Thanks,
>
> Carl
>
>
>
> http://codereview.appspot.com/216051/diff/1/2
> File bend-implementation-roadmap.txt (right):
>
> http://codereview.appspot.com/216051/diff/1/2#newcode43
> bend-implementation-roadmap.txt:43: Step 1: Creating the basic
> infrastructure
> Excellent!
>
> http://codereview.appspot.com/216051/diff/1/2#newcode47
> bend-implementation-roadmap.txt:47: Step 2: Building the StringBend
> engraver for normal staves
> Yes.  The string bend engraver creates the string bend indication as a
> spanner.
>
> http://codereview.appspot.com/216051/diff/1/2#newcode56
> bend-implementation-roadmap.txt:56: Step 4: Extending properties for
> TabNoteHead
> No, we don't need a 'style property.  We have the bend amount as an
> articulation or from a string-bend-event.  What would the style do
My annotation from feb 25 means the same - I think the 'style property
is superfluous.
>
> http://codereview.appspot.com/216051/diff/1/2#newcode59
> bend-implementation-roadmap.txt:59: read the bend-reference-pitch vector
> (provided by the
> The bend-reference-pitch vector should be stored as a private member of
> the Tab_note_heads engraver, rather than in the String_bend_engraver.
>
> All the String_bend_engraver has to do is draw a pointy slur between two
> note-heads, and the Tab_string_bend_engraver draws a curved arrow
> between two tab-note-heads.
Ok. I thought about situations like

 c d\bend ~ d\bend

where the pointed slur should not be drawn between the two d notes.
On the other hand, hold bend situations are done with consecutive
pre bends, so perhaps the string-bend-engraver has nothing to know
about pitches.
>
> http://codereview.appspot.com/216051/diff/1/2#newcode65
> bend-implementation-roadmap.txt:65: - provides the bend-reference-pitch
> vector (TabStringBend #'bend-reference-pitch)
> I don't think this is the right way to go.  The easiest thing to do is
> to store the reference pitches in the Tab_note_heads engraver, since
> that engraver already has to listen to the pitches and change the notes
> as necessary.
Hmmmm, I am not completely convinced. The direction of the bend arrows
depends on the pitches.

c d\bend is an arrow up,
c d\bend c\bend is an arrow up and an arrow down
etc.

What do you think?
>
> http://codereview.appspot.com/216051/diff/2001/2002#newcode95
> bend-implementation-roadmap.txt:95:
> This seems reasonable to me.  You may want to have
> chord_bend_reference_pitches and note_bend_reference_pitch
Ah, yes, good point!
>
> http://codereview.appspot.com/216051/diff/2001/2002#newcode135
> bend-implementation-roadmap.txt:135: and if *every* TabNoteHead in a
> note column has the style 'parenthezied, the
> Yes, I agree with this change.  The TabNoteHeads engraver should just
> look for bend-events in order to change the note head.
>
> http://codereview.appspot.com/216051/show
>
> ---
> ----
> Join the Frogs!
>
>

[c_sorensen, 2010-03-08 01:04:52]

On 3/7/10 2:13 AM, "Marc Hohl" <marc@hohlart.de> wrote:

> Ok. I thought about situations like
> 
>  c d\bend ~ d\bend
> 
> where the pointed slur should not be drawn between the two d notes.
> On the other hand, hold bend situations are done with consecutive
> pre bends, so perhaps the string-bend-engraver has nothing to know
> about pitches.


But isn't the reason we don't draw the pointed slur between the two d's is
because they're tied?  To me, that just means that we watch for ties, and
don't draw bend symbols.

>> 
>> http://codereview.appspot.com/216051/diff/1/2#newcode65
>> bend-implementation-roadmap.txt:65: - provides the bend-reference-pitch
>> vector (TabStringBend #'bend-reference-pitch)
>> I don't think this is the right way to go.  The easiest thing to do is
>> to store the reference pitches in the Tab_note_heads engraver, since
>> that engraver already has to listen to the pitches and change the notes
>> as necessary.
> Hmmmm, I am not completely convinced. The direction of the bend arrows
> depends on the pitches.
> 
> c d\bend is an arrow up,
> c d\bend c\bend is an arrow up and an arrow down
> etc.
> 
> What do you think?

I think that the information needed to draw the arrows is present in the
tabNoteHeads that are properly placed on the TabStaff.  Once the
TabNoteHeads are placed, it's pretty easy to tell the arrow direction,
because the arrow goes in the direction of the staff interval.  And the
grobs have a staff position, so we know what we need to do from the grobs,
without knowing the pitches.

HTH,

Carl

[marc, 2010-03-08 08:35:37]

Carl Sorensen schrieb:
>
> On 3/7/10 2:13 AM, "Marc Hohl" <marc@hohlart.de> wrote:
>
>   
>> Ok. I thought about situations like
>>
>>  c d\bend ~ d\bend
>>
>> where the pointed slur should not be drawn between the two d notes.
>> On the other hand, hold bend situations are done with consecutive
>> pre bends, so perhaps the string-bend-engraver has nothing to know
>> about pitches.
>>     
>
>
> But isn't the reason we don't draw the pointed slur between the two d's is
> because they're tied?  To me, that just means that we watch for ties, and
> don't draw bend symbols.
>   
I think you are right - as always ;-)

And if the user gives a non-musical input, then it is not necessarily
lilipond's task to get everything right.
>   
>>> http://codereview.appspot.com/216051/diff/1/2#newcode65
>>> bend-implementation-roadmap.txt:65: - provides the bend-reference-pitch
>>> vector (TabStringBend #'bend-reference-pitch)
>>> I don't think this is the right way to go.  The easiest thing to do is
>>> to store the reference pitches in the Tab_note_heads engraver, since
>>> that engraver already has to listen to the pitches and change the notes
>>> as necessary.
>>>       
>> Hmmmm, I am not completely convinced. The direction of the bend arrows
>> depends on the pitches.
>>
>> c d\bend is an arrow up,
>> c d\bend c\bend is an arrow up and an arrow down
>> etc.
>>
>> What do you think?
>>     
>
> I think that the information needed to draw the arrows is present in the
> tabNoteHeads that are properly placed on the TabStaff.  Once the
> TabNoteHeads are placed, it's pretty easy to tell the arrow direction,
> because the arrow goes in the direction of the staff interval.  And the
> grobs have a staff position, so we know what we need to do from the grobs,
> without knowing the pitches.
>   
Yes, of course! Stupid me ...

Thanks again for your comments. WIthin the next days, I will rewrite the 
roadmap
according to the informations I got from you and continue working on the 
engraver.

Greetings,

Marc
> HTH,
>
> Carl
>
>
>   

[marc, 2010-03-14 18:50:56]

Marc Hohl schrieb:
> [...]
>
> Thanks again for your comments. WIthin the next days, I will rewrite 
> the roadmap
> according to the informations I got from you and continue working on 
> the engraver.
I uploaded the changes in the roadmap to rietveld.

At the moment, I am short of time, so things go very slowly ...


http://codereview.appspot.com/216051/show


Marc

[marc, 2010-03-16 19:59:38]

I uploaded my latest version of string-bend-engraver.cc.

I think I am on the right track now, but I am not sure how to get
the bend-event stuff right. I have stored all bend-events
in bend_events_, but I have no clue how to assign these events
to the appropriate note_events.

I can check for bend_events_.size () > 0, but in case of chord
constructs, it is essential to get from e.g. < c\5 e\4\bend g\3 >4
the bend-event assigned to string-event 4. How can this be done?
I have tried to use a code similar to the articulation filtering
mechanism a couple of lines above, but this failed (or, more
obviously, I did some mistakes).

Thanks in advance for any hint,

Marc

http://codereview.appspot.com/216051/show

[Carl, 2010-03-17 16:43:19]

Inside a chord, the string numbers don't come as events, they come as
articulations on the note events.

I assume that the same will be true of \bend, once it's added to the parser.  It
will create a bendEvent if it's outside a chord construct, and an articulation
to the noteEvent if it's inside the chord construct.  That way, it's easy to
tell which note the bend applies to.

HTH,

Carl

[marc, 2010-03-17 19:12:27]

Carl.D.Sorensen@gmail.com schrieb:
> Inside a chord, the string numbers don't come as events, they come as
> articulations on the note events.
>
> I assume that the same will be true of \bend, once it's added to the
> parser.  It will create a bendEvent if it's outside a chord construct,
> and an articulation to the noteEvent if it's inside the chord construct.
>  That way, it's easy to tell which note the bend applies to.
Ah, I see. So I have to tell the parser how to handle \bend?

I thought this was already done by defining bend in ly/declarations-init.ly,
so lilypond does the right thing ...

Ok, so I'll try to find out how the parser works.

Thanks,

Marc

[c_sorensen, 2010-03-18 00:19:48]

On 3/17/10 1:12 PM, "Marc Hohl" <marc@hohlart.de> wrote:

> Carl.D.Sorensen@gmail.com schrieb:
>> Inside a chord, the string numbers don't come as events, they come as
>> articulations on the note events.
>> 
>> I assume that the same will be true of \bend, once it's added to the
>> parser.  It will create a bendEvent if it's outside a chord construct,
>> and an articulation to the noteEvent if it's inside the chord construct.
>>  That way, it's easy to tell which note the bend applies to.
> Ah, I see. So I have to tell the parser how to handle \bend?
> 
> I thought this was already done by defining bend in ly/declarations-init.ly,
> so lilypond does the right thing ...

It may do so.  I have not traced down this particular feature.  I'm
certainly not a parser expert.  I just assumed that you'd need to modify the
parser.

Maybe your understanding is correct.

Thanks,

Carl

[marc, 2010-03-21 13:28:12]

Carl Sorensen schrieb:
>
> On 3/17/10 1:12 PM, "Marc Hohl" <marc@hohlart.de> wrote:
>
>   
>> Carl.D.Sorensen@gmail.com schrieb:
>>     
>>> Inside a chord, the string numbers don't come as events, they come as
>>> articulations on the note events.
>>>
>>> I assume that the same will be true of \bend, once it's added to the
>>> parser.  It will create a bendEvent if it's outside a chord construct,
>>> and an articulation to the noteEvent if it's inside the chord construct.
>>>  That way, it's easy to tell which note the bend applies to.
>>>       
>> Ah, I see. So I have to tell the parser how to handle \bend?
>>
>> I thought this was already done by defining bend in ly/declarations-init.ly,
>> so lilypond does the right thing ...
>>     
>
> It may do so.  I have not traced down this particular feature.  I'm
> certainly not a parser expert.  I just assumed that you'd need to modify the
> parser.
>
> Maybe your understanding is correct.
>   
Hello Carl,

please review the current changes. IIUC, articulations can be
established by make-articulation, so perhaps I do not need
to change the parser.

By the way, if I uncomment the \displayMusic line in bend-test.ly,
lilypond aborts. I think I have to add bend to the music output routines,
but for the moment, everything looks very promising :-)

Marc

 http://codereview.appspot.com/216051

> Thanks,
>
> Carl
>
>
>   

[marc, 2010-03-21 17:12:33]

Marc Hohl schrieb:
> Carl Sorensen schrieb:
>>
>> On 3/17/10 1:12 PM, "Marc Hohl" <marc@hohlart.de> wrote:
>>
>>  
>>> Carl.D.Sorensen@gmail.com schrieb:
>>>    
>>>> Inside a chord, the string numbers don't come as events, they come as
>>>> articulations on the note events.
>>>>
>>>> I assume that the same will be true of \bend, once it's added to the
>>>> parser.  It will create a bendEvent if it's outside a chord construct,
>>>> and an articulation to the noteEvent if it's inside the chord 
>>>> construct.
>>>>  That way, it's easy to tell which note the bend applies to.
>>>>       
>>> Ah, I see. So I have to tell the parser how to handle \bend?
>>>
>>> I thought this was already done by defining bend in 
>>> ly/declarations-init.ly,
>>> so lilypond does the right thing ...
>>>     
>>
>> It may do so.  I have not traced down this particular feature.  I'm
>> certainly not a parser expert.  I just assumed that you'd need to 
>> modify the
>> parser.
>>
>> Maybe your understanding is correct.
>>   
> Hello Carl,
>
> please review the current changes. IIUC, articulations can be
> established by make-articulation, so perhaps I do not need
> to change the parser.
>
> By the way, if I uncomment the \displayMusic line in bend-test.ly,
> lilypond aborts. I think I have to add bend to the music output routines,
> but for the moment, everything looks very promising :-)
I had time to work a little bit more on this issue. I included a number of
"cout << ..." lines which seem to indicate that everything is fine.

Now (given that the engraver structure is ok) I have to include the actual
drawing routine. How do I tell the routine which note-events it should
use?
If I look at glissando-engraver.cc, I see a function called make_spanner,
but it is still mysterious to me how the function gets its starting
and ending points/events.
Any hints are more than welcome.

Thanks,

Marc
>
> Marc
>
> http://codereview.appspot.com/216051
>
>> Thanks,
>>
>> Carl
>>
>>
>>   
>
>
> ---
> ----
> Join the Frogs!
>
>

[Neil Puttock, 2010-03-22 23:12:45]

On 2010/03/21 13:28:12, marc wrote:

> please review the current changes. IIUC, articulations can be
> established by make-articulation, so perhaps I do not need
> to change the parser.

No.  While there's no need to change the parser, you'd only use
make-articulation if you were adding a new Script grob, with its properties set
in default-script-alist.

You're confusing an articulation (a Script) with the 'articulations music
property.  The parser adds an event to 'articulations whenever it finds a music
object following a note inside a chord.  Since this happens automatically, all
you have to do is define your \bend command using make-music: the parser will
decide whether to add the string-bend-event to 'articulations (inside < >) or
the 'elements property of the EventChord (outside a chord).

Regards,
Neil

[marc, 2010-03-23 06:53:16]

n.puttock@gmail.com schrieb:
> On 2010/03/21 13:28:12, marc wrote:
>
>> please review the current changes. IIUC, articulations can be
>> established by make-articulation, so perhaps I do not need
>> to change the parser.
>
> No.  While there's no need to change the parser, you'd only use
> make-articulation if you were adding a new Script grob, with its
> properties set in default-script-alist.
>
I understand.
> You're confusing an articulation (a Script) with the 'articulations
> music property.  The parser adds an event to 'articulations whenever it
> finds a music object following a note inside a chord.  Since this
> happens automatically, all you have to do is define your \bend command
> using make-music: the parser will decide whether to add the
> string-bend-event to 'articulations (inside < >) or the 'elements
> property of the EventChord (outside a chord).
Even better! SO the parser does all the work, and I don't have to bother 
- great.

Thanks,

Marc
>
> Regards,
> Neil
>
> http://codereview.appspot.com/216051/show
>
> ---
> ----
> Join the Frogs!
>
>

[marc, 2010-04-03 14:12:47]

Marc Hohl schrieb:
> [...]
> Now (given that the engraver structure is ok) I have to include the 
> actual
> drawing routine. How do I tell the routine which note-events it should
> use?
> If I look at glissando-engraver.cc, I see a function called make_spanner,
> but it is still mysterious to me how the function gets its starting
> and ending points/events.
It is still not clear to me how to proceed.
Assume I have a note-event in

bend_reference_events_[string_nr]

and a corresponding note-event in

note_events_[string_nr]

How do I call make_spanner? It should draw a spanner between
bend_reference_events_[string_nr] and note_events_[string_nr].

Any hints are welcome.

Thanks,

Marc

http://codereview.appspot.com/216051

[c_sorensen, 2010-04-09 00:50:02]

On 4/3/10 8:12 AM, "Marc Hohl" <marc@hohlart.de> wrote:

> Marc Hohl schrieb:
>> [...]
>> Now (given that the engraver structure is ok) I have to include the
>> actual
>> drawing routine. How do I tell the routine which note-events it should
>> use?
>> If I look at glissando-engraver.cc, I see a function called make_spanner,
>> but it is still mysterious to me how the function gets its starting
>> and ending points/events.
> It is still not clear to me how to proceed.
> Assume I have a note-event in
> 
> bend_reference_events_[string_nr]
> 
> and a corresponding note-event in
> 
> note_events_[string_nr]
> 
> How do I call make_spanner? It should draw a spanner between
> bend_reference_events_[string_nr] and note_events_[string_nr].
> 
> Any hints are welcome.

I've been really busy, and not had time to look this up at all, so I was
hoping somebody else would answer.  But since nobody has, I thought I'd tell
you what I've been able to find out.

I've been looking at lily/slur-engraver.cc.

In Slur_engraver::process_music(), line 187, a slur grob is created by
calling make_spanner.

In line 192, the slur is added to a vector of slurs.

In line 172-179, slurs are ended.

In Slur_engraver::stop_translation_timestep()

events are added to the encompass list for the active slurs.  I think this
gives the slur grob the info it needs to do the calculations.

I think this is the code that sets up the grob with all of its information.

lily/slur.cc is the c++ code (that is also exported to scheme) that does the
actual layout work.  You can see in that code that the encompassed columns
are available.

I think that what you need to do is at the time you create a bend_spanner,
you will pass in the start_note and the end_note.  Then at the time you want
to print the spanner, you will set the ends relative to the properties of
the start_note and the end_note.

I'm sorry I don't have a better answer for you than this.  I've never done
what you're doing.

HTH,

Carl