Enhancement: string bends (issue216051)

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

Enhancement: string bends (issue216051)

Neil Puttock

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)

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

---
----
Join the Frogs!

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

Re: Enhancement: string bends (issue216051)

Marc Hohl
Hello Neil,

[hidden email] 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!
>
>


---
----
Join the Frogs!

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

Re: Enhancement: string bends (issue216051)

Neil Puttock
On 20 February 2010 18:34, Marc Hohl <[hidden email]> 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

---
----
Join the Frogs!

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

Re: Enhancement: string bends (issue216051)

Marc Hohl
Neil Puttock schrieb:
> On 20 February 2010 18:34, Marc Hohl <[hidden email]> 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
>
>  


---
----
Join the Frogs!

Loading...