Re: string information handling inconsistent?

[Marc Hohl]

Carl Sorensen schrieb:
> 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 am not sure whether we understand each other. I was struggling with the
concept of getting the string information in the tab-note-heads-engraver
because I need the same function for bends.

Constructs like < c e g > \5 \4 \3 are somewhat strange, but they work, 
as it seems.

But < g e'\2 > doesn't work, because the routine in tab-note-heads-engraver
scans for note-events and string-events independently, and if there is only
one number given, then the engraver puts this number to the first note-event
which is wrong in this case.

So, while the parser does the right thing on strange cases like the ones 
you mentioned,
I think the tab-note-heads-engraver should be aware of the 
note-event/string-event
combination (in fact, the algorithm was not clear to me while I was 
trying to
get the bend stuff a little bit further, so I constructed the examplesI 
sent before
and found out that the tab-note-heads-engraver collects the note and string
informations independently and assumes that they will fit automatically, 
which is the case
in < g\3 e'\2 > or even < g e'\2 >\3, but not in < g e\2 >.

> 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 am not sure whether to be that restrictive, but a clear solution 
should be found anyway.
Since this string-number detection method is used within the 
note-heads-engraver,
the tab-note-heads-engraver, the fret-boards-engraver and the yet to be 
written
string-bend-engraver, perhaps this could be placed in an include file, 
so that we got more
consistency.

Thanks,

Marc