Re: [frogs] Music expressions and iterators (was: bend implementation)

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 2/7/10 12:20 PM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:

> Carl Sorensen schrieb:
>> 
>> [...]
>>> 
>>> Then I am able to do something like
>>> 
>>> c4 \startBend d e f \stopBend
>>> 
>>> and this compiles witout an error (and wihout a visible difference to c4
>>> d e f, of course).
>>> 
>>> I am not sure whether I am right, but I tried to do it the way slurs are
>>> integrated, so I
>>> thought that the \startBend will add the make-span-event call to the
>>> previous note, i.e. the c;
>>> so c is the first note that is "seen" by the engraver, and f being the last.
>>>    
>> 
>> I did not imagine using bend as a span event.  I imagined using it as an
>> event on each note that needed to be bent, like a string-number event.
>>  
> But is my assumption concerning the spanner behavior right, even if we don't
> use bends as spanners? Is the c the start of the spanner in the above case?
>> So it would be
>> 
>> c4 d\bend e\bend f\bend
>> 
>> This seems more right to me, but I can't give strong reasons for it.  I do
>> have an argument for extensibility below.
>>  
> I wonder if it would be better to use a span event - once we got the
> reference pitch, the engraver can compute the bend amount of
> each note in the spanner range.

This works fine as long as there aren't chords.  If there are chords, the
spanner won't work properly (each note in the chord should have a different
reference pitch).

> 
> For the pre bend problem, we have to distinguish a pre bend
> from a grace bend, the former been drawn as a grace note
> without stem and in parentheses. So I thought about marking
> this note as "pre bend" with some command which sets the property
> of the stem of this grace note to a special value - perhaps we introduce
> Stem #'style and set this to #pre-bend or something similar.

Ahh, I wasn't aware of this complication.  I'll have to think about that
some more.

> 
> The StringBend engraver can now get the information from the stem of the
> first note in the bend spanner and can now compute everything as expected..
> 
> I hope that there will be a possibility to mark bends with some short
> signs like
> \^ ... \v or something similar so we could avoid typing too much (I even
> trought about using
> guillements «  ... » for this purpose, acting like slur parentheses, so
> instead of
> c ( d e f ) we can draw bend via c « d e f », but the accessibility on
> several keyboard layouts
> has to be double-checked first).

No, please don't use guillements.  They're not accessible on US keyboards.

> 
> So ideally, we'll have something like
> 
> c8 \startBend d4 c8 \stopBend (a bend starting from c to d and a release
> to c again)
> 
> \grace c8 \startBend d4 c8 \stopBend (a grace bend)
> 
> \preBend c8 \startBend d4 c8 \stopBend (a pre bend)
> 
> or even with some shorter symbols ...
> 
>>  
>>>> I think this will take care of all the bends that don't exist in chords,
>>>> and
>>>> I think you can start there.
>>>> 
>>>>      
>>> I am not sure how this should be handled generally - glissandos don't work
>>> in chords either, and perhaps the right way to do this is to use seperate
>>> voices in cases where some notes sound unbent while one string is bent -
>>> but if this approach is extensible in the future anyway and we don't
>>> have to redo the whole
>>> thing, I probably don't have to care about this right now.
>>>    
>> 
>> That's the key question -- is this approach extensible in the future?
>> 
>> The only approach that I'm positive is extensible in the future and to any
>> construct is to have \bend have an argument containing a pitch, which would
>> be the amount a pitch should be bent by:
>> 
>> c4 d\bend #'(ly:make-pitch 0 1 0) e\bend #'(ly:make-pitch 0 2 0) f\bend
>> #'(ly:make-pitch 0 3 0)
>> 
>>  
> Hmmmm - I wonder what would be the more guitar-like approach,
> giving the notes and let lilypond calculate the difference - or
> give just the bend amount and let lilypond display the right note?
> 
> Something like
> 
> c4 \bend4 2 \bend8 0
> 
> would translate to
> 
> c4 /\ d4 /\ c8

> 
> in the output (we have to consider the durations then - I don't know
> whether this works the way I pseudo-coded it, and I would certainly give
> the bend amount in half tone steps as an argument, not a ly:make-pitch 0
> 2 0;
> this has the drawback that the duration must be written in every case,
> until there is a way to enable optional arguments).

We have a way to enable optional arguments in the parser; the parser can
tell the difference between \bend note and \bend pitch note (or \bend number
note).

> 
> This is similar to the tablature input discussion earlier on the list;
> it is now difficult to draw tablatures when you have to translate
> (hand-written) tablatures to notes to get a proper input for lilypond
> in order to let lilypond again translate this into tablature numbers.

The earlier proposal was for a separate input mode.  To apply this kind of
bend syntax as part of a tablature input mode is very reasonable.  However,
we don't currently have such a mode.

For now, I think that the bend input needs to be parsable in normal note
mode.

> Here, I am not sure how guitarists think, but normally, it is more
> interesting
> how strong I have to pull a string ( ½, 1 or even 1½ and more as David
> Gilmour
> way too often does), not what pitch this will sound like, so in my
> opinion, the
> situations are comparable.
> 
> And the more I think about it, the more I like this idea ...
> 
> What do you think?
> 

Let me try to clarify my current understanding.  There needs to be a pitch
for the bent note, so it can be printed in the Staff.  And the pitch should
be parseable in note mode for now.

There also needs to be a reference pitch or a bend amount, so the the bend
can be properly printed in the tabStaff.

Suppose I do something like

c4 <d fis>4, and I want the d to be bent from the c.  How do I know that?
At that point, I need to either establish a reference pitch or a bend
amount.  Because it's a chord (and the fis might be bent as well), I can't
just use the c as the reference pitch.  So I need to enter something in the
chord construct as part of the articulation to establish the bend.

I thought about a reference pitch for the bend, but that would need to be
transposed if the music were transposed.  Also, for parsing, we would not be
able to tell the difference between \bend reference-pitch and \bend
next-note-pitch.  For those two reasons, I chose to have a bend amount as
the optional argument.

For the normal case, we'd just do \bend, and let the engraver track the
reference pitch.  For the chord case, we'd explicitly specify the amount of
the bend on each note in the chord.

I'd be fine to have it be a number, instead of a pitch.  I used a pitch
because I seem to remember somebody talking about a quarter-tone bend.  And
using a pitch for the bend argument gives all of the flexibility that
pitches allow.

Thanks,

Carl


---
----
Join the Frogs!