Change stringTunings entries from semitones to pitches

Change stringTunings entries from semitones to pitches

This lays the foundation for creating a TabKey grob that lists
the pitches of each string in the tablature.

Create a new file ly/string-tunings-init.ly
  Defines \makeStringTuning, which takes an absolute-mode chord
    as an argument, so stringTunings definitions are more easily
    human-readable.
  Collects all the default tunings from scm/tablatures.scm, and
    defines them using \makeStringTuning.
  Adds tunings for orchestral strings.

Add table documenting predefined string tunings to appendix.

Write convert-ly rule for change.

Apply convert-ly to source tree.

Edit updated source files to comply with standard .ly formatting guidelines.

Change definition in python/musicexp.py

Update Docs to match new syntax.

[Carl, 2010-12-24 19:31:51]

Here's a patch that changes stringTunings entries from semitones to pitches.

This is needed to allow a TabKey grob to be created.

Also defines stringTunings for orchestral strings, and includes a function to
allow the definition of stringTunings using absolute mode chords.

Please review.

Merry Christmas!

Carl

[Keith, 2010-12-29 02:25:44]

I'm not a programmer, but accustomed to doing code review as a systems engineer.


> Change stringTunings entries from semitones to pitches
> This lays the foundation for creating a TabKey grob 

Presumably the idea is to store the correct spelling of the note in the future
TabKey, should anyone tune a string to des or cis.  Tell us if there is a
less-obvious reason.

I *thought* that this would make \transpose, when applied to the whole score,
shift the tuning as well.  When I tried your patch, though, only the music was
transposed and not the tuning.  I think that is fine; I'm just jiggling our
brains looking for side-effects.

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
Documentation/notation/fretted-strings.itely:477: A string tuning is a Scheme
list of string pitches,
Your \makeStringTuning allows us to proceed without knowing this.  If you move
the "Any desired" and "As a convenience" paragraphs up here, with a bit of
rewording and with the example, then readers are spared the trouble of reading
and then partially /un-learning/ these paragraphs.

http://codereview.appspot.com/3842041/diff/6001/ly/declarations-init.ly
File ly/declarations-init.ly (right):

http://codereview.appspot.com/3842041/diff/6001/ly/declarations-init.ly#newco...
ly/declarations-init.ly:120: \include "property-init.ly"
the re-ordering looks nice, but any other reason?

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly
File ly/string-tunings-init.ly (right):

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:28: (ly:parser-define! parser tuning-symbol (reverse
pitches))))
ordering. If we reverse here, the two methods of entering a tuning require
opposite orders of entry.
An arbitrary decision was made in 2002 to enter the tuning and number strings in
the top-to-bottom vertical order of the printed tablature, and no inputs to that
decision have changed.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))
Is it possible to return a PropertySet event instead?  If so, we could call it
\setStringTuning and define the tuning where it is \set :
\new TabStaff {
 \setStringTuning TabStaff.stringTunings  <c' g' d'' a''>

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:96: ;; orchestral strings
Why bother to add more default tunings?  With the semitone method, people needed
help to get them right, but your patch makes it easier to enter a tuning than to
look up the name.

[Carl, 2010-12-29 03:37:12]

On 2010/12/29 02:25:44, Keith wrote:
> I'm not a programmer, but accustomed to doing code review as a systems
engineer.
> 

I very much appreciate the review.  Thanks!

> 
> > Change stringTunings entries from semitones to pitches
> > This lays the foundation for creating a TabKey grob 
> 
> Presumably the idea is to store the correct spelling of the note in the future
> TabKey, should anyone tune a string to des or cis.  Tell us if there is a
> less-obvious reason.

That is exactly the reason.

> 
> I *thought* that this would make \transpose, when applied to the whole score,
> shift the tuning as well.  When I tried your patch, though, only the music was
> transposed and not the tuning.  I think that is fine; I'm just jiggling our
> brains looking for side-effects.

StringTunings is a characteristic of an instrument, not a characteristic of
music.  So I don't think that transpose should affect StringTunings.

I'll respond to your detailed comments in the body.

Thanks,

Carl

[Carl, 2010-12-29 03:50:23]

Thanks again for the review.  Here are my responses to your comments.

Thanks,

Carl

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
Documentation/notation/fretted-strings.itely:477: A string tuning is a Scheme
list of string pitches,
On 2010/12/29 02:25:44, Keith wrote:
> Your \makeStringTuning allows us to proceed without knowing this.  If you move
> the "Any desired" and "As a convenience" paragraphs up here, with a bit of
> rewording and with the example, then readers are spared the trouble of reading
> and then partially /un-learning/ these paragraphs.

I'm fine to change the order, but I don't want to eliminate the definition of a
string tuning.  The context property that is stored is a list of pitches.  If
people want to use the property as part of a scheme function, for example, they
need to know that it's a list of pitches, rather than a chord.

http://codereview.appspot.com/3842041/diff/6001/ly/declarations-init.ly
File ly/declarations-init.ly (right):

http://codereview.appspot.com/3842041/diff/6001/ly/declarations-init.ly#newco...
ly/declarations-init.ly:120: \include "property-init.ly"
On 2010/12/29 02:25:44, Keith wrote:
> the re-ordering looks nice, but any other reason? 

Yes.  If the file is not reordered, an error is thrown.  The reordering was done
in a trial-and-error fashion; I'm not sure that the minimal necessary reordering
was done, but without the reordering lilypond would throw an error while parsing
this file.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly
File ly/string-tunings-init.ly (right):

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:28: (ly:parser-define! parser tuning-symbol (reverse
pitches))))
On 2010/12/29 02:25:44, Keith wrote:
> ordering. If we reverse here, the two methods of entering a tuning require
> opposite orders of entry.
> An arbitrary decision was made in 2002 to enter the tuning and number strings
in
> the top-to-bottom vertical order of the printed tablature, and no inputs to
that
> decision have changed.

The order in the internal storage is somewhat less than arbitrary.  Both are
ordered in string order.  That is, string 1 is the highest string, and string 1
is the first entry in StringTunings.

The order for the chord entry was requested by the users.  Chords are generally
entered lowest note first.

While the two are in different orders, I think there are rational reasons for
the difference.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))

We need to save the string tuning in a Scheme variable, because that string
tuning is used as a key to store predefined fretboards.  So the PropertySet
method would not meet the full needs.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:96: ;; orchestral strings
On 2010/12/29 02:25:44, Keith wrote:
> Why bother to add more default tunings?  With the semitone method, people
needed
> help to get them right, but your patch makes it easier to enter a tuning than
to
> look up the name. 

Because the users who requested this change asked for it.  Similar to the desire
to use

\lanugage "italiano"

instead of 

\include "italiano.ly"

The users preferred to say

\set StringTunings = #violin-tuning

instead of 

\makeStringTuning #'violin-tuning <g d' a' e''>
\set StringTunings #'violin-tuning"

And I've already indicated why we don't want to just use a PropertySet music
function.

[Keith, 2010-12-29 05:18:07]

Everything I know how to check looks good.

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
Documentation/notation/fretted-strings.itely:477: A string tuning is a Scheme
list of string pitches,
> I'm fine to change the order, but I don't want to eliminate the definition of
a
> string tuning. 
Sounds good.  Having the info about the Scheme representation closer to the
@file links down below would be great.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly
File ly/string-tunings-init.ly (right):

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:28: (ly:parser-define! parser tuning-symbol (reverse
pitches))))
> The order in the internal storage is somewhat less than arbitrary.  
Agreed. My earlier 'arbitrary' was a mental slip. I was thinking the choice was
sensible, but even if it were arbitrary I would be scared of change.

> The order for the chord entry was requested by the users.  Chords are
generally
> entered lowest note first.

Yes, but were the users right?  I would have asked for that order of entry, too,
but would have changed my mind for fear of bugs when reminded that the old way
to specify tuning was in order of string numbering.  (Bugs made by me in my .ly
files, that is)
If you found this reversal not too error-prone, then maybe the users were right.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))
> We need to save the string tuning in a Scheme variable...
But if it is possible to set the variable as you do now, and then return a
PropertySet instead of the void event,
(begin
  (chord->tuning parser tuning chord)
  (context-spec-music 
    (make-property-set 'stringTunings tuning )
  'TabStaff)
)
then we could 
\new TabStaff {
 \setStringTuning #'a-fiddle-tuning <g d' a' d''>

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:96: ;; orchestral strings
On 2010/12/29 03:50:23, Carl wrote:
> On 2010/12/29 02:25:44, Keith wrote:
> > Why bother to add more default tunings?  
> Because the users who requested this change asked for it.  
Okay. I saw the request for an easier entry method but not for the pre-define.

[pkx166h, 2010-12-29 09:13:24]

Just a couple of Doc-policy things

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
Documentation/notation/fretted-strings.itely:484: A string pitch in a string
tuning list is a LilyPond pitch
Is 'LilyPond pitch object' such a term that it needs an @emph or @code done to
it - just a question.

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
Documentation/notation/fretted-strings.itely:524: chord construct must be in
absolute note mode, and the string
Hello, referred to 'Absolute octave entry' in the NR, not 'Absoulte note mode'.
Could we also have an @ref{} here too please (and thus an addition to the
@seealso).

[marc, 2010-12-29 18:22:56]

Am 29.12.2010 06:18, schrieb k-ohara5a5a@oco.net:
> [...]

> The order for the chord entry was requested by the users.  Chords are
> generally
>> entered lowest note first.
>
> Yes, but were the users right?  I would have asked for that order of
> entry, too, but would have changed my mind for fear of bugs when
> reminded that the old way to specify tuning was in order of string
> numbering.  (Bugs made by me in my .ly files, that is)
> If you found this reversal not too error-prone, then maybe the users
> were right.
At first sight, I thought that it would be better to use a input method
that resembles the string numbering (i.e. first pitch -> first string).
But for duitar, there is a tuning (from low to high) called DADgad, and
whether correct or not, there are some book concerning this kind of
tuning, and the tuning is always called "DADgad", not "dagDAD".
So I think this is more consistent with the normal practice.

Just my 2ct ...

Regards,

Marc

[marc, 2010-12-29 18:25:38]

Am 29.12.2010 19:22, schrieb Marc Hohl:
> [...]
> But for duitar,
I meant "guitar", of course - don't know how a "duitar" is tuned and 
played ;-)

Marc

[James.Lowe_datacore.com, 2010-12-30 11:42:10]

________________________________
From: lilypond-devel-bounces+james.lowe=datacore.com@gnu.org
[lilypond-devel-bounces+james.lowe=datacore.com@gnu.org] on behalf of Marc Hohl
[marc@hohlart.de]
Sent: 29 December 2010 18:25
To: Carl.D.Sorensen@gmail.com; lilypond-devel@gnu.org;
reply@codereview.appspotmail.com
Cc: k-ohara5a5a@oco.net
Subject: Re: Change stringTunings entries from semitones to pitches
(issue3842041)

Am 29.12.2010 19:22, schrieb Marc Hohl:
> [...]
> But for duitar,
I meant "guitar", of course - don't know how a "duitar" is tuned and
played ;-)

---

With gifficulty I expect!

;)

Happy New Year!

James

[cpkc_shaw.ca, 2010-12-30 13:21:23]

On Thu, 2010-12-30 at 11:42 +0000, James Lowe wrote:
> 
> ________________________________
> From: lilypond-devel-bounces+james.lowe=datacore.com@gnu.org
[lilypond-devel-bounces+james.lowe=datacore.com@gnu.org] on behalf of Marc Hohl
[marc@hohlart.de]
> Sent: 29 December 2010 18:25
> To: Carl.D.Sorensen@gmail.com; lilypond-devel@gnu.org;
reply@codereview.appspotmail.com
> Cc: k-ohara5a5a@oco.net
> Subject: Re: Change stringTunings entries from semitones to pitches
(issue3842041)
> 
> Am 29.12.2010 19:22, schrieb Marc Hohl:
> > [...]
> > But for duitar,
> I meant "guitar", of course - don't know how a "duitar" is tuned and
> played ;-)
> 
> ---
> 
> With gifficulty I expect!
> 

But it should be easy to represent it draphically!

Colin
-- 
Happiness is when what you think, what you say, and what you do are in
harmony. - Mohandas K. Gandhi (1869-1948) 

[Carl, 2010-12-31 14:52:36]

On 2010/12/29 05:18:07, Keith wrote:
> Agreed. My earlier 'arbitrary' was a mental slip. I was thinking the choice
was
> sensible, but even if it were arbitrary I would be scared of change.
> 
> > The order for the chord entry was requested by the users.  Chords are
> generally
> > entered lowest note first.
> 
> Yes, but were the users right?  I would have asked for that order of entry,
too,
> but would have changed my mind for fear of bugs when reminded that the old way
> to specify tuning was in order of string numbering.  (Bugs made by me in my
.ly
> files, that is)
> If you found this reversal not too error-prone, then maybe the users were
right.

As far as old files go, the convert-ly rule automatically does the conversion,
so you don't even need to think about it.

As far as new files go, I think the user can learn whatever syntax is necessary.

Thanks,

Carl

[Carl, 2010-12-31 14:54:31]

On 2010/12/29 05:18:07, Keith wrote:

> ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))
> > We need to save the string tuning in a Scheme variable...
> But if it is possible to set the variable as you do now, and then return a
> PropertySet instead of the void event,
> (begin
>   (chord->tuning parser tuning chord)
>   (context-spec-music 
>     (make-property-set 'stringTunings tuning )
>   'TabStaff)
> )
> then we could 
> \new TabStaff {
>  \setStringTuning #'a-fiddle-tuning <g d' a' d''>
> 

I'll add a \setStringTuning function.  I can see its utility.

Thanks,

Carl

[Carl, 2011-01-01 05:04:55]

I've responded to all the commandments and put up a new patch.

Thanks for all of your input.

Please review.

Carl

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/frette...
Documentation/notation/fretted-strings.itely:524: chord construct must be in
absolute note mode, and the string
On 2010/12/29 09:13:24, pkx166h wrote:
> Hello, referred to 'Absolute octave entry' in the NR, not 'Absoulte note
mode'.

The heading is "Absolute octave entry".  The mode is "absolute octave mode" or
"absolute mode" -- see "Relative octave entry".

I've changed to "absolute octave mode".

> Could we also have an @ref{} here too please (and thus an addition to the
> @seealso).

Done.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly
File ly/string-tunings-init.ly (right):

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#new...
ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))
I've added a new music function contextStringTunings (the name is negotiable)
that does the property set as well.

It sets stringTunings for both TabStaff and FretBoards.

I don't want to call it setStringTuning because it will be confused with \set
stringTunings.

[pkx166h, 2011-01-03 16:36:11]

For the Doc/Notation/fretted-strings.itely - that looks good.

I can't comment on the rest.