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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
