Re: Towards a new pitch representation

[Felipe Gonçalves Assis]

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.

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?
ais. How many of them?

I look forward to hearing from you.

Cheers,
Felipe