Re: tablature.ly

[Carl D. Sorensen]

On 4/30/09 1:36 AM, "Marc Hohl" <address@hidden> wrote:

> [snip]
> 
> I have reworked my tablature.ly according to all suggestions and
> improvements by Neil and Carl.
> 
> The modern tab clef seems to be scaling properly, I played a bit with
> some values for staff-space,
> and it looks now as it should be (at least in my opinion). I have
> managed (with excessive help)
> to get the staff-space and the line-count from the staff-symbol
> property, so there is no more
> need for explicitly using the tuning as an argument for the clef functions.
> (And again, I have gained some more insight  in scheme and lilypond,
> thank you both!)
> 
> As Neil proposed, it should be possible to code
> 
> \clef tab
> 
> for the current calligraphic clef, and to write
> 
> \clef moderntab
> 
> for the sans serif-style clef for compatibility's sake.
> 
> This issue is beyond my abilities, so I call desperately for help ;-)
>> If we add entries in parser-clef.scm to supported-clefs and
>> c0-pitch-alist (either directly or by consing the new entries within
>> the tablature file) for the modern tab,
>> 
>> ("moderntab" . ("markup.moderntab" 0 0))
>> 
>> ("markup.moderntab" . 0)
>>  
> I tried to cons these values, and I succeded (or at least it seemed to
> me) for the
> supported-clefs list, but not with the c0-pitch-alist
> (see attached files and lilypond's error messages).
> Is this list only locally defined, or am I missing something?

You are correct.  c0-pitch-alist is not public.  So it's currently not
possible to cons a value in with the tablature.ly file.

Your choices at this point are to
a) change the scm/parser-clef.scm file to (define-public c0-pitch-alist ....
and keep the additions to the clef list in tablature.ly

b) hardcode the changes to supported-clefs and c0-pitch-alist in
scm/parser-clef.scm

c) add a scheme function (define-public (add-new-clef clef-name) ....)
to scm/parser-clef.scm.  This function would cons the new clef values onto
both lists.  And because the function is defined in scm/parser-clef.scm, it
will have access to c0-pitch-alist.  Then you would revise tablature.ly to
call add-new-clef to take care of things.

My recommendation is that you pursue option c.  The disadvantage of pursuing
option c is that it won't be available to others until a new release of
LilyPond is issued.

However, the existing tablature.ly file that you posted to the list works
for 2.12, so that will meet the needs of those users.  And you will have
made the changes to scm/parser-clef.scm on your system, so you'll have it
available for your use.  And you can post a patch that those who are
interested can use to make changes to their own version of
scm/parser-clef.scm.

All in all, I'd say go ahead with the new function in scm/parser-clef.scm
and modify tablature.ly to work with the new function.


> 
> In my opinion, as tablature.ly is meant to be included by the user, not
> by default,
> the changings in these lists should be done within tablature.ly, if this
> is possible.

You can also think about splitting tablature.ly into tablature-init.ly which
will be always be run, and tablature.ly which will only be run if the user
includes it.  That's the way predefined-fretboards works.

>> we can override the Clef 'stencil to check 'glyph before calling the
>> default print-function.  If the string "markup.moderntab" is found,
>> then it's simple to return a stencil for the new tab markup.
>> 
>>  
> How can I achieve this?

Define a new Scheme function to be used as the Clef 'stencil property

(define (newClefPrint grob) ....)

It should check for the 'glyph property of the grob, and if it's
markup.moderntab, it will call the new tab markup function.  Otherwise, it
will call (ly:clef::print grob).


Hope this helps,

Carl