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

[ Thread Index | Date Index | More lilynet.net/frogs Archives ] 

Carl Sorensen schrieb:


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.

Hm, I am not sure about this, but surely we don't have to force the
user working with 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).

Yes, that makes sense.

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.

Yes, this decision should not be taken by lilypond. It's in the
user's responsibility to choose an appropriate string within
chord constructs.
[...] 
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!

Of course!

[...]

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 agree. Your first proposal didn't have a bend command, so I didn't insert one, too. 


[...]

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

Ok, but I thought that bends are spanners in order to provide two note heads
to the pointed slur engraving routine. If it is an articulation, how does the 
string-bend engraver knows which note the pointed slur should start on?

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.

I simplified my description - I got the idea that you want to change
the appearance of the tab note head. Concerning the correct placement, I thought about giving a bend-amount-dy list which contains the values in staff sizes where the 
changed tab note heads are placed. Something like
bend-amount-dy = (2.5 2 1.5) where the all entries up to the n-th are summed up to compute the value for a n-th order bend. If the bend order exceeds the number of entries 
in this list, the last entry is used again and again.
I plan to make a description of all parameters needed for the drawing of pointed slurs and bend arrows to get all the properties defined correctly. Perhaps I upload it with the first patch to rietveld, so we don't have to care about attachment size limitations, and 
everyone interested can get this description easily.


The bend arrows simply connect the note heads.
But still, I need two points in order to create the bend arrows, so how do I obtain 
them without having \bend been defined as a spanner?
[...]


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).

The vector solutions seems to be the right thing, but we have to update
this vector when a new bend is started - consecutive bends are still
depending on the first unbent note.

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.

I think the best solution would be to define a 'style property
for the tab note heads. #'normal is the default, then #'bend-amount
for our purpose - and how about #'parenthesized? If you have a look
at David's second paper concerning various examples of tablature features,
examples f and g show the need fot the slur spanner to influence the
appearance of the tab note head. At the moment, a tie makes the fret number
invisible and parenthesized at line breaks, but if the tied note is then
hooked to another one by a slur, the tied note should be parenthesized.
Changing a 'style property would simplify the situation.
Perhaps I'll include some algorithmic ideas in this yet to be written paper, too. 
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.

I hope so wholeheartedly ;-)

Thanks,

Marc



---
----
Join the Frogs!

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/