Re: Solved: conditionals in scheme :-)

[Carl D. Sorensen]

(Copied to list because of discussion on locations for initialization).

Marc has been working on tablature, specifically modifying the tabClef to
suit his liking by using a markup.  He's written a markup-command that will
typeset a tab clef, and he's also done it just with existing markups.  One
thing that is confusing to him and me was that the markup appeared different
when created in what appeared to us to be two equivalent ways.  The attached
image shows the difference, and the attached .ly files can be used to
recreate the problem.


On 4/22/09 12:48 PM, "Marc Hohl" <address@hidden> wrote:

> Carl D. Sorensen schrieb:
>> 
>>> By using the \sansSerifTabClef I recognized however that the spacing of the
>>> letters T, A and B increases too much with respect to num-strings. I
>>> (display)ed the
>>> values and fed them into some hard-coded versions of the clefs to see if my
>>> formulas were wrong. But this isn't the case, the hard-coded clefs look
>>> exactly as I wanted
>>> them, whereas the calculated ones don't fit in the tablature lines.
>> 
>> I think that maybe the hard-coded clefs are applying the font-size first,
>> then the baseline-skip (so the baseline skip is in units of the small font
>> size) and the calculated ones are applying the baseline skip first, so the
>> baseline-skip is in units of the large font size.
>> 
>>  
> This idea came to me when I went to work today,
> so when I came home again, you confirmed my suspicions...
>> I can't trace it all through, because I'm not sure exactly how it works
>> internally, but I think that #:column gets translated to (column-lines
>> layout props args), and our override was in new-props, not props.
>> 
>> I think it's time to start on thread on lilypond-devel, and see what they
>> tell you.
>> 
>> You could also try
>> 
>> (markup #:raise raise-value #:bold #:fontsize font-size
>>   (column-lines layout new-props '("T" "A" "B")))
>> 
>> or
>> 
>> (markup #:raise raise-value #:bold #:fontsize font-size
>>   (column-lines layout new-props "T" "A" "B"))
>> 
>>  
> I don't know why, but this ended up with an error message.
> 
> On the other hand, my formulas have no intrinsic mathematical meaning, they
> are just a best fit to the values I found by trial-and-error.
> So again, in manually typed in some values and wrote down the ones that
> looked
> best for a certain num-strings. Afterwards, I tried to find a function
> which returns
> just these values, and a 1/x-function looked best. So here is my new
> definition:
> 
> #(define-markup-command (customTabClef layout props tuning) (pair?)
>   (define (square x) (* x x))
>     (let* ((num-strings (length tuning))
>            (raise-value (- (* num-strings 0.4) 0.8))
>            (font-size (- (* num-strings 1.5) 7))
>            (base-skip (+ (/ -3.36 num-strings) 2.56))
>            (new-props (cons (list
>                               '(font-family . sans)
>                               (cons 'baseline-skip base-skip))
>                              props)))
>        (interpret-markup layout new-props
>          (markup #:raise raise-value #:bold #:fontsize font-size
>                 #:column ("T" "A" "B")))))

I don't understand.  The only difference I see from the previous function is
that you've changed the function that calculates base-skip.  Why should that
make it work differently?

For anybody else who might be interested in helping us figure out what's
going on, I've attached a couple of files that demonstrate the problem we
were working on.

> 
> If someone wants to write music for more than 7 strings, then I have to
> cross fingers
> and hope that my algorithm still works fine, or, as a better solution,
> the size of the clef
> should be limited in size. But as a first attempt, it will do.
> 
> So what is the next step? You asked for putting the defaults in
> ly/engraver-init.ly
> and putting the commands in ly/property-init.ly.
> 
> My proposal: should we open a ly/tablature-init.ly or something like that?
> (Some commands will touch not only the tablature, but some general
> guitar-specific issues like \palmMute, but I think the name is still ok.)


I like this proposal.

> 
> When we finally/hopefully have solved the bendings, slurs and ties etc.,
> there are a lot of commands especially for that purpose, so I think
> a seperate file would be the easiest way:

Yes, that's right.  The main question is whether it should be
ly/tablature-init.ly, which is always loaded, or whether it should be
ly/tablature.ly, which would only be loaded if it were called.


> one more line in ly/engraver-init.ly (namely \tabNumbersOnly),

I'm a bit concerned about putting \tabNumbersOnly in as the default, because
I don't know how to write a convert-ly rule that will properly handle the
conversion from previous versions to the current version.  Somebody who has
a tab score in version 2.12 would have stems and beams, and when they ran
convert-ly they'd all go away.  I think that to avoid this confusion, it
would be best to have \tabFullNotation as the default.  However, it it were
ly/tablature.ly, then havind \tabNumbersOnly as a default is no problem,
because old files wouldn't have \include "tablature.ly".

> one more in ly/declarations-init.ly ( \include "tablature-init.ly")
> and the future work only modifies/extends ly/tablature-init.ly.

I like these proposals (except we want to decide if it will be
tablature-init.ly or tablature.ly).

You will want to move the tuning definitions to scm/output-lib.scm.

You will want to remove (square x) from customTabClef.

You will also need to make regression tests -- .ly files that demonstrate
each of the new features you are adding.  Generally  you want one file per
feature.  You can find existing files in the input/regression directory.  If
you don't have the LilyPond source on your machine, you can download files
from the git repository on Savannah:

http://git.savannah.gnu.org/gitweb/?p=lilypond.git

Are you working with a git repository?  If not, seeing as how you're serious
about working on LilyPond, you should.  You can read about how to get
started with a git repository in the Contributors' Guide.  If you get
started on git it will make things easier for you.

Although it's not required for you to do it, somebody has to write
documentation snippets and examples for the new features you're adding.  I
think Jonathan Kulp is heading up this kind of changes to the documentation,
so you may want to either recruit him to write the new documentation
material or work with him to make sure your ideas for documentation work.  I
know that you're not a native English speaker, so you may wish to give the
documentation to work to somebody else.  But I find your English writing to
be *very* good.

When it comes time to add things to LilyPond (and it can be added in stages,
rather than all at once), we'll accomplish this by having you send me a
patch against the source tree.  The easiest way to do this is with git
format-patch.  Another acceptable way is with diff, using diff -u.  But as
involved as your changes are, I'd recommend you use git.

Anyway, keep up the good work, and welcome to LilyPond development!

Carl

cleftest-marc4.ly
Description: cleftest-marc4.ly

tablature.ly
Description: tablature.ly

clef-test-six-string.png
Description: clef-test-six-string.png