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.