Re: PATCH: Improved tablature support

[Carl Sorensen]

On 7/17/09 2:13 AM, "Marc Hohl" <address@hidden> wrote:

> Carl Sorensen schrieb:
>> 
>> On 7/16/09 9:56 AM, "Carl Sorensen" <address@hidden> wrote:
>> 
>>  
>> 3) Is it necessary (or desirable) to have both \deadNote and
>> \deadNoteOn..\deadNoteOff?  Unless a whole piece is to be written in
>> DeadNotes, I can't imagine that it's better to write
>> 
>> \deadNoteOn e e deadNoteOff
>> 
>> than
>> 
>> \deadNotes{e e}.
>> 
>> If there's no value to the On..Off pairs, then it's probably best to
>> eliminate them.  But if there is value, we can keep them.  And I'm not the
>> judge of value.  I'm just asking the question.
>>  
> Hm, I introduced the ..On/..Off pairs first, because this syntax seemed
> to be
> "lilypondish"  -  and easier to read, especially if there are long
> passages played
> palm mute- or dead note-style. The latter construct looks more like a
> programming language to me (yes, in fact it is a programming language, but
> as there are many users not familiar with computer programming, we should
> avoid this in general - but this is rather philosophical here).

There are actually two different "lilypondish" constructs.  One is a
setting, the other is a function.

For example, we do \relative c' {...} and \transpose e f { ... } which are
exactly equivalent to \deadNote { ... }.

But we also have lots of settings.

> On the other hand, for a single dead note
> \deadNoteOn e \DeadNoteOff
> is way too complicated, and furthermore
> < c \deadNoteOn e \deadNoteOff g > won't work, so there is need for the
> second syntax.

Right, so we *must* have the function mode.  Do we need the setting mode as
well?  I don't feel strongly about eliminating it, but I don't feel strongly
about keeping it either.  I trust your judgment.

However, now that I think about it, for the function call, I would prefer
the name \deadNotes (plural) instead of \deadNote (singular), because it can
take multiple notes in its argument.


> > 
>> 
>> 4) Formatting nit on scm/tablature.scm
>> 
>> line 125-128: I think it would look better to put all the arguments to
>> ly:stencil-combine-at-edge on line 124.
>> 
>> line 129-131:  I would like it better to have the last three arguments to
>> the first ly:stencil-combine-at-edge call on line 125, nested to the same
>> depth as the inner (ly:stencil-combine-at-edge call.
>> 
>>  
> I don't want to blame others here, but this piece of code was 1:1 copied
> from Neil's mail.
> Shall I reformat it and send a new patch, or are there other
> possibilities to correct it?

This kind of judgment is somewhat subjective.  You can leave it as is, or
you can reformat it.  If you reformat it, please send a new patch.

>> Other than that, things look good.
>> 
>> Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
>> command that will be better than the current parentheses; it will draw the
>> parentheses as slurs.  This may be something you want to use in the future.
>>  
> Great! This opens the possibilitiy of drawing parentheses around chords,
> isn't it?

It will, but it may yet have its own problems.  It will parenthesize any
stencil.  I don't know if the set of noteheads forms its own stencil
(separate from the stem) or not.  If it does, we'll be home free on
parenthesizing chords.  If not, we'll still have to figure out how to get
the set of noteheads for parenthesizing.

Thanks,

Carl