Add option to indicate frets by letters in tablature

Add option to indicate frets by letters in tablature

 - Add Scheme function to provide fret number as a
   letter, invoked by setting the context property
   tablatureFormat to this procedure.

 - Add context property fretLetters to specify the
   first few fret letters, overriding the corresponding
   letters of the alphabet.

 - Move whiteout code into Tab_note_heads_engraver and
   make this conditional on the value of the 'whiteout
   property of TabNoteHead.  Modify the two other
   tablatureFormat procedures to invoke whiteout
   conditionally.

[Neil Puttock, 2009-12-02 22:19:32]

Hi Trevor,

This looks OK apart from a few minor details (I've mentioned the interface/doc
issues in the main thread).

I look forward to the next instalment.

Cheers,
Neil

http://codereview.appspot.com/164063/diff/1/2
File input/regression/tablature-letter.ly (right):

http://codereview.appspot.com/164063/diff/1/2#newcode3
input/regression/tablature-letter.ly:3: \header{ texidoc = "@cindex
Tabulature-letter
\header {
tablature-letter

http://codereview.appspot.com/164063/diff/1/2#newcode13
input/regression/tablature-letter.ly:13: }
no indent

http://codereview.appspot.com/164063/diff/1/2#newcode15
input/regression/tablature-letter.ly:15: partition =  {
= {

http://codereview.appspot.com/164063/diff/1/3
File lily/tab-note-heads-engraver.cc (right):

http://codereview.appspot.com/164063/diff/1/3#newcode140
lily/tab-note-heads-engraver.cc:140: if (to_boolean (note->get_property
("whiteout")))
Is this useful enough to make available to all grobs?

It could be added to grob.cc (where 'transparent and 'rotation are processed),
though the code would be a bit more convoluted. :)

http://codereview.appspot.com/164063/diff/1/6
File scm/translation-functions.scm (left):

http://codereview.appspot.com/164063/diff/1/6#oldcode395
scm/translation-functions.scm:395: (make-vcenter-markup
reindent

http://codereview.appspot.com/164063/diff/1/6#oldcode415
scm/translation-functions.scm:415: (make-vcenter-markup
reindent

http://codereview.appspot.com/164063/diff/1/6
File scm/translation-functions.scm (right):

http://codereview.appspot.com/164063/diff/1/6#newcode396
scm/translation-functions.scm:396: (letters (ly:context-property context
'fretLetters))
Could this context prop be a bit more descriptive?

Perhaps something like

fretLetterExceptions

http://codereview.appspot.com/164063/diff/1/6#newcode400
scm/translation-functions.scm:400: (if (< fret (length letters))
indent
(+ following lines)

[t.daniels_treda.co.uk, 2009-12-05 17:47:08]

I've reworked this patch to make 'whiteout a property of all
grobs.  To use it effectively 'layer must also be set
carefully.

I think I've dealt with the other issues.

Patch set 2 is a complete replacement.

Further comments?

http://codereview.appspot.com/164063

Trevor

----- Original Message ----- 
From: <n.puttock@gmail.com>
To: <tdanielsmusic@googlemail.com>
Cc: <lilypond-devel@gnu.org>; <reply@codereview.appspotmail.com>
Sent: Wednesday, December 02, 2009 10:19 PM
Subject: Add option to indicate frets by letters in tablature 
(issue164063)


> Hi Trevor,
>
> This looks OK apart from a few minor details (I've mentioned the
> interface/doc issues in the main thread).
>
> I look forward to the next instalment.
>
> Cheers,
> Neil
>
>
> http://codereview.appspot.com/164063/diff/1/2
> File input/regression/tablature-letter.ly (right):
>
> http://codereview.appspot.com/164063/diff/1/2#newcode3
> input/regression/tablature-letter.ly:3: \header{ texidoc = 
> "@cindex
> Tabulature-letter
> \header {
> tablature-letter
>
> http://codereview.appspot.com/164063/diff/1/2#newcode13
> input/regression/tablature-letter.ly:13: }
> no indent
>
> http://codereview.appspot.com/164063/diff/1/2#newcode15
> input/regression/tablature-letter.ly:15: partition =  {
> = {
>
> http://codereview.appspot.com/164063/diff/1/3
> File lily/tab-note-heads-engraver.cc (right):
>
> http://codereview.appspot.com/164063/diff/1/3#newcode140
> lily/tab-note-heads-engraver.cc:140: if (to_boolean 
> (note->get_property
> ("whiteout")))
> Is this useful enough to make available to all grobs?
>
> It could be added to grob.cc (where 'transparent and 'rotation are
> processed), though the code would be a bit more convoluted. :)
>
> http://codereview.appspot.com/164063/diff/1/6
> File scm/translation-functions.scm (left):
>
> http://codereview.appspot.com/164063/diff/1/6#oldcode395
> scm/translation-functions.scm:395: (make-vcenter-markup
> reindent
>
> http://codereview.appspot.com/164063/diff/1/6#oldcode415
> scm/translation-functions.scm:415: (make-vcenter-markup
> reindent
>
> http://codereview.appspot.com/164063/diff/1/6
> File scm/translation-functions.scm (right):
>
> http://codereview.appspot.com/164063/diff/1/6#newcode396
> scm/translation-functions.scm:396: (letters (ly:context-property 
> context
> 'fretLetters))
> Could this context prop be a bit more descriptive?
>
> Perhaps something like
>
> fretLetterExceptions
>
> http://codereview.appspot.com/164063/diff/1/6#newcode400
> scm/translation-functions.scm:400: (if (< fret (length letters))
> indent
> (+ following lines)
>
> http://codereview.appspot.com/164063 

[Carl, 2009-12-06 15:23:46]

Looks great to me.

I have a couple of comments.

Thanks for doing this!

Carl

http://codereview.appspot.com/164063/diff/2001/3008
File scm/translation-functions.scm (right):

http://codereview.appspot.com/164063/diff/2001/3008#newcode393
scm/translation-functions.scm:393: (define-public (fret-letter-tablature-format
str context event)
The change from string to str is contrary to the desired goal in LilyPond
programming.

The goal is to have all variable names be english words, rather than
abbreviations of english words.

There is lots of legacy code where that is not true, but we should not be
writing new code like this.

http://codereview.appspot.com/164063/diff/2001/3008#newcode399
scm/translation-functions.scm:399: (make-vcenter-markup
If length of 'fretLetterExceptions is greater than zero, I think we ought to
throw a warning if fret is higher than the length of 'fretLetterExceptions so
that the user will have an idea of why things didn't work the way they wanted it
to.

[t.daniels_treda.co.uk, 2009-12-06 16:50:32]

Hi Carl

Thanks for taking a look at this.

You wrote Sunday, December 06, 2009 3:23 PM>
>
> http://codereview.appspot.com/164063/diff/2001/3008
> File scm/translation-functions.scm (right):
>
> http://codereview.appspot.com/164063/diff/2001/3008#newcode393
> scm/translation-functions.scm:393: (define-public
> (fret-letter-tablature-format str context event)
> The change from string to str is contrary to the desired goal in
> LilyPond programming.
>
> The goal is to have all variable names be english words, rather 
> than
> abbreviations of english words.
>
> There is lots of legacy code where that is not true, but we should 
> not
> be writing new code like this.

I changed it because "string" is a keyword in Scheme.
It is even used as such in the same few lines of code.
Although "string" can be used as a variable name I don't
think it should be - it seems bad practice to overload
keywords in this way.

I fully agree with your point in general, but we need
to think of a variable name other than "string" for the
string on an instrument.  I tried, and failed :(, hence
str.

> http://codereview.appspot.com/164063/diff/2001/3008#newcode399
> scm/translation-functions.scm:399: (make-vcenter-markup
> If length of 'fretLetterExceptions is greater than zero, I think 
> we
> ought to throw a warning if fret is higher than the length of
> 'fretLetterExceptions so that the user will have an idea of why 
> things
> didn't work the way they wanted it to.

Hhm, I'm not so sure about this.  I had envisaged changing
only the c to r, leaving all letters beyond c to default.
As this would be the norm I don't think a warning is desirable,
but I'm willing to be convinced otherwise.  Actually, for most
ancient instruments only i or j, not both, is used, so maybe the
length of fretLetterExceptions would be somewhat greater than
3 normally, making a warning more appropriate.  Although if i
not j is a general rule, maybe that should be built in to the
default, then we'd be back to needing just the change from c to r.
Maybe a question on -user is needed on this point.

Trevor

[t.daniels_treda.co.uk, 2009-12-06 16:50:33]

Hi Carl

Thanks for taking a look at this.

You wrote Sunday, December 06, 2009 3:23 PM>
>
> http://codereview.appspot.com/164063/diff/2001/3008
> File scm/translation-functions.scm (right):
>
> http://codereview.appspot.com/164063/diff/2001/3008#newcode393
> scm/translation-functions.scm:393: (define-public
> (fret-letter-tablature-format str context event)
> The change from string to str is contrary to the desired goal in
> LilyPond programming.
>
> The goal is to have all variable names be english words, rather 
> than
> abbreviations of english words.
>
> There is lots of legacy code where that is not true, but we should 
> not
> be writing new code like this.

I changed it because "string" is a keyword in Scheme.
It is even used as such in the same few lines of code.
Although "string" can be used as a variable name I don't
think it should be - it seems bad practice to overload
keywords in this way.

I fully agree with your point in general, but we need
to think of a variable name other than "string" for the
string on an instrument.  I tried, and failed :(, hence
str.

> http://codereview.appspot.com/164063/diff/2001/3008#newcode399
> scm/translation-functions.scm:399: (make-vcenter-markup
> If length of 'fretLetterExceptions is greater than zero, I think 
> we
> ought to throw a warning if fret is higher than the length of
> 'fretLetterExceptions so that the user will have an idea of why 
> things
> didn't work the way they wanted it to.

Hhm, I'm not so sure about this.  I had envisaged changing
only the c to r, leaving all letters beyond c to default.
As this would be the norm I don't think a warning is desirable,
but I'm willing to be convinced otherwise.  Actually, for most
ancient instruments only i or j, not both, is used, so maybe the
length of fretLetterExceptions would be somewhat greater than
3 normally, making a warning more appropriate.  Although if i
not j is a general rule, maybe that should be built in to the
default, then we'd be back to needing just the change from c to r.
Maybe a question on -user is needed on this point.

Trevor

[demery_suffolk.lib.ny.us, 2009-12-06 21:37:40]

> I fully agree with your point in general, but we need
> to think of a variable name other than "string" for the
> string on an instrument.  I tried, and failed :(, hence
> str.

String is only completely correct for instruments like violins that have a
single string per course.

'course'  is the more general term for a group of strings that are sounded
together.

> Hhm, I'm not so sure about this.  I had envisaged changing
> only the c to r, leaving all letters beyond c to default.

I dont understand this insistance on misreading gamma as r.   It was not
written as gamma, the letterform used was always understood as 'c'.  It
should be read today as c, and is most logically encoded as c.  Yes, naive
musicologists and new players might take a while to get used to the idea,
but no experienced player reads gamma as 'r' to my knowledge.  Go this way
and you make a nightmare for possible analytical use of music thus
encoded.

Let the choice of font display a glyph in the proper shape. Provide the
user with a way to display arbitrary glyphs and ligatures for each encoded
'stop'.  This will be useful for bass stops (/a  /b  /c... //a  //b  //c,
///a) and essential for german tab should we go there.

It would be wrong to presume the encoding of the font.   The need for
glyphs beyond what is used in prose makes necessary special fonts whose
encoding has no standard.

afm-like information in external files keyed by name to their relevant
font would be my suggestion for that.

> Although if i not j is a general rule

I have generally seen i used in preference to j, but I have seen both in
the same document albeit this was german tab (same semantic).  Note that
that edition had large pages and lots of staves, it must have been a
challenge to find enough sorts to set the amount of type on each page,
several sizes and flavors of each sort were also used interchangeably
(both tall and short s for example).

J Wolf Handbuck der Notationskunde (2vv, ca 1926) and Apel _Notation of
Polyphonic Music 900-1600_ are the two standard references.  Groves
Dictionary of Music and Musicians (22vv or 26vv edition) 'Tabulature' is a
lengthy article also worth having a copy of.

--
Dana Emery

[c_sorensen, 2009-12-06 21:59:04]

On 12/6/09 9:50 AM, "Trevor Daniels" <t.daniels@treda.co.uk> wrote:

> Hi Carl
> 
> Thanks for taking a look at this.
> 
> You wrote Sunday, December 06, 2009 3:23 PM>
>> 
>> http://codereview.appspot.com/164063/diff/2001/3008
>> File scm/translation-functions.scm (right):
>> 
>> http://codereview.appspot.com/164063/diff/2001/3008#newcode393
>> scm/translation-functions.scm:393: (define-public
>> (fret-letter-tablature-format str context event)
>> The change from string to str is contrary to the desired goal in
>> LilyPond programming.
>> 
>> The goal is to have all variable names be english words, rather
>> than
>> abbreviations of english words.
>> 
>> There is lots of legacy code where that is not true, but we should
>> not
>> be writing new code like this.
> 
> I changed it because "string" is a keyword in Scheme.
> It is even used as such in the same few lines of code.
> Although "string" can be used as a variable name I don't
> think it should be - it seems bad practice to overload
> keywords in this way.

I don't know of string as a keyword in Scheme.  It's not listed in the Guile
reference manual index.

string?  is a predicate.

substring is a procedure.

There are a bunch of string-*, string->*, and *->string procedures.

But string by itself seems to not be part of the Scheme language.  Have I
missed something? (I easily could have.)

> 
> I fully agree with your point in general, but we need
> to think of a variable name other than "string" for the
> string on an instrument.  I tried, and failed :(, hence
> str.
> 

Dana suggests "course", which I guess speaks well to lute players.  But not
to guitar players.

string seems the best to me.

I know that I used string all through the fret-diagram code.

>> http://codereview.appspot.com/164063/diff/2001/3008#newcode399
>> scm/translation-functions.scm:399: (make-vcenter-markup
>> If length of 'fretLetterExceptions is greater than zero, I think
>> we
>> ought to throw a warning if fret is higher than the length of
>> 'fretLetterExceptions so that the user will have an idea of why
>> things
>> didn't work the way they wanted it to.
> 
> Hhm, I'm not so sure about this.  I had envisaged changing
> only the c to r, leaving all letters beyond c to default.
> As this would be the norm I don't think a warning is desirable,
> but I'm willing to be convinced otherwise.  Actually, for most
> ancient instruments only i or j, not both, is used, so maybe the
> length of fretLetterExceptions would be somewhat greater than
> 3 normally, making a warning more appropriate.  Although if i
> not j is a general rule, maybe that should be built in to the
> default, then we'd be back to needing just the change from c to r.
> Maybe a question on -user is needed on this point.

I had envisioned that a full set of fretLetters would be given (in fact, I'm
not really a big fan of the term fretLetterExceptions).  But now that I see
your design intent, I'm not sure what the best thing to do is.

Perhaps we just ought to define lists called fretLabels (instead of
fretLetters).  And we could then define lists of any kind of glyphs to be
used.  There could be specific lists for each different style of tablature,
that would be very easy to switch to.  The fretLabels list wouldn't need to
be characters; they could be markups or stencils, so users could define
whatever is needed or desired.

I'm not refusing to approve for any of this; I'm just kicking some ideas
around.

Thanks,

Carl

[t.daniels_treda.co.uk, 2009-12-07 00:18:01]

Carl Sorensen wrote Sunday, December 06, 2009 9:59 PM
>
> On 12/6/09 9:50 AM, "Trevor Daniels" <t.daniels@treda.co.uk> 
> wrote:
>>
>> I changed it because "string" is a keyword in Scheme.
>> It is even used as such in the same few lines of code.
>> Although "string" can be used as a variable name I don't
>> think it should be - it seems bad practice to overload
>> keywords in this way.
>
> I don't know of string as a keyword in Scheme.  It's not listed in 
> the Guile
> reference manual index.
>
> string?  is a predicate.
>
> substring is a procedure.
>
> There are a bunch of string-*, string->*, and *->string 
> procedures.
>
> But string by itself seems to not be part of the Scheme language. 
> Have I
> missed something? (I easily could have.)

I think you have.  string is a built-in procedure which
forms a string from one or more characters.  Try

guile> (string #\a #\b)

It outputs "ab".

It's actually used in the code in question, which was
what prompted me to change it.  "string" was being used
with two meanings in the same procedure.

>> I fully agree with your point in general, but we need
>> to think of a variable name other than "string" for the
>> string on an instrument.  I tried, and failed :(, hence
>> str.
>
> Dana suggests "course", which I guess speaks well to lute players. 
> But not
> to guitar players.
>
> string seems the best to me.

I prefer str to course and string, but if no other ideas
are forthcoming I'll use string_number.

>>> http://codereview.appspot.com/164063/diff/2001/3008#newcode399
>>> scm/translation-functions.scm:399: (make-vcenter-markup
>>> If length of 'fretLetterExceptions is greater than zero, I think
>>> we
>>> ought to throw a warning if fret is higher than the length of
>>> 'fretLetterExceptions so that the user will have an idea of why
>>> things
>>> didn't work the way they wanted it to.
>>
>> Hhm, I'm not so sure about this.  I had envisaged changing
>> only the c to r, leaving all letters beyond c to default.
>> As this would be the norm I don't think a warning is desirable,
>> but I'm willing to be convinced otherwise.  Actually, for most
>> ancient instruments only i or j, not both, is used, so maybe the
>> length of fretLetterExceptions would be somewhat greater than
>> 3 normally, making a warning more appropriate.  Although if i
>> not j is a general rule, maybe that should be built in to the
>> default, then we'd be back to needing just the change from c to 
>> r.
>> Maybe a question on -user is needed on this point.
>
> I had envisioned that a full set of fretLetters would be given (in 
> fact, I'm
> not really a big fan of the term fretLetterExceptions).  But now 
> that I see
> your design intent, I'm not sure what the best thing to do is.
>
> Perhaps we just ought to define lists called fretLabels (instead 
> of
> fretLetters).  And we could then define lists of any kind of 
> glyphs to be
> used.  There could be specific lists for each different style of 
> tablature,
> that would be very easy to switch to.  The fretLabels list 
> wouldn't need to
> be characters; they could be markups or stencils, so users could 
> define
> whatever is needed or desired.

I quite like the term fretLabels, with the list being of
anything that evaluated to a Scheme string.  I'll have a
play with this idea.  I think I shall also drop the idea
of having the default fret labels being the alphabet and
require all labels to be provided, issuing a warning as
you suggested if insufficient are available to indicate
the required pitch.  Label sets can then be provided in
the context definitions or by the user.

Trevor

[c_sorensen, 2009-12-07 01:51:35]

On Dec 6, 2009, at 5:18 PM, "Trevor Daniels" <t.daniels@treda.co.uk>  
wrote:

>
> Carl Sorensen wrote Sunday, December 06, 2009 9:59 PM
>>
>> On 12/6/09 9:50 AM, "Trevor Daniels" <t.daniels@treda.co.uk>
>> wrote:
>>>
>>> I changed it because "string" is a keyword in Scheme.
>>> It is even used as such in the same few lines of code.
>>> Although "string" can be used as a variable name I don't
>>> think it should be - it seems bad practice to overload
>>> keywords in this way.
>>
>> I don't know of string as a keyword in Scheme.  It's not listed in
>> the Guile
>> reference manual index.
>>
>> string?  is a predicate.
>>
>> substring is a procedure.
>>
>> There are a bunch of string-*, string->*, and *->string
>> procedures.
>>
>> But string by itself seems to not be part of the Scheme language.
>> Have I
>> missed something? (I easily could have.)
>
> I think you have.  string is a built-in procedure which
> forms a string from one or more characters.  Try
>
> guile> (string #\a #\b)
>
> It outputs "ab".
>
> It's actually used in the code in question, which was
> what prompted me to change it.  "string" was being used
> with two meanings in the same procedure.
>

Oh, yes. I forgot about that function.

Clearly we should not overload that.



>>> I fully agree with your point in general, but we need
>>> to think of a variable name other than "string" for the
>>> string on an instrument.  I tried, and failed :(, hence
>>> str.
>>
>> Dana suggests "course", which I guess speaks well to lute players.
>> But not
>> to guitar players.
>>
>> string seems the best to me.
>
> I prefer str to course and string, but if no other ideas
> are forthcoming I'll use string_number.
>

string_number seems so awkward.  But it's more descriptive than str.   
And I can't think of anything better.

>>>>

>>>> .  The fretLabels list
>> wouldn't need to
>> be characters; they could be markups or stencils, so users could
>> define
>> whatever is needed or desired.
>
> I quite like the term fretLabels, with the list being of
> anything that evaluated to a Scheme string.

Why a string instead of a string or a markup?

Thanks,

Carl

>

[Ian Hulin, 2009-12-07 02:18:25]

Carl, Trevor,

You've discussed the overloading of 'string' in Scheme and what variable 
name to use, and looked at Dana's suggestion of using 'course' but did 
you consider the other important point Dana made?


demery@suffolk.lib.ny.us wrote:
> <snip>
>> Hhm, I'm not so sure about this.  I had envisaged changing
>> only the c to r, leaving all letters beyond c to default.
> 
> I don't understand this insistance on misreading gamma as r.   It was not
> written as gamma, the letterform used was always understood as 'c'.  It
> should be read today as c, and is most logically encoded as c.  Yes, naive
> musicologists and new players might take a while to get used to the idea,
> but no experienced player reads gamma as 'r' to my knowledge.  Go this way
> and you make a nightmare for possible analytical use of music thus
> encoded.
> 
> Let the choice of font display a glyph in the proper shape. Provide the
> user with a way to display arbitrary glyphs and ligatures for each encoded
> 'stop'.  This will be useful for bass stops (/a  /b  /c... //a  //b  //c,
> ///a) and essential for german tab should we go there.
> 
> It would be wrong to presume the encoding of the font.   The need for
> glyphs beyond what is used in prose makes necessary special fonts whose
> encoding has no standard.
> 
> afm-like information in external files keyed by name to their relevant
> font would be my suggestion for that.
> 
>> Although if i not j is a general rule
> 
> I have generally seen i used in preference to j, but I have seen both in
> the same document albeit this was german tab (same semantic).  Note that
> that edition had large pages and lots of staves, it must have been a
> challenge to find enough sorts to set the amount of type on each page,
> several sizes and flavors of each sort were also used interchangeably
> (both tall and short s for example).
> 
> J Wolf Handbuck der Notationskunde (2vv, ca 1926) and Apel _Notation of
> Polyphonic Music 900-1600_ are the two standard references.  Groves
> Dictionary of Music and Musicians (22vv or 26vv edition) 'Tabulature' is a
> lengthy article also worth having a copy of.
> 
> --
> Dana Emery

Cheers,
Ian

[c_sorensen, 2009-12-07 02:38:53]

On Dec 6, 2009, at 7:18 PM, "Ian Hulin" <ian@hulin.org.uk> wrote:

> Carl, Trevor,
>
> You've discussed the overloading of 'string' in Scheme and what  
> variable
> name to use, and looked at Dana's suggestion of using 'course' but did
> you consider the other important point Dana made?

I think so. That's why I suggested a list of (string or markup), which  
I think is completely general. At that point the user can select any  
glyph from any font available.

The possibility of adding the afm-type info that Dana talked about is  
a separate patch, because it applies to all markups.

Is there something else you were thinking of?

Thanks,

Carl

>
> demery@suffolk.lib.ny.us wrote:
>> <snip>
>>> Hhm, I'm not so sure about this.  I had envisaged changing
>>> only the c to r, leaving all letters beyond c to default.
>>
>> I don't understand this insistance on misreading gamma as r.   It  
>> was not
>> written as gamma, the letterform used was always understood as  
>> 'c'.  It
>> should be read today as c, and is most logically encoded as c.   
>> Yes, naive
>> musicologists and new players might take a while to get used to the  
>> idea,
>> but no experienced player reads gamma as 'r' to my knowledge.  Go  
>> this way
>> and you make a nightmare for possible analytical use of music thus
>> encoded.
>>
>> Let the choice of font display a glyph in the proper shape. Provide  
>> the
>> user with a way to display arbitrary glyphs and ligatures for each  
>> encoded
>> 'stop'.  This will be useful for bass stops (/a  /b  /c... //a  // 
>> b  //c,
>> ///a) and essential for german tab should we go there.
>>
>> It would be wrong to presume the encoding of the font.   The need for
>> glyphs beyond what is used in prose makes necessary special fonts  
>> whose
>> encoding has no standard.
>>
>> afm-like information in external files keyed by name to their  
>> relevant
>> font would be my suggestion for that.
>>
>>> Although if i not j is a general rule
>>
>> I have generally seen i used in preference to j, but I have seen  
>> both in
>> the same document albeit this was german tab (same semantic).  Note  
>> that
>> that edition had large pages and lots of staves, it must have been a
>> challenge to find enough sorts to set the amount of type on each  
>> page,
>> several sizes and flavors of each sort were also used interchangeably
>> (both tall and short s for example).
>>
>> J Wolf Handbuck der Notationskunde (2vv, ca 1926) and Apel  
>> _Notation of
>> Polyphonic Music 900-1600_ are the two standard references.  Groves
>> Dictionary of Music and Musicians (22vv or 26vv edition)  
>> 'Tabulature' is a
>> lengthy article also worth having a copy of.
>>
>> --
>> Dana Emery
>
> Cheers,
> Ian

[t.daniels_treda.co.uk, 2009-12-07 10:12:16]

Dana Emery wrote Sunday, December 06, 2009 9:37 PM

> Let the choice of font display a glyph in the proper shape. 
> Provide the
> user with a way to display arbitrary glyphs and ligatures for each 
> encoded
> 'stop'.  This will be useful for bass stops (/a  /b  /c... //a 
> //b  //c,
> ///a) and essential for german tab should we go there.
>
> It would be wrong to presume the encoding of the font.   The need 
> for
> glyphs beyond what is used in prose makes necessary special fonts 
> whose
> encoding has no standard.
>
> afm-like information in external files keyed by name to their 
> relevant
> font would be my suggestion for that.

I prefer to leave the whole question of fonts until
later, primarily because I know little about them
at present.  As Carl suggested, if we permit markups
then any available font can be used (although even
that is not necessary, as simply overriding the font
for TabNoteHead works with just characters entered
anyway, as my initial lash-up using Fronimo fonts
showed.)  But markup will permit PostScript or even
images to be substituted, so there is an advantage
in flexibility to be gained by permitting it.

>> Although if i not j is a general rule
>
> I have generally seen i used in preference to j, but I have seen 
> both in
> the same document albeit this was german tab (same semantic). 
> Note that
> that edition had large pages and lots of staves, it must have been 
> a
> challenge to find enough sorts to set the amount of type on each 
> page,
> several sizes and flavors of each sort were also used 
> interchangeably
> (both tall and short s for example).

You will be able to use either or both.

Trevor

[t.daniels_treda.co.uk, 2009-12-07 10:19:59]

Carl Sorensen wrote Monday, December 07, 2009 1:51 AM
>
> On Dec 6, 2009, at 5:18 PM, "Trevor Daniels" 
> <t.daniels@treda.co.uk>
> wrote:
>
>> Carl Sorensen wrote Sunday, December 06, 2009 9:59 PM
>
>>>> .  The fretLabels list
>>> wouldn't need to
>>> be characters; they could be markups or stencils, so users could
>>> define
>>> whatever is needed or desired.
>>
>> I quite like the term fretLabels, with the list being of
>> anything that evaluated to a Scheme string.
>
> Why a string instead of a string or a markup?

As the font can be overridden in TabNoteHead markup
isn't required to select a different font.  However,
I see there might be an advantage in permitting PS
or even images to be substituted, or to use a different
font for some of the fret labels, and that would need
markup in the list.  I'll look at implementing that.

Thanks for the suggestions.

> Carl
Trevor

[c_sorensen, 2009-12-07 16:20:49]

On 12/6/09 5:18 PM, "Trevor Daniels" <t.daniels@treda.co.uk> wrote:

> 
> I prefer str to course and string, but if no other ideas
> are forthcoming I'll use string_number.
> 

In Scheme files, the variable name should be string-number.

In c++ files it would be string_number.

Thanks,

Carl

[demery_suffolk.lib.ny.us, 2009-12-07 16:30:24]

> Dana suggests "course", which I guess speaks well to lute players.  But
> not
> to guitar players.

12 course guitar anyone?

maybe ts a classical guitar hing, but I also remember tutorials discussing
6-course instruments.


> I had envisioned that a full set of fretLetters would be given

At least that, saving keystrokes is not a good idea here.  Wht is really 
needed is a way to specify degenerated ligatures; as I have said, for
german tab the ligatures used by 16c printers (and later) included
overstrikes using both curved and straight line segments placed below,
thru, and above the main glyph, each positioned differently from others. 
I began a font for these, but got sidetracked and havent gone back to it.

> Perhaps we just ought to define lists called fretLabels (instead of
> fretLetters).  And we could then define lists of any kind of glyphs to be
> used.

Flags, mensural symbols (O2, O3, O/...), bars (| || |:|  :|:  :|  |: |||,
this last is a common ornamental flourish used for the final bar, the
second vertical stroke is repeated several times all connected, the height
of it degenerates into, well, a flourish).  In some renaissance editions
it is clearly a cast type sort, others use various woodcuts chosen to fill
available space; perhaps the user will be inconcistant in how it is used,
epsf-cum-woodcut or font character.

While I use separate dots flags and stems when devising a font, they are
pre-compounded and are encoded as one non-combining symbol to the font
user.  However, other font makers may solve that issue differently,
leaving it up to the user to form ligatures from parts like tails, dots,
stems.  Tabulature flags with dots are usually shown above the staff
(Petrucci's editions are an exception), so there is no issue of the dot
intersecting a line, as is seen in notes on a mensural staff; mensural
notation requires a different placement of the dot of augmentation
relative to its note when the note is on a line as opposed to when it is
in a space, which is a reason to have them be combining symbols in a
mensural font.

> There could be specific lists for each different style of tablature,
> that would be very easy to switch to.

If ly needs musical semantics to associate with the symbols then there
will be an issue to consider as well, the display symbol lists will need
coordination with similar lists for the semantic(s).

Historical usage varied as to the symbols employed and how they map to
duration.  The usual set of 5 flags were simply up-stemmed notes (usually,
but not always headless) with tails to the right - semibreve, minim,
semiminim, fusa, semifusa.  Some printers also had a breve - a left-going
tail, or a tailless stem with a circle on it.

Many polyphonic editions show (by comparing parallel score parts with the
tab) that those flags were read in proportion (ie, the written semibreve
was read as breve); this to avoid needing  5-flagged stems that would
challenge the punchcutter, the player, compositor, and proofreader with
weak eyes, and the ink that spreads.

--
Dana Emery

[t.daniels_treda.co.uk, 2009-12-07 16:31:48]

Carl Sorensen wrote Monday, December 07, 2009 4:20 PM
>
>On 12/6/09 5:18 PM, "Trevor Daniels" <t.daniels@treda.co.uk> wrote:
>>
>> I prefer str to course and string, but if no other ideas
>> are forthcoming I'll use string_number.
>
> In Scheme files, the variable name should be string-number.
>
> In c++ files it would be string_number.

Yes, I realised that when I came to change it.

Thanks anyway

Trevor

[demery_suffolk.lib.ny.us, 2009-12-07 17:37:08]

What I am trying to say comes from my own experiences writing a gui
program to do tab typesetting on macintosh.

My software records {course,fret} data for each note in the score, and
pitch information for each course on the instrument (simplifying courses
with octaves as split play is very rare).

That internal data is mapped using user-selected tables (which can be
user-defined, tho I provide several) for - keybindings (gui input),
musical semantics, and display ligatures.

For ly, you have user-encoded textfiles which roughly correspond to marked
up data using my input keybindings, an Internalization of that data,
musical semantic tables, display tables.

BTW, I found it useful to map the index 0 to blank and 'no semantic' on
all those tables.
--
Dana Emery

[Ian Hulin, 2009-12-07 18:01:14]

Hi Carl,

Carl Sorensen wrote:
> On Dec 6, 2009, at 7:18 PM, "Ian Hulin" <ian@hulin.org.uk> wrote:
>
>   
>> Carl, Trevor,
>>
>> You've discussed the overloading of 'string' in Scheme and what  
>> variable
>> name to use, and looked at Dana's suggestion of using 'course' but did
>> you consider the other important point Dana made?
>>     
>
> I think so. That's why I suggested a list of (string or markup), which  
> I think is completely general. At that point the user can select any  
> glyph from any font available.
>
> The possibility of adding the afm-type info that Dana talked about is  
> a separate patch, because it applies to all markups.
>
> Is there something else you were thinking of?
>   
Well, yes, maybe Dana can explain this better, but it seems to me we may 
be in danger of perpetuating a sort of urban myth with regard to 
lettered tablatures.  

Fret 3 was lettered as ɣ, which was rendered in some contemporary 
engravings to look a bit like a fancy r, so some modern transcriptions 
of the tablature turn it into an r.  If we're going to re-render ɣ, why 
not do it as c, and keep the logical letter sequence. 

I know we want Lily to be flexible and render contemporary engraving as 
authentically as possible, but using the 'r' for fret 3 is as bogus as 
this example.  Titles like "Ye Olde Forge", is a misreading of the "Þe 
Olde Forge": Þ being a letter thorn standing in for Th.  The ornate 
blackface font letter Y looked a bit like Þ so it got substituted in 
some texts where early printers didn't have the Þ in their type-cases.

Cheers,

Ian


> Thanks,
>
> Carl
>
> <snip>

[c_sorensen, 2009-12-07 20:50:45]

On 12/7/09 11:00 AM, "Ian Hulin" <ian@hulin.org.uk> wrote:

> Hi Carl,
> 
> Carl Sorensen wrote:
>>  
>> 
>> On Dec 6, 2009, at 7:18 PM, "Ian Hulin" <ian@hulin.org.uk>
>> <mailto:ian@hulin.org.uk>  wrote:
>> 
>>   
>>  
>>>  
>>> Carl, Trevor,
>>> 
>>> You've discussed the overloading of 'string' in Scheme and what
>>> variable
>>> name to use, and looked at Dana's suggestion of using 'course' but did
>>> you consider the other important point Dana made?
>>>     
>>>  
>>  
>> 
>> I think so. That's why I suggested a list of (string or markup), which
>> I think is completely general. At that point the user can select any
>> glyph from any font available.
>> 
>> The possibility of adding the afm-type info that Dana talked about is
>> a separate patch, because it applies to all markups.
>> 
>> Is there something else you were thinking of?
>>   
> Well, yes, maybe Dana can explain this better, but it seems to me we may be
in
> danger of perpetuating a sort of urban myth with regard to lettered
> tablatures.   

We are perpetuating that urban myth if we provide fretLabels with "r".  I'm
glad you pointed that out.

My comments were not about the fretLabels to be provided, but about the
architecture that would support various fretLabel lists.


> 
> Fret 3 was lettered as ɣ, which was rendered in some contemporary engravings
> to look a bit like a fancy r, so some modern transcriptions of the tablature
> turn it into an r.  If we're going to re-render ɣ, why not do it as c, and
> keep the logical letter sequence. 

My preference would be to render it as gamma.  Let's do it correctly.
Thanks for pointing this out.

Carl

[c_sorensen, 2009-12-07 21:05:12]

On 12/7/09 9:30 AM, "demery@suffolk.lib.ny.us" <demery@suffolk.lib.ny.us>
wrote:

> 
> 
>> Dana suggests "course", which I guess speaks well to lute players.  But
>> not
>> to guitar players.
> 
> 12 course guitar anyone?

In my experience we call it a 12-string guitar (but as you correctly point
out, there are only 6-courses in a 12-string guitar).

> 
> maybe ts a classical guitar hing, but I also remember tutorials discussing
> 6-course instruments.
> 

There are some pages on the web that discuss 5- and 6-course guitars, with
either single courses (1 string per course) or double courses (2 strings per
course).

This is not part of the experience in "popular" guitar playing as far as I
can see.

But it is apparent that we really do finger courses, rather than strings.

> 
>> I had envisioned that a full set of fretLetters would be given
> 
> At least that, saving keystrokes is not a good idea here.  Wht is really
> needed is a way to specify degenerated ligatures; as I have said, for
> german tab the ligatures used by 16c printers (and later) included
> overstrikes using both curved and straight line segments placed below,
> thru, and above the main glyph, each positioned differently from others.
> I began a font for these, but got sidetracked and havent gone back to it.

These overstrikes can be accomplished with markups, which is part of the
reason I want to have markups available in fretLabels.

> 
>> Perhaps we just ought to define lists called fretLabels (instead of
>> fretLetters).  And we could then define lists of any kind of glyphs to be
>> used.
> 
> Flags, mensural symbols (O2, O3, O/...), bars (| || |:|  :|:  :|  |: |||,
> this last is a common ornamental flourish used for the final bar, the
> second vertical stroke is repeated several times all connected, the height
> of it degenerates into, well, a flourish).  In some renaissance editions
> it is clearly a cast type sort, others use various woodcuts chosen to fill
> available space; perhaps the user will be inconcistant in how it is used,
> epsf-cum-woodcut or font character.
> 
> While I use separate dots flags and stems when devising a font, they are
> pre-compounded and are encoded as one non-combining symbol to the font
> user.  However, other font makers may solve that issue differently,
> leaving it up to the user to form ligatures from parts like tails, dots,
> stems.  Tabulature flags with dots are usually shown above the staff
> (Petrucci's editions are an exception), so there is no issue of the dot
> intersecting a line, as is seen in notes on a mensural staff; mensural
> notation requires a different placement of the dot of augmentation
> relative to its note when the note is on a line as opposed to when it is
> in a space, which is a reason to have them be combining symbols in a
> mensural font.

Font design is clearly outside the scope of the current effort, although it
has been proposed as a future phase.

> 
>> There could be specific lists for each different style of tablature,
>> that would be very easy to switch to.
> 
> If ly needs musical semantics to associate with the symbols then there
> will be an issue to consider as well, the display symbol lists will need
> coordination with similar lists for the semantic(s).

Unquestionably we want LilyPond to have correct semantics, and produce
output corresponding to those semantics.  I think that's at the core of
Trevor's implementation.
 

> 
> Historical usage varied as to the symbols employed and how they map to
> duration.  The usual set of 5 flags were simply up-stemmed notes (usually,
> but not always headless) with tails to the right - semibreve, minim,
> semiminim, fusa, semifusa.  Some printers also had a breve - a left-going
> tail, or a tailless stem with a circle on it.

Again, a list that matches a duration to a symbol (and whose symbols can be
specified by the user) will allow the matching between semantics and
display.

> 
> Many polyphonic editions show (by comparing parallel score parts with the
> tab) that those flags were read in proportion (ie, the written semibreve
> was read as breve); this to avoid needing  5-flagged stems that would
> challenge the punchcutter, the player, compositor, and proofreader with
> weak eyes, and the ink that spreads.
> 

Thanks,

Carl

[demery_suffolk.lib.ny.us, 2009-12-08 00:23:16]

>> Fret 3 was lettered as ɣ, which was rendered in some contemporary
>> engravings
>> to look a bit like a fancy r, so some modern transcriptions of the
>> tablature
>> turn it into an r.  If we're going to re-render ɣ, why not do it as c,
>> and
>> keep the logical letter sequence. 
>
> My preference would be to render it as gamma.  Let's do it correctly.
> Thanks for pointing this out.

'c' marks fret 2 in French tab.

Correct is to think of it as 'c', employ that concept internally, and in
any documentation.  Draw it as a gamma-like glyph in fonts emulating those
hands and fonts which do so historically; but encode it in those fonts as
the 'c' it is.

This list is the first place I have seen mention of the concept of it
being a gamma, the citations i gave in an earlier email are the scholarly
references for tablature notation, I own Apel and have it open now, but
Wolf is hard to come by outside of a good music library.  Apel takes time
to discuss the development of some symbols, clefs for instance, but not
these, no mention of gamma at all in his discussion of the symbols of
french tabulature.  He illustrates Granjons pretty font in a 1568
publication, the 'c' in that font is a combination of both, the lower
curve of a 'c', the upper flattened arm of a gamma.  The hand  of gaultier
as seen in the Hamburg codex is also shown, there the 'c' (as labeled by
Apel) is indeed a gamma, very rectilinear modern 'r'.  But, my point here
is that Apel labels it 'c', and says nothing about it resembling a gamma.

The omission of j will be curious to anyone writing analytical software,
but that is enough strangeness (gotta have at least one point of
strangeness).

Please note that Pierre Attaignant (first printer of french tabulature
notation) used ROMAN MAJISCULE letter forms in his 1528 and 1530 editions,
C was a C for his readers.  I wish I had the material from my survey of
french tab printers fonts handy, I am sure there are others whose letter
forms were more italianate than courthand.

--
Dana Emery

[t.daniels_treda.co.uk, 2009-12-08 00:51:10]

Thanks for this, Dana.  We're some way off implementing
fonts, or whatever means we select for rendering specific
lettering, but I shall carefully file all this information
away and draw on it at the appropriate time.  For now I'm
more concerned with understanding the internal mechanisms
of LilyPond and implementing some rather basic facilities.

Trevor

----- Original Message ----- 
From: <demery@suffolk.lib.ny.us>
To: "Carl Sorensen" <c_sorensen@byu.edu>
Cc: "Ian Hulin" <ian@hulin.org.uk>; "Trevor Daniels" 
<t.daniels@treda.co.uk>; <lilypond-devel@gnu.org>; 
<reply@codereview.appspotmail.com>; <tdanielsmusic@googlemail.com>; 
<carl.d.sorensen@gmail.com>
Sent: Tuesday, December 08, 2009 12:23 AM
Subject: Re: Add option to indicate frets by letters in tablature 
(issue164063)




>> Fret 3 was lettered as ɣ, which was rendered in some 
>> contemporary
>> engravings
>> to look a bit like a fancy r, so some modern transcriptions of 
>> the
>> tablature
>> turn it into an r. If we're going to re-render ɣ, why not do it 
>> as c,
>> and
>> keep the logical letter sequence.Â
>
> My preference would be to render it as gamma.  Let's do it 
> correctly.
> Thanks for pointing this out.

'c' marks fret 2 in French tab.

Correct is to think of it as 'c', employ that concept internally, 
and in
any documentation.  Draw it as a gamma-like glyph in fonts emulating 
those
hands and fonts which do so historically; but encode it in those 
fonts as
the 'c' it is.

This list is the first place I have seen mention of the concept of 
it
being a gamma, the citations i gave in an earlier email are the 
scholarly
references for tablature notation, I own Apel and have it open now, 
but
Wolf is hard to come by outside of a good music library.  Apel takes 
time
to discuss the development of some symbols, clefs for instance, but 
not
these, no mention of gamma at all in his discussion of the symbols 
of
french tabulature.  He illustrates Granjons pretty font in a 1568
publication, the 'c' in that font is a combination of both, the 
lower
curve of a 'c', the upper flattened arm of a gamma.  The hand  of 
gaultier
as seen in the Hamburg codex is also shown, there the 'c' (as 
labeled by
Apel) is indeed a gamma, very rectilinear modern 'r'.  But, my point 
here
is that Apel labels it 'c', and says nothing about it resembling a 
gamma.

The omission of j will be curious to anyone writing analytical 
software,
but that is enough strangeness (gotta have at least one point of
strangeness).

Please note that Pierre Attaignant (first printer of french 
tabulature
notation) used ROMAN MAJISCULE letter forms in his 1528 and 1530 
editions,
C was a C for his readers.  I wish I had the material from my survey 
of
french tab printers fonts handy, I am sure there are others whose 
letter
forms were more italianate than courthand.

--
Dana Emery

[demery_suffolk.lib.ny.us, 2009-12-08 01:27:27]

> Thanks for this, Dana.  We're some way off implementing
> fonts, or whatever means we select for rendering specific
> lettering

I realize that, what i was concerned with is that the technology for
flexibility be in place.

When the time comes, you will want to have done some surveying of
originals.  J Wolf Handbuch der Notationskunde and W. Apel Polyphonic
Notation 900-1600 are a beginning, there are many more interesting
publications that illustrate musical incuabulae, including tabulature. 
New Groves 'Tabulature' is dated, but has lots of good illustrations. 
'Sources' is another source that touches on some of the Ms.  If you are a
member of the LSA you have access to microfilms, and being in the UK you
have the BM, Oxford, and Cambridge, with Paris and other continental
sources a pleasant journey away.

It is not easy finding exemplars for the whole alphabet in actual music,
if a note isnt played you have no glyph.  With all the interest nowadays
in geneology, as well as past years interest in typography and caligraphy
there are many tangential resources to draw on.

There are also many modern musicologists who have written articles on the
grace markups in EM, LSAJ, LSJ, EMA etc, all of those need some time in
library pour les musiques baroque.

--
Dana Emery

[Neil Puttock, 2009-12-13 19:54:12]

Hi Trevor,

Here are a few comments as promised earlier.

Cheers,
Neil

http://codereview.appspot.com/164063/diff/5001/5002
File Documentation/changes.tely (right):

http://codereview.appspot.com/164063/diff/5001/5002#newcode73
Documentation/changes.tely:73: \new TabStaff
trailing space

http://codereview.appspot.com/164063/diff/5001/5002#newcode79
Documentation/changes.tely:79: \set fretLabels = #`(,(markup #:with-color red
"a")
trailing space

http://codereview.appspot.com/164063/diff/5001/5002#newcode80
Documentation/changes.tely:80: "b"
trailing space

http://codereview.appspot.com/164063/diff/5001/5003
File input/regression/tablature-letter.ly (right):

http://codereview.appspot.com/164063/diff/5001/5003#newcode23
input/regression/tablature-letter.ly:23: \set fretLabels = #`("α" "β" "γ")
#'

http://codereview.appspot.com/164063/diff/5001/5005
File lily/grob.cc (right):

http://codereview.appspot.com/164063/diff/5001/5005#newcode160
lily/grob.cc:160: /* Call the scheme procedure stencil-whiteout in
scm/stencils.scm */
I'd use { } here if you want this comment placed before the code.

http://codereview.appspot.com/164063/diff/5001/5005#newcode162
lily/grob.cc:162: retval = *unsmob_stencil (scm_call_1 (
If you newline at the parenthesis, the following lines should be indented
accordingly, but this will make the line quite long so it's probably better to
start on the following line:

retval
  = *unsmob_stencil (scm_call_1 (ly_lily_module_constant ("stencil-whiteout"),
                                 retval.smobbed_copy()));

http://codereview.appspot.com/164063/diff/5001/5010
File scm/translation-functions.scm (right):

http://codereview.appspot.com/164063/diff/5001/5010#newcode398
scm/translation-functions.scm:398: (make-vcenter-markup
    (make-vcenter-markup
     (cond
      ((= 0 (length labels))
       (string (integer->char (+ fret (char->integer #\a)))))
      ((and (<= 0 fret) (< fret (length labels)))
       (list-ref labels fret))
      (else
       (ly:warning "No label for fret ~a (~a on string ~a);
only ~a fret labels provided"
                   fret pitch string-number (length labels))
       ".")))))

http://codereview.appspot.com/164063/diff/5001/5010#newcode414
scm/translation-functions.scm:414: (make-vcenter-markup
    (make-vcenter-markup
     (format
      "~a"
      (- (ly:pitch-semitones pitch)
	 (list-ref tuning
		   ;; remove 1 because list index starts at 0
		   ;;and guitar string at 1.
		   (1- string-number))))))

http://codereview.appspot.com/164063/diff/5001/5010#newcode432
scm/translation-functions.scm:432: (make-vcenter-markup
    (make-vcenter-markup
     (let ((fret (- (ly:pitch-semitones pitch)
		    (list-ref tuning (1- string-number)))))
       (number->string (cond
			((and (> fret 0) (= string-number 5))
			 (+ fret 5))
			(else fret)))))))

[t.daniels_treda.co.uk, 2009-12-14 12:13:07]

Thanks Neil

Sorry about the trailing spaces.  I was used to my Windows editor 
removing
them automatically; gedit can't, AFAICS.  However, I've just 
discovered that
git rebase --warning=fix will remove them, so as long as I remember 
to do
that they should be gone.

I think I've corrected the formatting errors as you suggested. 
Could you please
explain when I should use a 1-space indent and when 2-space, please, 
otherwise
this seems just arbitrary.  I do find a 1-space indent makes it more 
difficult to
see the alignments when the lines are some distance apart.

So is http://codereview.appspot.com/164063 now ready to go?

I'll amend the docs after pushing.

Trevor

----- Original Message ----- 
From: <n.puttock@gmail.com>
To: <tdanielsmusic@googlemail.com>; <carl.d.sorensen@gmail.com>
Cc: <reply@codereview.appspotmail.com>; <lilypond-devel@gnu.org>
Sent: Sunday, December 13, 2009 7:54 PM
Subject: Re: Add option to indicate frets by letters in tablature 
(issue164063)


> Hi Trevor,
>
> Here are a few comments as promised earlier.
>
> Cheers,
> Neil
>
>
> http://codereview.appspot.com/164063/diff/5001/5002
> File Documentation/changes.tely (right):
>
> http://codereview.appspot.com/164063/diff/5001/5002#newcode73
> Documentation/changes.tely:73: \new TabStaff
> trailing space
>
> http://codereview.appspot.com/164063/diff/5001/5002#newcode79
> Documentation/changes.tely:79: \set fretLabels = #`(,(markup
> #:with-color red "a")
> trailing space
>
> http://codereview.appspot.com/164063/diff/5001/5002#newcode80
> Documentation/changes.tely:80: "b"
> trailing space
>
> http://codereview.appspot.com/164063/diff/5001/5003
> File input/regression/tablature-letter.ly (right):
>
> http://codereview.appspot.com/164063/diff/5001/5003#newcode23
> input/regression/tablature-letter.ly:23: \set fretLabels = #`("α" 
> "β"
> "γ")
> #'
>
> http://codereview.appspot.com/164063/diff/5001/5005
> File lily/grob.cc (right):
>
> http://codereview.appspot.com/164063/diff/5001/5005#newcode160
> lily/grob.cc:160: /* Call the scheme procedure stencil-whiteout in
> scm/stencils.scm */
> I'd use { } here if you want this comment placed before the code.
>
> http://codereview.appspot.com/164063/diff/5001/5005#newcode162
> lily/grob.cc:162: retval = *unsmob_stencil (scm_call_1 (
> If you newline at the parenthesis, the following lines should be
> indented accordingly, but this will make the line quite long so 
> it's
> probably better to start on the following line:
>
> retval
>   = *unsmob_stencil (scm_call_1 (ly_lily_module_constant
> ("stencil-whiteout"),
>                                  retval.smobbed_copy()));
>
> http://codereview.appspot.com/164063/diff/5001/5010
> File scm/translation-functions.scm (right):
>
> http://codereview.appspot.com/164063/diff/5001/5010#newcode398
> scm/translation-functions.scm:398: (make-vcenter-markup
>     (make-vcenter-markup
>      (cond
>       ((= 0 (length labels))
>        (string (integer->char (+ fret (char->integer #\a)))))
>       ((and (<= 0 fret) (< fret (length labels)))
>        (list-ref labels fret))
>       (else
>        (ly:warning "No label for fret ~a (~a on string ~a);
> only ~a fret labels provided"
>                    fret pitch string-number (length labels))
>        ".")))))
>
> http://codereview.appspot.com/164063/diff/5001/5010#newcode414
> scm/translation-functions.scm:414: (make-vcenter-markup
>     (make-vcenter-markup
>      (format
>       "~a"
>       (- (ly:pitch-semitones pitch)
> (list-ref tuning
>    ;; remove 1 because list index starts at 0
>    ;;and guitar string at 1.
>    (1- string-number))))))
>
> http://codereview.appspot.com/164063/diff/5001/5010#newcode432
> scm/translation-functions.scm:432: (make-vcenter-markup
>     (make-vcenter-markup
>      (let ((fret (- (ly:pitch-semitones pitch)
>     (list-ref tuning (1- string-number)))))
>        (number->string (cond
> ((and (> fret 0) (= string-number 5))
> (+ fret 5))
> (else fret)))))))
>
> http://codereview.appspot.com/164063
>


--------------------------------------------------------------------------------


> _______________________________________________
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
> 

[t.daniels_treda.co.uk, 2009-12-14 17:50:32]

Trevor Daniels wrote Monday, December 14, 2009 12:12 PM
>
> Sorry about the trailing spaces.  I was used to my Windows editor 
> removing
> them automatically; gedit can't, AFAICS.  However, I've just 
> discovered that
> git rebase --warning=fix will remove them,

--whitespace=fix of course!

Trevor

[Neil Puttock, 2009-12-20 21:48:51]

On 2009/12/14 12:13:07, t.daniels_treda.co.uk wrote:

> I think I've corrected the formatting errors as you suggested. 
> Could you please
> explain when I should use a 1-space indent and when 2-space, please, 
> otherwise
> this seems just arbitrary.  I do find a 1-space indent makes it more 
> difficult to
> see the alignments when the lines are some distance apart.

I'm afraid I can't give you a definitive list of 2-space vs 1-space keywords;
AFAIK, it's just a feature of standard Lisp indentation style, which is why it's
advisable to use an editor which does it properly.

Here's a link which explains it a bit more clearly:
http://evalwhen.com/scmindent/index.html

> So is http://codereview.appspot.com/164063 now ready to go?

The indentation in translation-functions.scm is still a bit wrong, but apart
from that, it looks fine.

Regards,
Neil

[c_sorensen, 2009-12-21 00:58:37]

On 12/20/09 2:48 PM, "n.puttock@gmail.com" <n.puttock@gmail.com> wrote:

> On 2009/12/14 12:13:07, t.daniels_treda.co.uk wrote:
> 
>> I think I've corrected the formatting errors as you suggested.
>> Could you please
>> explain when I should use a 1-space indent and when 2-space, please,
>> otherwise
>> this seems just arbitrary.  I do find a 1-space indent makes it more
>> difficult to
>> see the alignments when the lines are some distance apart.
> 
> I'm afraid I can't give you a definitive list of 2-space vs 1-space
> keywords; AFAIK, it's just a feature of standard Lisp indentation style,
> which is why it's advisable to use an editor which does it properly.

I've never had anybody turn down a patch by me because I had the wrong
number of indents, ore even call me on it, because the rules are not well
enough understood by us mere mortals (it's all in the indenter code).

Every time I've been called on indentation problems it's been because my
indentation is inconsistent within one indentation block.

I think if you always did 2 space indentation consistently nobody would
complain.

HTH,

Carl

[t.daniels_treda.co.uk, 2009-12-21 01:07:09]

<n.puttock@gmail.com>, Sunday, December 20, 2009 9:48 PM


> On 2009/12/14 12:13:07, t.daniels_treda.co.uk wrote:
>
>> I think I've corrected the formatting errors as you suggested.
>> Could you please
>> explain when I should use a 1-space indent and when 2-space, 
>> please,
>> otherwise
>> this seems just arbitrary.  I do find a 1-space indent makes it 
>> more
>> difficult to
>> see the alignments when the lines are some distance apart.
>
> I'm afraid I can't give you a definitive list of 2-space vs 
> 1-space
> keywords; AFAIK, it's just a feature of standard Lisp indentation 
> style,
> which is why it's advisable to use an editor which does it 
> properly.
>
> Here's a link which explains it a bit more clearly:
> http://evalwhen.com/scmindent/index.html

Thanks Neil, that's very helpful.  I now understand
why it is difficult to explain the indenting in words.

It is also useful to know what the different levels of
indentation mean when reading code.  After all, there's
not much point in indenting lines differently if the
meaning of the different indents is not understood by
readers.  Although if these indentation rules have not
been applied consistently in existing Lily code I guess
they can't be relied on (yet).

>> So is http://codereview.appspot.com/164063 now ready to go?
>
> The indentation in translation-functions.scm is still a bit wrong, 
> but
> apart from that, it looks fine.

OK, I'll get the emacs indenting script working, fix the
indenting, and push.

Thanks,
Trevor

[t.daniels_treda.co.uk, 2009-12-24 14:14:54]

Trevor Daniels Monday, December 21, 2009 1:07 AM
>
> <n.puttock@gmail.com>, Sunday, December 20, 2009 9:48 PM
>
>> On 2009/12/14 12:13:07, t.daniels_treda.co.uk wrote:
>>
>>> So is http://codereview.appspot.com/164063 now ready to go?
>>
>> The indentation in translation-functions.scm is still a bit 
>> wrong, but apart from that, it looks fine.
>
> OK, I'll get the emacs indenting script working, fix the
> indenting, and push.

Well, in the end I used Emacs to indent the code
I'd added.  I failed to get the script to work,
and also failed to discover why :(  I'm still a noob
at Unix and unixy things like Emacs.  So I used Emacs
itself, which sort-of worked.  I found it messed
up the indenting of docs strings if I applied it to the
whole of scm/translation-functions.scm, so I indented
just a small region which included my code.  And
then I pushed.  Hope that's ok.

I'll document these additions (whitespace and lettered
tab) after Christmas.  Best wishes to all!

Trevor