Re: Towards a new pitch representation

[Carl Sorensen]

On 12/31/10 1:31 AM, "Felipe Gonçalves Assis" <address@hidden>
wrote:

> Hi,
> 
>> 
>> Are you using a two-element list, or a cons cell?  The two are not the same.
>> 
>> I seem to remember looking in the code, and seeing scm_cadr calls, which
>> implies that your alterations would be (1 -1), not (1 . -1).
>> 
> 
> In scheme I am using a cons cell, in C++ I am using a new struct with
> overloaded
> operators. I was using the terms "list" and "pair" in an informal way. Sorry
> for
> the confusion.
> 
>> 
>> If we are going to move to a list for alterations, the list should probably
>> be rationals, rather than integers, in order to be most general.  Thus it
>> should most likely be (1/2 -1/4), rather than (1 -1).
>> 
>> Alternatively, you will need a property somewhere which is a list of the
>> base units for each alteration, so that an alteration would be (1 -1), and
>> the alterationMagnitude would be (1/2 1/4).
>> 
> 
> Right. In my patch this alterationMagnitude was sneaked in as new arguments
> for make-scale. So, by redefining the default-scale, you get what you want
> (see ly/makam.ly in the patch and dodecaphonic-adapted.ly in my previous
> message).
> 
> As I said, if you are going to use only a finite number of rationals, you
> can always accomplish the same results by using integers and scaling
> them accordingly. This scaling is only used for things like midi and
> ambitus. For transposition, and engraving, you only need the integers.
> 
>> In the current patch, you force all alterations to be lists (or cons cells,
>> whichever you have implemented).  This will break lots of old scores.  It
>> would be cleaner to allow alterations to be numbers (as they were in the
>> past) or lists.  Then the old code would work.  Otherwise, you'll need to
>> make a convert-ly rule which may be a bit tricky.
>> 
>> I think that as long as you *allow* but don't require the extended pitch
>> representation, it's likely to be very well accepted.
>> 
> 
> That is an important point. Below is what can be argued in defense
> of this.
> 
> . For code that only uses 1/4 alterations, and does not redefine the
>   default scale, convert-ly will be enough.
> . The only snippet in the LSR that calls ly:set-default-scale is
>   precisely dodecaphonic.ly.
> . Integers are faster than rationals.

For some large percentage of music written (certainly greater than 90%,
probably more like 99%), quarter-tone accidentals are irrelevant.  If you
keep the standard notation for this case, I think you'll get the best
possible performance, and you'll make code entry as easy as possible for
people -- they can keep doing it the way they've always done it.  And it's
not hard to code.  Why not do it?

> 
> So, admittedly, this idea of using a list of rationals, simple as at is,
> only occurred to me while writing towards123, yesterday.
> 
> If the community decides for that, I will start working on a new patch
> as soon as the order is given.
> 
> So, unless someone comes up with a completely new idea, what we
> have to decide is
> 
> a. Rationals or Integers?

Probably integers, with a rational magnitude list that is used to convert to
midi.

> ais. How many of them?

No need to decide how many of them.  Just make the argument a list, instead
of a cons cell, and give the user access to change the length of the list if
they want to.  For the default distribution, the list length should be two,
because we have symbols for quarter-tone alterations, but no symbols for
anything smaller.

In makam.ly, we may want to have a different list length.  I don't know,
because I haven't done anything with turkish music.

Thanks,

Carl