Re: [tablatures] Tablature Feature Request Examples - Part 2

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 1/5/10 12:47 PM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:

> Carl Sorensen schrieb:
>> 
>> On 1/5/10 7:54 AM, "David Stocker" <dstocker@xxxxxxxxxxxxxxxxx> wrote:
>> 
>>  
>>> Here are more examples of usage in guitar tablature. I realize that some
>>> of these are complex. The reason I put down some more complex examples
>>> is so that those doing the coding for this may see potential problems
>>> early on and be able to leave the code open-ended and flexible enough
>>> handle more complex scenarios in the future. In this way, I hope that as
>>> more features are implemented, a re-write of existing code won't be
>>> necessary in order to accommodate them.
>>>    
>> 
>> Looking at this example, I'm more convinced that bend should be a property
>> of a note.
> Not a spanner?

The bend indicator is a spanner, but the bend itself is a property of a
note.  How do you know when a note is bent (not in LilyPond necessarily, but
in generic musical notation)?  It's when the pitch is higher than the
standard pitch for a note at that fret given the string tuning.

>>  The numbers above the staff on the tablature should be
>> TabNoteHeads, not part of a bend graphic.  The bend graphic should connect
>> the TabNoteHeads.  And in the regular staff, the bend graphic should connect
>> the NoteHeads.
>>  
> Ah, I think I understand. As a beam connects multiple notes which are
> coded seperately, the bend engraver connects different notes by use of
> pointed slurs
> or arrows and changes the tab note head into a number, depending on the
> first note of the "bend beam".

Yes, that's exactly what I'm thinking.  And that's why you shouldn't use the
slur engraver as the starting point for the bend engraver.  The slur
engraver has all kinds of positioning that I don't think is needed for
either of the bend indications.

I'd recommend that you at least look at the logic of the auto_beam_engraver
as having some characteristics that will be needed for the bend_engraver.
It has the try/junk/finalize logic that I think will be useful.

>> I guess there will need to be some kind of merge command for the
>> tabNoteHeads if they have the same amount of bend.
>>  
> Hm, perhaps this is not necessary, because the position of the bend number
> is fixed, so in the worst case, we'll have two identical numbers positioned
> exactly on the same spot.

Not so if you look at the last case in David's example, where a two-note
chord is bent, but one note is bent a half step and the other is bent a
whole step. In that case, the bent note location is different for the two
notes.  Hence, we need to support both merged and unmerged bend notes.

Thanks,

Carl