[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.
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.
- Re: Towards a new pitch representation, (continued)
- Re: Towards a new pitch representation, Felipe Gonçalves Assis, 2010/12/31
- Re: Towards a new pitch representation, Felipe Gonçalves Assis, 2010/12/31
- Re: Towards a new pitch representation, Carl Sorensen, 2010/12/31
- Re: Towards a new pitch representation, David Kastrup, 2010/12/31
- Re: Towards a new pitch representation, Carl Sorensen, 2010/12/31
- Re: Towards a new pitch representation, Felipe Gonçalves Assis, 2010/12/31
- Re: Towards a new pitch representation, Carl Sorensen, 2010/12/31
- Re: Towards a new pitch representation, Felipe Gonçalves Assis, 2010/12/30