Yahoo Tuning Groups Ultimate Backup tuning Re: A mode room on line

Hi Simon Sun,

> We are still thinking about the design and operation. I agree that
> the
> file format is quite important, especially I have to include some
> discussions, reference information etc. So I am still thinking how
> should I put them - put into different files or can be in same file
> with proper enclosing on all the content. Robert's idea of the file
> types is quite useful to us and we'll take that into consideration.

Thanks, if there is any way I can help...

>
> Actually, I'm a bit curious about how the modes should be stored. Is
> it more useful if the ratios are in cents? If then, is it good for
> allowing users to enter cents only, or allow users to enter fraction?

Yes, this goes straight to one of the first questions one needs to
ask as programmer during design stage.

The SCALA method is best, where a mode is stored as steps in
an underlying scale.

Then you only need to define the mode once, and can use it for,
e.g. any tempering of a 12 tone scale.

Now, some modes begin at other than first note of scale, e.g.
some gamelan modes. Scala shows those using number in brackets
[3] 1 1 2 1 2 Tembung
(pelog mode)

In FTS, for data entry and showing mode, I require that first step
is given, and it is 0 if mode starts at first note of scale

(I may add the [] notation as alternative format soon)

So then, assuming one uses that method, question is, are the scales entered in cents or ratios.

**************parsing of scale values***************************

It's no good just looking for the '/' symbol to tell which it is since
one wants to be able to enter 2 on its own instead of 2/1 when typing the
scale in as data, for speed - if user does that, don't want to call it
2 cents!

Next idea is to have tick box to say if scale is in cents or ratios,
but that is no good either as mixed notations are common.
E.g. quarter comma mean-tone with the 5/4 in it, to take
simple ex.
Or 1/1 256/243 192.18 cents 32/27 390.225 cents 4/3 1024/729
696.09 cents 128/81 888.27 cents 16/9 1092.18 cents 2/1
for Werckmeister III.

So supposing one decides to accept mixed notation - best
to do that - how does one know which is which.

One needs to be able to do it by checking if next token
is the word "cent" or "cents", since if the value is entered
in that way, should be correct.

Also prog may show the word "cents" itself (or at least
have option to do so), and the way
edit boxes work in programs that use a Gui is that
values displayed in them can be edited by the user
and so must be acceptable values for input too.

So scale parsing is going to need look ahead,
or something equivalent, though only
by one token (I do it in FTS by reading value as ratio,
then on reaching next token, if it says "cents", re-interpret
most recent value as in cents instead).

But it is too laborious to require user to type the
entire word "cents" each time!

The way SCALA does it, values for scale defs
can be in cents or as ratios. If the value has a decimal point in it,
it is assumed to be in cents, which saves typing when entering
values by hand.

FTS doesn't do that because of possibility, to
display the ratio in decimal format, e.g. 1.25 for 5/4.
Even though one will hardly ever choose to enter
a scale in this format, one may want to choose to show
it that way, and if one has that option, it has to be recognisable
as input in a Gui.

So in FTS I added the abbreviation '10 for 10 cents for data entry.

I.e prefix the number with the character ' or `.

Here one could have a tick box - "recognize cents by decimal pt"
which is automatically switched off, or better, disabled / hidden
when one chooses to show ratios in decimal format. (I may add
that as option to FTS come to think of it).

Clearly best to think over these issues really early on,
prob. before one writes the first line of code!

If you want to be really sophisticated, do what Scala and FTS do,
and build in a little equation parser into your program, so
values can be entered using mathematical formulae.
So you can use, e.g.

1/1 2^(1/31) for 31-tet

I could provide the c-source code for the FTS one - as I wrote it
myself from scratch. It's quite small for such a thing (about 400
or 500 lines of c-code), reasonably fast, and I could convert it to
java and maybe include on my web site code snippets page as
an ex. of how to do it.

At present it is limited to use of single character short cuts for
mathematical functions, e.g. r3 for sqrt(3). But you could
deal with that by a pre-parsing search and replace for
mathematical functions, and maybe I'll do that too.

SCALA uses one generated by a compiler compiler
type method, so you could do that too.

Then whenever you parse a number, you just need to pass
the token to the equation parser, and use its return value
as the parsed value for the token.

Like this:

c declaration of equ. parser:
double parse_equation(char *token, BOOL value_is_in_cents);

Use of it:
value = parse_equation( token, value_is_in_cents)

You will have to tell the parser whether the equation is for a value in cents, or for a pure ratio
so it knows what to return.

You can just use it as a "black box".

Another thing one needs to think about at the beginning, one doesn't want to assume, and hard code in, that scale repeats at octave.

That's because of, e.g. Bohlen-Pierce scale that repeats at 3/1

However another reason is that one will want to be able to define
a scale that has repeating blocks using just one block,
e.g.
0 cents 38.709677 cents for 31-tet.

Rather than work out all the values for i = 1 to 31, if you
allow scales that repeat at any interval, you can simply define
the scale internally as
1 1.0226114 (2 entries)

Another thing one needs to think about, one may well
at some stage want to be able to enter scales
as harmonics:
4 5 6 for 1/1 5/4 3/2

*****************harmonic series as a scale*********************

In FTS, I include a method of defining a harmonic series
using an additive definition, which may poss. be of
interest?-

here it is
---------------------------------------------------

In FTS, you need to enter the 1/1 - or 1 for short - that begins the scale
(in SCALA it is left out, and scale is assumed to start at 1/1),

If first entry is anything other than 1, scale is taken as giving an additive
definition.

For instance you can define the harmonic series as:

The number 2 is the frequency of the first harmonic, as a multiple of the frequency of the
fundamental.

The harmonic series is then found by repeatedly adding the frequency difference between the
fundamental and the first harmonic.

For instance, the harmonic series starting at A is

440, 2*440, 3*440, 4*440, 5*440, ... adding 440 each time.

I define negative numbers for the mode in harmonic series scale as an upside down harmonic series:

1 1/2 1/3 1/4 1/5 1/6 ....

In the same notation, 1+1/5 would be short for a first "harmonic" of 1+1/5, i.e. a generalised
harmonic series of

1, 1+1/5, 1+2/5, 1+3/5, ...

or starting at 440,

440, 440+(440/5), 440+(2*440/5), 440+(3*440/5),...

Since 6/5 is the ratio of the sixth to the fifth harmonic, this gives the harmonic series from the fifth
harmonic of fundamental at 88 hz upwards.

The upside down series will be

1 1/(1+1/5), 1/(1+2/5),....

Any ratios of the form (n+1)/n will give successive members of the harmonic series from the nth
harmonic upwards.

Other ratios like 5/3 or 11/9 also pick out members of the harmonic series, with gaps. For instance
5/3 picks out every other harmonic from the 3rd upwards.

----------------------end of additive scale def-----------------------------

Anyway, however one does it, one will prob. at some point in the future want
to have a way of using the harmonic series itself as the underlying scale for use in "mode"
definitions.

Could just be a tick box, "scale is harmonic series" - much easier to program prob..

Then major chord is
4 1 1 (step notation - 4 5 6 in degree notation)

in harmonic series scale,

or
0 1 1 (step notation)
in the harmonic series defined as

4/3
in my additive def.

(could also be defined as 4 = 1st harmonic + 1 = step in harmonic series scale def, and
enter the values 4, and 1 into suitable boxes)

5 6 7 8 9 10
is David Canright's equal frequency differences pentatonic scale,
or

0 1 1 1 1 1 (step notation)
0 1 2 3 4 5
in scale
5/4 (additive def)

...
Can prob. leave the harmonic series def till late in project, but good
to bear in mind that it might be needed at some point in the
future when working on the basic design.

I implement the harmonic series internally as a scale def like all the
others, and only go up to some large number in the series.
(at present, use array of 1000 values for scale defs, which has been fine
for all the ones encountered so far)

Another consideration is, how to internally store the numbers for the scale
def.

*********internal storage of ratios and cents values**************

I don't know how SCALA does it. In FTS, I just store them as doubles
(= c prog. language high precision floating point)
e.g. as 1.25 for 5/4.

Then for display, I use the (v. fast) continued fraction algorithm
which by a number theory theorem gives a closer ratio to
any floating point number than any other ratio with same size
quotient or smaller.

So it uses this algorithm on 1.25 and comes up with 5/4 as factorisation.

Even for a difficult case like
1.1494390589260

it reaches the ratio v. quickly:
7/6 8/7 23/20 923/803 1946/1693 2869/2496 7684/6685 10553/9181

However if you do it that way, you have to bear in mind that
some et scale steps happen to be rather close to pure ratios:

Ex.
419914/404871 happens to be within 1e-12 of 2^(1/19) - step for 19-tet.

FTS deals with this by restricting the max factor to use
in the denominator / denumerator (requires them to be
at most 50 limit, with option to change that value)

419914/404871= 2*11*19087/(3*19*7103)
which is decidedly _not_ 50 limit, so shows value in
cents.

Similarly,
2^2*3*7*7789/(31*20639)
is within 1e-12 of step for 31-tet.

In practice, this hasn't turned up any stray pure ratios
for et scales, so it works.

Does need a limit on size of denominator as well or you
will eventually get some ratios close to et degrees.

I use
100,000,000
as max denominator in FTS and that hasn't turned up any
stray pure ratios to date.

Other way round, it always finds the ratio if it _is_ a pure ratio, by the
theorem that continued fractions method finds the optimal ratio
for its size of quotient mentioned above.

Would be nice if one could prove some theorem
to show that it will always work:

---------theorem it would be nice to prove-----------

Objective - to find values of epsilon, k, N and n such that
there are no k-limit ratios with max quotient N within epsilon
of any et scale degree in any m-tet for m less than n.

However such results are likely to be extremely hard
to prove, as some simple questions about irrationality
remain unsolved in Number theory, though many general
cases have been cracked.

For instance I've just done a web search for e and pi,
and found that it is known that e*pi is irrational, but it is still not
known if e+pi is is rational or irrational.

http://www.math.niu.edu/~rusin/known-math/98/pi_e
(author's web site http://www.seanet.com/~ksbrown/)

Interesting situation:
>THEOREM. e + pi is irrational or e - pi is irrational.
>
>Proof: Suppose e + pi and e - pi are rational. Then by addition, 2e is
>rational. Contradiction.
>
- that's from
http://www.math.psu.edu/simpson/fom/postings/0006/msg00101.html

Unless we are lucky. Sometimes you find someone has proved a theorem
that just gives you what you want.

------------end of theorem wish list---------------------

Could do computer search of all et scales up to 183 (largest
number in SCALA mode names file) however, and
I think I might do that, having thought of it.

If you want to use the continued fractions method to find ratio from
double, again you are welcome to use my subroutine converted to
java, and I could add it to my Windows C snippets page.

Alternative would be to store ratios internally as a pair of integers,
and that may be something to consider at design stage.

Anyway, sure that's given lots to think over, good luck with the design
stage.

I often spend a long time on the design stage - sign of some maturity
in programming I hope.

So often happens that by waiting a few more days, you get an idea
for the design that is going to save maybe weeks of work when you
get down to the coding.

And once you've got a reasonable body of code written, it can be
pretty difficult to change the basic design, should it become necessary.

Robert

Re: A mode room on line

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

🔗Joseph Pehrson <josephpehrson@compuserve.com>

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>