some output from Graham's cgi

Unison vector input
-------------------

>unison vectors
>· 36:35
>· 50:49
>calculated
>unison vectors
>· 36:35
>· 50:49

Why do you say "calculated" and then list them again?

>0/1, 1886.3 cent generator

A bug? Do we always want the "generator" to be the smaller
generator, and the "period" the larger? Anyway, it would be
nice to see the period.

Are these optimum generators?

>basis:
>(0.25, 1.57192809489)

Never heard of it.

>mapping by period and generator:
>[(4, 0), (0, 1), (3, 1), (5, 1)]

I'm up to speed on this.

>mapping by steps:
>[(4, 0), (-1, 1), (2, 1), (4, 1)]

? Carried out how far?

>highest interval width: 1

?

>complexity measure: 4 (8 for smallest MOS)

From the map above isn't it 5?

>highest error: 0.027608 (33.129 cents)

Why not give rms as well as or instead of this?

List parameters input
---------------------

"""
9 odd limit, or consonant harmonics
15 highest complexity
10.0 worstError (cents)
100 number of equal temperaments to consider
10 number of results to return
0.5 ET goodness cutoff (0.5 is Erlich consistency)
_ Figure of Demerit (optional)
"""

>9-limit
>ETs considered 5 12 19 22 26 27 29 31 41 46 50 53 58 60 68 70 72 /.../

>13/41, 380.4 cent generator
>mapping by period and generator:
>[(1, 0), (0, 5), (2, 1), (-1, 12)]
>complexity measure: 12 (13 for smallest MOS)
>highest error: 0.004942 (5.930 cents)
>unique

>13/31, 503.6 cent generator
>mapping by period and generator:
>[(1, 0), (2, -1), (4, -4), (7, -10)]
>complexity measure: 10 (12 for smallest MOS)
>highest error: 0.009198 (11.038 cents)

>17/46, 443.4 cent generator
>mapping by period and generator:
>[(1, 0), (-1, 7), (-1, 9), (-2, 13)]
>complexity measure: 14 (19 for smallest MOS)
>highest error: 0.007304 (8.765 cents)
>unique

>11/27, 489.6 cent generator
>mapping by period and generator:
>[(1, 0), (2, -1), (6, -9), (2, 2)]
>mapping by steps:
>[(22, 5), (35, 8), (51, 12), (62, 14)]
>complexity measure: 11 (12 for smallest MOS)
>highest error: 0.014090 (16.908 cents)

>6/31, 232.3 cent generator
>mapping by period and generator:
>[(1, 0), (1, 3), (0, 12), (3, -1)]
>complexity measure: 13 (16 for smallest MOS)
>highest error: 0.009322 (11.186 cents)

>3/13, 90.8 cent generator
>mapping by period and generator:
>[(3, 0), (5, -1), (7, 0), (8, 2)]
>complexity measure: 12 (15 for smallest MOS)
>highest error: 0.012155 (14.586 cents)

>19/45, 506.3 cent generator
>mapping by period and generator:
>[(1, 0), (2, -1), (4, -4), (-1, 9)]
>complexity measure: 13 (19 for smallest MOS)
>highest error: 0.013826 (16.591 cents)

Very cool.

-Carl

In-Reply-To: <4.0.1.20020304214213.029dc818@lumma.org>
Carl Lumma wrote:

> Unison vector input
> -------------------
>
> >unison vectors
> >� 36:35
> >� 50:49
> >calculated
> >unison vectors
> >� 36:35
> >� 50:49
>
> Why do you say "calculated" and then list them again?

Because they aren't always the same. The calculated ones should be the
the simplified set. Sometimes they obviously aren't. I know this is a
"simultaneous linear Diophantine equations" problem, but that still
doesn't tell me how to solve it :-(

> >0/1, 1886.3 cent generator
>
> A bug? Do we always want the "generator" to be the smaller
> generator, and the "period" the larger? Anyway, it would be
> nice to see the period.

Yes, it's a known bug that I'll tackle one day. This is a valid
generator, but not the simplest one. The same way that 3:1 and 8:3 are
generators for meantone. The problem is that the generator's chosen
before the temperament's optimized.

> Are these optimum generators?

Yes.

> >basis:
> >(0.25, 1.57192809489)
>
> Never heard of it.

Then you've learnt something!

> >mapping by period and generator:
> >[(4, 0), (0, 1), (3, 1), (5, 1)]
>
> I'm up to speed on this.
>
> >mapping by steps:
> >[(4, 0), (-1, 1), (2, 1), (4, 1)]
>
> ? Carried out how far?

This entry looks a bit odd for temperaments generated from unison vectors.
It's related to the problem above.

> >highest interval width: 1
>
> ?

max()-min() of the second column

> >complexity measure: 4 (8 for smallest MOS)
>
>From the map above isn't it 5?

No, it is 4.

> >highest error: 0.027608 (33.129 cents)
>
> Why not give rms as well as or instead of this?

Yes, there are a lot of things I could give and this is one of them. I'll
write an HTML formatting module sometime.

Graham

>>>basis:
>>>(0.25, 1.57192809489)
>>
>> Never heard of it.
>
>Then you've learnt something!

Unfortunately not.

>>>highest interval width: 1
>>
>> ?
>
>max()-min() of the second column

the 2nd column?

>>>complexity measure: 4 (8 for smallest MOS)
>>
>>From the map above isn't it 5?
>
>No, it is 4.

Then you're defining complexity differently here
than in your last message?

-Carl

--- In tuning-math@y..., Carl Lumma <carl@l...> wrote:
> >>>basis:
> >>>(0.25, 1.57192809489)
> >>
> >> Never heard of it.
> >
> >Then you've learnt something!
>
> Unfortunately not.

This is the [4,4,4,-2,5,-3] system which came in #10 when I was using the funky badness measure with steps^3. It's a Paul favorite, since it is associated to the octatonic scale of jazz and Stravinsky. We could call it igor, I suppose. :)

In-Reply-To: <200203060919.g269JMN15110@satyr.host4u.net>
Carl Lumma wrote:

> >>>highest interval width: 1
> >>
> >> ?
> >
> >max()-min() of the second column
>
> the 2nd column?

>From this matrix

[(4, 0), (0, 1), (3, 1), (5, 1)]

which should be oriented

[(4, 0),
(0, 1),
(3, 1),
(5, 1)]

the second column is the mapping by generator, and that's what you use for
the complexity.

> >>>complexity measure: 4 (8 for smallest MOS)
> >>
> >>From the map above isn't it 5?
> >
> >No, it is 4.
>
> Then you're defining complexity differently here
> than in your last message?

I may have forgotten you have to multiply by the number of periods to the
equivalence interval. But without that you wouldn't get 5. You must be
using the wrong column.

Graham

Very nicely made Graham. Do you plan to add the
minimax generators too? Why don't you give a few
more digits for the generators in cents, since you
have plenty for the basis.

How about any of you sending me scale files of the
best results, then I add them to the archive and
people can try them? It's also not yet clear to
me what Pajara is, that could be included too.

Manuel

>>>>>(0.25, 1.57192809489)
>>>>
>>>> Never heard of it.
>>>
>>>Then you've learnt something!
>>
>> Unfortunately not.
>
>This is the [4,4,4,-2,5,-3] system which came in #10 when I was using
>the funky badness measure with steps^3. It's a Paul favorite, since it
>is associated to the octatonic scale of jazz and Stravinsky. We could
>call it igor, I suppose. :)

I think Monz and Paul have been calling it octatonic.

I meant I don't know what basis is. Wasn't it also used in the
context of "MT reduced basis". Makes searching the archives difficult.

-Carl

--- In tuning-math@y..., Carl Lumma <carl@l...> wrote:

> I think Monz and Paul have been calling it octatonic.
>
> I meant I don't know what basis is. Wasn't it also used in the
> context of "MT reduced basis". Makes searching the archives difficult.

If you search for the wedgie you find a posting with the MT reduced
basis of <36/35, 50/49>.

In-Reply-To: <OF57BC8B23.674511F0-ONC1256B74.005DDEBC@office.novaterra.nl>
Manuel wrote:

> Very nicely made Graham. Do you plan to add the
> minimax generators too? Why don't you give a few
> more digits for the generators in cents, since you
> have plenty for the basis.

I can report the minimax, but I don't plan to sort by it because it'll
slow the search down. The cents values are formatted to what's likely to
be useful, whereas the basis is the standard stringification of the
sequence.

> How about any of you sending me scale files of the
> best results, then I add them to the archive and
> people can try them? It's also not yet clear to
> me what Pajara is, that could be included too.

I might get it to write the Scala files itself when I redo the formatting.
Which ones do you think the best are? Pajara's the same as Paultone and
Twintone. This should be 22 notes of the RMS optimum:

0.000
52.886
108.814
161.700
217.629
270.515
326.443
379.329
435.257
488.143
544.072
600.000
652.886
708.814
761.700
817.629
870.515
926.443
979.329
1035.257
1088.143
1144.072
1200.000

And the minimax:

0.000
56.178
109.363
165.542
218.726
274.905
328.089
384.268
437.452
493.631
546.815
600.000
656.178
709.363
765.542
818.726
874.905
928.089
984.268
1037.452
1093.631
1146.815
1200.000

Are there any plans to add this functionality to Scala? You should be
able to generate the scales easily enough from knowing the period and
generator.

Graham

Thanks, I've put them in the archive.
Graham wrote:
> Which ones do you think the best are?

I haven't taken a close look, I'll leave that to
you, Gene and Paul to decide.

>Are there any plans to add this functionality to Scala?

You mean generating these scales? That's possible now.
But if I get the files ready I don't need to worry about
a good file name, description, and number of generator
steps up and down. You always want to start the cycle on 1/1?
Or maybe a good convention is to have D somewhere in the
middle, if it's octave based.

Manuel

In-Reply-To: <OFB9F45FC8.B7945257-ONC1256B75.00573332@office.novaterra.nl>
Manuel wrote:

> Thanks, I've put them in the archive.

You mean the Pajaras?

> Graham wrote:
> > Which ones do you think the best are?
>
> I haven't taken a close look, I'll leave that to
> you, Gene and Paul to decide.

I presume you have some kind of miracles already. I have Scala files on
my website. They're linked to from
<http://x31eq.com/miracle/>. Currently in 72-equal, although
I'd prefer them with the 11:8-just generator of 116.755 cents.

I'd rather you include a template for the keyboard mapping, so that it can
be filled with any generator size. But I don't think that'll work, as the
mapping files aren't geared for open-ended tunings. Perhaps you could
make it a mode of 31, 41 and 72, but that still doesn't solve the general
problem.

Also 58 from multiple-29 should be there. I haven't tuned it up, so I'll
have to assume minimax is best. That's two lots of 29-equal 25 cents
apart.

> >Are there any plans to add this functionality to Scala?
>
> You mean generating these scales? That's possible now.

I was thinking of the searches and optimizations. Is the documentation
online? Ah yes, <http://www.xs4all.nl/~huygensf/scala/help.htm>. Well,
BISTEP and CALCULATE/LEASTSQUARE seem to do the optimization bit.

> But if I get the files ready I don't need to worry about
> a good file name, description, and number of generator
> steps up and down. You always want to start the cycle on 1/1?
> Or maybe a good convention is to have D somewhere in the
> middle, if it's octave based.

It doesn't matter where you start the cycle, or exactly what size
generator you choose. I'm counting up from the root by default. For
people who have Scala, simple instructions for generating the scales are
probably better than static files, so that they can play around with these
things. Although for people who don't have Scala, the lists of cents
might be useful.

I've counted 95 files in my copy of the archive including the word
'meantone'. Do you want that many for every temperament we come up with?

Graham

Graham wrote:
>You mean the Pajaras?

Yes.

>I presume you have some kind of miracles already.
>Currently in 72-equal, although
>I'd prefer them with the 11:8-just generator of 116.755 cents.

Yes, the 72-equal ones. I will add the just 11/8 ones.

>I'd rather you include a template for the keyboard mapping, so that it
can
>be filled with any generator size. But I don't think that'll work, as the
>mapping files aren't geared for open-ended tunings.

No, that's right.

>Also 58 from multiple-29 should be there.

Ok, will add.

>I was thinking of the searches and optimizations.

I didn't plan to add the searches. There are other things I'd like more
to add. The optimizations can be done, although I'm not sure whether
it's general enough to handle cases like 58 from multiple-29.

>For people who have Scala, simple instructions for generating the scales
>are probably better than static files, so that they can play around with
>these things.

Ok, I'll see about adding that.

>Although for people who don't have Scala, the lists of cents
>might be useful.

Yes, I think your top list should at least be available in files.
Preferably with file names near each other in lexical order.

>I've counted 95 files in my copy of the archive including the word
>'meantone'. Do you want that many for every temperament we come up with?

No thanks :-)

Manuel

Graham,

When I enter these numbers in the linear temperament finder
13
28
12.0
25
10
0.5

the first one is:

13-limit
31/75, 495.6 cent generator
basis:
(1.0, 0.41300690788)
mapping by period and generator:
[(1, 0), (2, -1), (11, -21), (9, -15), (8, -11), (7, -8)]
mapping by steps:
[(46, 29), (73, 46), (107, 67), (129, 81), (159, 100), (170, 107)]
highest interval width: 21
complexity measure: 21 (29 for smallest MOS)
highest error: 0.009422 (11.306 cents)

But when I do an RMS approximation I'm able to get a lower
highest error of 10.868 cents (for 13/9), with a generator of 495.708356
cents.
Did you exclude some consonant intervals?
With many consonant intervals to approximate, minimax makes more sense
than RMS I think.

(29 for smallest MOS)

This means 29 tones in the smallest MOS, doesn't it?

Manuel

In-Reply-To: <OFC5246248.AC822B6F-ONC1256B7B.00535BCC@office.novaterra.nl>
Manuel wrote:

> But when I do an RMS approximation I'm able to get a lower
> highest error of 10.868 cents (for 13/9), with a generator of
> 495.708356 cents.
> Did you exclude some consonant intervals?

No, I only exclude intervals that don't depend on the generator. I'm not
sure if that's right or not, but it doesn't matter here because the period
is an octave.

> With many consonant intervals to approximate, minimax makes more sense
> than RMS I think.

Yes, but the RMS optimum is more efficient to calculate.

> (29 for smallest MOS)
>
> This means 29 tones in the smallest MOS, doesn't it?

Yes, the smallest one that contains a complete 13-limit otonality.

Graham

>No, I only exclude intervals that don't depend on the generator.

O! So you didn't include 7/5 in the given example? Wouldn't
you, generally speaking, get better results if you did?

>I'm not sure if that's right or not, but it doesn't matter here
>because the period is an octave.

I don't understand why it doesn't matter?

Manuel

In-Reply-To: <OFBF3E9787.74F450EC-ONC1256B7C.004EAB50@office.novaterra.nl>
Manuel wrote:

> O! So you didn't include 7/5 in the given example? Wouldn't
> you, generally speaking, get better results if you did?

What? No, 7:5 is 20 generator steps. It would be excluded in Twintone,
where it's always a half-octave. On thinking about it more, this doesn't
affect the optimum because it's only removing a constant from the
RMS-by-generator-size function that's being minimized. So I was right to
exclude such intervals.

I don't know why we're getting different results.

> >I'm not sure if that's right or not, but it doesn't matter here
> >because the period is an octave.
>
> I don't understand why it doesn't matter?

An interval would have to be equal to a unison to be excluded, which is
much less likely than being equal to some division of an octave.

Graham

Graham wrote:
>I don't know why we're getting different results.

Found the problem, I was using a wrong mapping
somewhere. I confirmed your result using all
intervals.

Anyway, the minimax solution is 495.662963 cents.
Highest error 10.595435 cents.

Manuel

In-Reply-To: <OF5C0B1B93.CD1B3E17-ONC1256B7C.005B70BE@office.novaterra.nl>
> Anyway, the minimax solution is 495.662963 cents.
> Highest error 10.595435 cents.

Yes, that's what I get.