lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pb with 2.13 with doc example fret diagram


From: Carl Sorensen
Subject: Re: pb with 2.13 with doc example fret diagram
Date: Wed, 22 Dec 2010 07:36:24 -0700



On 12/21/10 11:35 PM, "David Kastrup" <address@hidden> wrote:

> David Kastrup <address@hidden> writes:
> 
>> Carl Sorensen <address@hidden> writes:
>> 
>>> The final answer is that it will be quite easy to to create a music function
>>> that creates a string tuning object.  How would this syntax be?
>>> 
>>> \makeStringTuning #'violinTuning {e' a d g}
>>> 
>>> If this sounds good, I'll have it done in the next day or so.
>> 
>> I think that
>> 
>> \makeStringTuning #'violinTuning <e' a d g>
>> 
>> would be more natural.  Even more natural would be
>> 
>> \makeStringTuning #'violinTuning <g d a e'>
>> 
>> And if we want to be correct, we'd better use
>> 
>> \makeStringTuning #'violinTuning <g d' a' e''>

I completely agree.

> 
> Actually, what's wrong with
> 
> violinTuning = \makeStringTuning <g d' a' e''>

music functions return music, and the string tuning is not music.

/makeStringTuning #'violinTuning <g d' a' e''>

would set the value of 'violinTuning and return void music.

The direct setting for a tuning would be

violinTuning = 
  #(list 
     (ly:make-pitch 1 2 0)
     (ly:make-pitch 0 5 0)
     (ly:make-pitch 0 1 0)
     (ly:make-pitch -1 3 0))

Or, now that I think about it, we could keep the order in the tuning the
same -- lowest string first instead of highest string first.  And when we do
the comparisons for fret calculations, since we already have to do
conversion to semitones above middle C, we can reverse the list.

I guess we could have a stringTunings be music, but then we'd need to do the
extraction all the way from music to semitones every time we wanted to use
it, which seems very inefficient to me.

We currently have one actual use for stringTunings (conversion from notes to
frets) and one proposed use for stringTunings (displaying a tab key).  The
note to fret conversion uses semitones, which is why the current value is a
list in semitones.  The proposed use wants to have correct spelling, so
semitones aren't sufficient.  This is a reason to move to pitches.  It comes
at the cost of some computation, but there's a structural reason for it.

Storing the stringTunings as music would require conversion from music to
semitones every time it is used, i.e. for every note that appears in a
tablature or in an automatically-calculated fret diagram.  It could
certainly be done, but seems to me to be a great deal of unnecessary
calculation.  Hence my proposal.

Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]