Re: string information handling inconsistent?

[Carl Sorensen]

On 3/15/10 2:08 AM, "Marc Hohl" <address@hidden> wrote:

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

Well, I'm pretty sure I understand you.  I think perhaps you misunderstood
my reply.  I'm not saying that the samples you made were wrong; they were in
fact correct if we're willing to to accept string-number events following a
chord.

And if we're going to accept string number events after a chord, then we
have to make up some means of transferring them from string-number events to
articulations in order to maintain the connection between note and string
number, it seems to me.

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

Yes, they do.  But I'm arguing that they shouldn't.

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

This is not quite the correct explanation for why this doesn't work.  The
reason is that the string-number articulations are combined in a list with
the string-number events.  And since there's only one string number in this
case, the list contains only one element.  Then, in later calls, since
there's only one string number, it's assigned to the first note in the
chord.

This behavior is clearly wrong.  I could patch the algorithm to add null
string numbers to the the list if there were string-number articulations and
no string-number events.  But even before you identified this bug, I was
thinking that the current structure is logically wrong.

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

Yes, you're absolutely right.

> 
>> 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,

Do you have a good reason why not to be that restrictive?  Can you think of
a reason why we would want to write

<c e g>4 \3 \2 \1

instead of

<c\3 e\2 g\1>4

?  I can't think of such a reason.  In my mind, the string number should
*always* be associated directly with the note to which it applies.  And that
association is lost in the first example.

The only possible corner case I can think of is

<c\5>4 vs <c>4 \5

But I think that the articulation string-number is clearer than the
string-event string-number in that case, as well.

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

I think that if we move to the plan I propose, the code will virtually
vanish.

But the principle is right -- if we have some functionality that is to be
used in multiple engravers, it should be stored in a common file, and
headers should be provided in an include file.

Thanks for your feedback!

Carl