Re: Plans for docs, snippets and requests

[Carl Sorensen]

On 2/8/10 4:17 AM, "Patrick Schmidt" <address@hidden> wrote:

> 
> 
>>>>> 3) propose a tab key that shows the tuning of the guitar in tablature
>>>> (please
>>>>> see file attached). Maybe it's possible to achieve this with \markup?!
>>>> 
>>>> The best thing to do would be to create a Tab_key_signature engraver.
>>>> This
>>>> could be written as a straightforward Scheme engraver that would create
>> a
>>>> TabKeySignature grob.  I think it's a *great* idea.
>>> I'll take a look at scheme-engraver.ly
>>> (http://codereview.appspot.com/181109/show).
>> 
>> Great!
> 
> This snippet (scheme-engraver.ly) compiles with an error (version "2.13.10"):

2.13.10 has a release date of 1 January; lily/scheme-engraver.cc has a
create date of 9 January.  You need a newer development version to use
scheme engravers.  2.13.11 should do it.
> 
> Without any description it's hard to tell for me what the engraver is supposed
> to do in this snippet (even though I followed Eric Knapp's and your emails.
> But ­ as you suggested ­ there might be easier ways to write an engraverS
> 
> I think first off I'll try to "manually" tweak a minimal example to achieve
> that the pitch names of the standard guitar tuning are printed on the lines of
> the TabStaff. Then I'll try to automate this process and extend it to other
> tunings using the variables defined in tablatures.scm. So maybe this way and
> with the help of the Extending manual I might be able to develop the
> Tab_key_signature_engraver from scratch. Does that sound like a promising
> approach?

It does, depending on what "manually" means.

The pitch names can probably use print routines very similar to the


> 
>>>>> 4) add (or edit) some unnumbered subsubsections to NR subsection
>> 
>> Ahh, now I see.  Certainly snippets would belong in the Snippet Repository
>> as well as in the docs.  But they don't get their own sections if they're
>> snippets.
> Well, what about Marc's \palmmute- and \deadNote-commands? If muted notes
> don't get an own section where should I place them in the notation reference?

They can have their own subsubsection.  They don't need tweaks; there is a
command for them (\deadNote).

If you create commands for some of your work, then the commands get added to
the distribution, and the docs get added to a (subsub)section in the NR.

If you're doing it using tweaks and overrides, it gets added to the LSR, and
the docs show up in the snippets list.

>>>>> c) Why are the chord extension numbers limited to 13? Chords such as
>> <e,
>>>> b' e
>>>>> g b e> cannot be defined in \chordmode.
>> 
>> Actually, this is not true.  Individual pitches can be added to any
>> degree.
>> See the docs for "Extended and altered chords" in NR 2.7.1.
>> 
>> It's only the automatic stacking that won't go beyond 13.
> True. I wasn't clear. I was aiming at the automatic stacking. Provided an
> automatic stacking going beyond 13 and the chordmode/ChordName-behavior
> described in the last paragraph it would become possible to define the chord
> <e b' e g b e> with a simple e:m15^3.
> 

I'd be happy to review a patch for the stacking algorithm that fixes all the
problems you've identified.

>> 
>> 
>>>>> e) It should also be possible for each step to appear more than once
>> in
>>>> a
>>>>> chord. Some guitar chords contain the same note on several strings
>> (e.g.
>>>> in
>>>>> compositions of Villa-Lobos). Mixed position chords would become
>>>> possible,
>>>>> too.
>> 
>> As I've thought more about this, I don't think that named chords should
>> have
>> a step multiple times.
>> 
>> I think it makes sense for explicitly entered chords to have repeated
>> steps,
>> and the chord namer should be smart enough to catch it.
> 
> I didn't mean that this should affect the chord name. I meant the possibility
> to enter something like c:3.5.8.8 or c:8.8. The chordname would still be c.

I understand, but c:8.8 doesn't make any sense to me.  The only time I can
see that it makes sense to have a repeated note is when there's an explicit
string assignment to the note so that the note will be placed on multiple
strings.  In standard musical notation I don't think you'd double up the
note head; only in tablature would you have two different indications for
the same note.

Again, if this is important to you, and you want to write a patch, I'd be
happy to review it.  As long as it doesn't break existing function, it
should be OK to implement it.

Thanks,

Carl