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

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 2/8/10 1:21 PM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:

> Carl Sorensen schrieb:
>> 
>> [...]
>>> 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).
>>  
> Thinking about bends in general, I stumbled across the fact that bends
> are actions on *one* string, so we have to include the string information
> in the bend engraving process - this would easily allow for hold bend
> actions
> (i.e. bending one string, holding it while playing another string,
> playing the
> still bent string again and so on).
> 
> In my naive opinion, there are two possible solutions:
> either we save the number of the string the starting note is played on,
> and take only
> the notes into account that are played at the same string. This may lead
> to the problem
> that we have to explicitly add the string number to every note (I don't
> know in which
> order the engravers are called, and thus I don't know whether the
> string-bend engraver
> can get the string number from the note head, but I think so);
> or (this is an idea I got during the work - I didn't had the time to do
> more research on it)
> we make use of some extended version of parallelMusic, which has one
> input line
> per string and thus would make bends and even multiple glissandi much
> easier to code.
> As I understand now, parallelMusic created a separate voice for every
> input line, but works
> at the moment not with \repeat constructs. But then, every string forms
> a separate voice, and a
> bend in one voice surely doesn't influence another. (On the other hand,
> as we aren't able
> to *force* users to use parallelMusic input for simple single note
> lines, the engraver has to
> listen to the string number anyway).

I don't think we need to require parallelMusic.  I try to avoid
parallelMusic.

For a voice without chord constructs, we can assume that a bend refers to a
previous note, I think (at least for version 1).

For a voice with chord constructs, we can require string number
articulations to be on the notes in order to handle bends properly.  And it
makes sense to do so. If you're going to have something played as a bend,
you generally know which string it should be on, I think.

>>  
>>> 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.
>> 
>> [...]
>>  
>> 
>> No, please don't use guillements.  They're not accessible on US keyboards.
>>  
> I strongly feel we need bigger keyboards with lots of different keys on
> it ;-)

It would certainly make things nicer to have more bracket-style characters!

>>  
>> [...]
>> 
>> 
>>  
>> 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.
>>  
> Ok, that's reasonable.
>> [...]
>> 
>> 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.
>>  
> Correct.
>> 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.
>>  
> When we take the string numbers into account, then
> 
> c4\2 < d\2 fis\1>4 would certainly do the job.

Yes, as long as we knew that d was supposed to be a bent note, and not a
note on a different fret.

So I'd code it as 

c4\2 < d\2\bend fis\1>4


>> 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.
>>  
> We have to take care about the reference pitch, being the first note of a
> series of bends (pre bends are drawn specially, but the first note is still
> the reference pitch), and the ancestor note.
> Consider the following:
> 
> c4 \bend d4 \bend e4 \bend c4

You are misunderstanding my syntax proposal.  Just as string numbers come
*after* the note, my syntax proposal is that \bend comes after the note.

c d\bend e\bend c

My assumption is that bend is a characteristic of a note, not a
characteristic of a transition between notes.
> 
> The tab note head for the first note is the fret number, the comes the
> bend arrow;
> the d is shown as a "1" over the first arrow, then follows another arrow
> with a
> 2 on top of it for e. Another arrow pointing down follows which ends on the
> parenthesized fret number.

Separate the bend arrows from the tab note heads.

The tab note head for the first note is the fret number, located on the
string number.  The tab note head for the second note is the bend amount (1)
located above the tab staff (1 staff space above the tab staff?).  The tab
note head for the third note is the bend amount (2) located above the tab
staff (I guess maybe 2 staff spaces above the tab staff?).  The note head
for the fourth note is the fret number, located on the string number.

The bend arrows simply connect the note heads.


> 
> But how do I code the following situation?
> 
> Think of a c4 as starting pitch, being bent up to d, being hold and
> struck again and then
> released to a c?
> 
> c4 \bend d4 d4 \bend c4 certainly would not do this, but perhaps c4
> \bend d4 \bend d4 \bend c4.

c4 d\bend d\bend c

Once you stop thinking about a bend as a transition, and instead think of it
as a characteristic, it works just fine.

The bend doesn't tell you where to draw the arrows; the bend tells you where
to place the note head.  And the arrows are just drawn between the note
heads.

> 
> Here, the ancestor of the second d is also a d, so the engraver knows
> that there is a
> hold bend situation and can take care of it.
> 
>> 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.
>>  
> May we use \bend as a "misused articulation", but - as we act upon a
> certain string -
> don't give the explicit bend amount within a chord?
> 
> < c\2\bend fis\1 >4 <d\2 g\1 >4
> 
> gives a bend from c to d, while the fis is replaced my a (struck) g. The
> \bend is
> only a marker to indicate which string number has to be observed by the
> engraver.

I don't think \bend is a misused articulation at all.  I think it's a
*proper* articulation.  But I'd code it as

<c\2 fis \1>4 <d\2\bend g\1>4

because it's the d, not the c, that is bent.

This would require an engraver variable bend_reference_notes_ that would be
a vector the same size as stringTunings.  I think I like this idea.  If we
use bend-event to create the bend, the reference note is given by base_note_
(which came from the previous note-event).  On the other hand, if we use
bend-articulation to create the bend (because it's in a chord), then we use
bend_reference_notes_  to establish the reference notes for each of the
strings (and we can update bend_reference_notes_ every time we handle a
chord in the engraver).

I'm not sure yet how we get the information to the tabNoteHead grob to
change it.  The bend-engraver doesn't create the tabNoteHead; the
tab-note-heads-engraver does.  So we either need to create some kind of
acknowledge path, or we need to have the bend-engraver change a property of
the tab-note-head event so the tab-note-heads-engraver knows what to do.

> 
> Thanks for reading all this stuff - the more I think of it, the more
> complicated it becomes,
> but I think that taking care of the string  number affected by the bend
> is crucial to
> the whole story.

I agree with you.  I think when we finally get to the right architecture,
the proper way forward will be clear.  And I think we're getting close.


Thanks,

Carl


---
----
Join the Frogs!