[Top][All Lists]

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

Re: Towards a new pitch representation

From: Hans Aberg
Subject: Re: Towards a new pitch representation
Date: Fri, 31 Dec 2010 13:19:49 +0100

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.

I run it in 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.

reply via email to

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