Re: string information handling inconsistent?

[Carl Sorensen]

On 3/14/10 12:14 PM, "Marc Hohl" <address@hidden> wrote:

> Hello all,
> 
> it seems that explicit string information has to be used within chord
> constructs
> for *every* note, otherwise lilypond shows errors.
> 
> In the following example the second bar gives an error, because lilypond
> uses the
> "\2" for the first note within < ... >, this is the g which cannot be
> played on
> the second string.
> 
> I did not find this mentioned anywhere in the docs - or is this example
> too artificial and I should not bother?
> 

Marc,

Thank you for catching this.

This is a side effect of the patch I added some time ago to move to a single
function for note to fret conversion for both tab-note-heads and fretboards.

At the time I proposed that we ignore string indications that are outside of
chord constructs.  It was suggested that that was not ideal behavior.  I
agreed and went ahead with a patch that considered both the string-number
articulations in the chord and the string events that could follow the
chord.

This led to a couple of bugs, one of which I fixed last night, and one that
you just identified.  It also led to some copied code in both
tab-note-heads-engraver and fretboards-engraver.

After thinking about it some more, I now believe strongly that my original
inclination was correct.  We should ignore string-number events following a
chord.  They are ambiguous and incorrect, even though the parser will accept
them.

What should 

<c e g> \5 \4 \3

mean?

What about

<c e\4 g>\5 \3

Or

<c e\4 g> \5 \4 \3

? 

I propose to rewrite the code in note-heads-engraver, tab-note-heads
engraver, and fret-boards engraver such that if we're in a chord construct
(i.e., more than one note at this instant), any string-number events will
trigger a warning.  Furthermore, only string-number articulations will have
an effect in these engravers when we have a chord.

I'd welcome any comments on this proposal.

Thanks,

Carl