Re: Change stringTunings entries from semitones to pitches (issue3842041)

[Carl . D . Sorensen]

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

Thanks,

Carl



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

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/fretted-strings.itely#newcode477
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#newcode120
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#newcode28
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#newcode43
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#newcode96
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.

http://codereview.appspot.com/3842041/