Re: Towards a new pitch representation

[Hans Aberg]

On 31 Dec 2010, at 10:59, Felipe Gonçalves Assis wrote:

> > I made a proposal for a representation, and there is Haskell code  
> > available
> > if you are interested.
>
> Hi Hans. I would very much appreciate that code.

I have put it up here.
https://www-lagring.telia.se/Shares/Home.aspx?ShareID=069b86e6-3f8d-4d4e-a328-f7e9d4a6c121

I run it in Hugs <http://haskell.org/hugs/>; start it using from the  
directory above the unpacked one by
  hugs Score.Staff
On a Mac, I add -Eopen, so ':e' opens the file in an editor.

This is the file that computes the accidentals from a staff system.  
Get back to here if you want more info.

There is another module Score.Scale with the pitch model. Those are  
not entirely synced together. The module Score.Intervals contains  
intervals I got from Scala.

> I should remark
> that your emails are what inspired me to start this. I take this  
> opportunity
> to thank you for everything.

It would be nice if it can serve as an inspiration for you tom  
implement something in LilyPond.

> > In it, the staff positions are expressed by a linear combinations  
> > of a
> > sequence of seconds m, M, n_0, ..., n_k (whatever names you want to  
> > give
> > them). If one only has a minor second m and a major second M, then  
> > sharps
> > raise with the interval M - m and the flats lower with that interval.
> >
> > So I generalized this as to compute for any set of accidentals. The
> > algorithm will depend on the typesetting preferences, but it is  
> > possible to
> > compute them without any reference to pitches at all.
>
> So, my idea is the same, except that I use the differences between the
> seconds, so that the degree is just the coefficient of the major  
> second,
> and the calculation of accidentals is simpler (again, see notes on  
> section
> 2.1 of towards123.txt).

Yes - it gets more complicated when having more accidentals.  
Musically, one plays on the seconds, and the accidentals only show up  
to express differences between them:

Define a tuning system by some intervals like the fifth P5 having the  
interval 3/2 and the octave P8 2, which gives the Pythagorean tuning,  
or replace the fifth with the major third M3 set to 5/4, which gives  
quarter-comma tuning.

Then express these intervals algebraically without their values in  
linear combinations of the minor second m and the major second M: P5 =  
m + 3M, P8 = 2m + 5M, M3 = 2M.

When computing the tuning system, one expresses the intervals  
abstractly like this, which is also what the staff system expresses:  
these algebraic relations. Then this leads to a matrix which should be  
inverted in order to get actual values for m and M.

So what I do is a generalization of this.

> > Rational numbers are not sufficient for the theoretically given:  
> > one must be
> > able to take roots, for example when computing meantone values.
>
> Firstly, I repeat that the use of rational numbers would be  
> algebraically
> equivalent to integers, so this does not come to the theoretical  
> discussion
> here, it would be just convenient with regards to backwards  
> compatibility.
>
> Secondly, taking roots does not change the situation. You can  
> represent
> that just using one more integer in your representation for each root.
>
> Finally, we are primarily concerned with notation here, so the fact  
> that we
> represent a sharp by +1/2 does not forbid you to write a midi  
> engraver that
> implements your favourite temperament (as close as midi can get to  
> that).

I'm not sure exactly what model you have in mind, but this is mostly  
necessary in order to produce sound files, and possibly if one would  
want to impose algebraic relation, though for example E12 (12-ET)  
enharmonic equivalences can be introduced by adding/subtracting  
muliplse of M - 2m.

LilyPond has now 2^r, where is rational, thought that is not fully  
implemented for example for key signatures, which only accept E24.

So I extend this to 2^r_1 3^r_2 5^r_3 ..., which I represent as a map  
(associative array)
  (2, r_2) (3, r_3) (5, r_5) ...
Since one does not need to add these numbers, one mostly just has to  
add exponents.

This data type then includes not only the rationals, but also all ETs  
as well other systems like the Bohlen-Pierce scale.

> > So, for the exact given values, I added those roots. This suffices,  
> > as one
> > is never going to add the numbers of the intervals - interval  
> > addition
> > correspond to multiplication of numbers. The implementation  
> > representation I
> > chose was as a prime factorization - a map from prime numbers to  
> > rational
> > numbers. This seems to work well, as one is typically just working  
> > with a
> > few small prime numbers.
>
> Oh, I see. That is actually what I was talking about in towards123  
> when
> I pointed the isomorphism between Z^(inf) and Q*, but that sounds like
> unnecessary trouble to go with, even though it might look beautiful in
> your Haskell code.

Yes, I think this may be a good candidate. The only practical problem  
would be if one would encounter a large prime, which would happen if  
say converting floats to rationals. But this is not very convenient,  
floats as rational, to to work with and slow. So I added the floating  
point part, to, which I just write out as cents, though internally it  
is just a factor.

> > But when working with inexact intervals, like in pitch bends or  
> > given s
> > cents, etc., this proved inconvenient.
> >
> > So I added an inexact part, a floating point number (double). The
> > representation is thus (r, x), where r is the exact number above,  
> > and x a
> > floating point number. When x = 1.0, the representation is  
> > considered exact.
>
> That is fine. But once more I remark that we are interested here in  
> notation.
> What you are attaining is to represent frequencies in a way that is  
> virtually
> always exact for music concerns (which looks quite promising, by the  
> way).

The problems are in fact related: in the current model, typesetting is  
tied to the tuning. So for example, the Arab music file uses E24,  
because that is the only thing that works with key signatures. But the  
actual music does not use that. So it is not easy to alter that.

By splitting these up, one can typeset without reference to the  
tuning. But people will want to produce sound files, at least for  
debugging. Then that could be developed quite independently.