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

[Marc Hohl <marc@xxxxxxxxxx>]

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).
>   
> > 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 ;-)
>   
> [...]
>
>
>   
> 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.
> 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

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.

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.

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.

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.

Marc


---
----
Join the Frogs!