back to list

12-tones of diminished

🔗Carl Lumma <ekin@lumma.org>

7/14/2003 2:28:11 AM

Graham, and all;

So if one wants 12-tones of diminished, and one isn't planning
on enforcing 300-cent octaves, it makes sense to take 4 periods
of 3 tones each, no? And what is the optimal generator?

According to Paul's Incredibly, Very Awesome database, 94 cents
in the 5-limit, giving mapping [[4,0] [6,1] [9,1]] and 11 cents
RMS error. That appears to agree with the 'linear temp from uvs'
script for 648/625, and with the 'from ets' script in the
5-limit with either 8,12 or 16,28.

Now, how to extend this to the 7-limit? The 'from ets' script
gives...

16,28: 86-cent generator and [... [11, 1]] mapping,
$0.33 max error

8,12: 106-cent generator and [... [12, -2]] mapping,
$0.20 max error

8,28: 133-cent generator and [... [13, -4]] mapping,
$0.16 max error

...how do I tell what new commas are involved here? Too bad the
script doesn't give RMS error also.

-Carl

🔗Graham Breed <graham@microtonal.co.uk>

7/14/2003 12:16:56 PM

Carl Lumma wrote:

> So if one wants 12-tones of diminished, and one isn't planning
> on enforcing 300-cent octaves, it makes sense to take 4 periods
> of 3 tones each, no? And what is the optimal generator?

300 cent octaves don't make sense anyway, because an octave is a long way from 300 cents. 4 periods of 2 tones each will do you (this is the octatonic scale, right?

> According to Paul's Incredibly, Very Awesome database, 94 cents
> in the 5-limit, giving mapping [[4,0] [6,1] [9,1]] and 11 cents
> RMS error. That appears to agree with the 'linear temp from uvs'
> script for 648/625, and with the 'from ets' script in the
> 5-limit with either 8,12 or 16,28.

Yes, about 94 cents.

> Now, how to extend this to the 7-limit? The 'from ets' script
> gives...
> > 16,28: 86-cent generator and [... [11, 1]] mapping,
> $0.33 max error
> > 8,12: 106-cent generator and [... [12, -2]] mapping,
> $0.20 max error
> > 8,28: 133-cent generator and [... [13, -4]] mapping,
> $0.16 max error
> > ...how do I tell what new commas are involved here? Too bad the
> script doesn't give RMS error also.

The Python library can do it, which you have always been able to download. It's giving different mappings for ET pairs, probably because I switched from nearest-prime to optimal mappings. Anyway, here are the results, and as it's getting hot and sticky in here I'll post them verbatim rather than interpret them:

>>> temper.Temperament(16,28,temper.limit7)

3/11, 83.3 cent generator

basis:
(0.25, 0.069401894665888031)

mapping by period and generator:
[(4, 0), (6, 1), (9, 1), (12, -3)]

mapping by steps:
[(28, 16), (44, 25), (65, 37), (78, 45)]

highest interval width: 4
complexity measure: 16 (28 for smallest MOS)
highest error: 0.015561 (18.673 cents)
unique
>>> temper.Temperament(12,8,temper.limit7)

2/5, 86.3 cent generator

basis:
(0.25, 0.071928094887362182)

mapping by period and generator:
[(4, 0), (6, 1), (9, 1), (11, 1)]

mapping by steps:
[(12, 8), (19, 13), (28, 19), (34, 23)]

highest interval width: 1
complexity measure: 4 (8 for smallest MOS)
highest error: 0.027608 (33.129 cents)
>>> temper.Temperament(8,28,temper.limit7)

4/9, 133.8 cent generator

basis:
(0.25, 0.11147098441152084)

mapping by period and generator:
[(4, 0), (5, 3), (8, 3), (9, 5)]

mapping by steps:
[(28, 8), (44, 13), (65, 19), (78, 23)]

highest interval width: 5
complexity measure: 20 (28 for smallest MOS)
highest error: 0.013034 (15.641 cents)
unique
>>> def rmsError(m, n):
... lt = temper.Temperament(m, n, temper.limit7)
... lt.optimizeRMS()
... return lt.getRMSError()
...
>>> rmsError(16, 28)*1200
13.982572846883539
>>> rmsError(8, 28)*1200
11.750812084722009
>>> rmsError(8, 12)*1200
20.963524907544105
>>> map(temper.getRatio, temper.Temperament(8,28,temper.limit7).getUnisonVectors())
[(648, 625), (686, 675)]
>>> map(temper.getRatio, temper.Temperament(16,28,temper.limit7).getUnisonVectors())
[(525, 512), (648, 625)]
>>> map(temper.getRatio, temper.Temperament(8,12,temper.limit7).getUnisonVectors())
[(36, 35), (50, 49)]

Graham

🔗Carl Lumma <ekin@lumma.org>

7/14/2003 12:59:56 PM

>> So if one wants 12-tones of diminished, and one isn't planning
>> on enforcing 300-cent octaves, it makes sense to take 4 periods
>> of 3 tones each, no? And what is the optimal generator?
>
>300 cent octaves don't make sense anyway, because an octave is a
>long way from 300 cents.

Exactly.

>4 periods of 2 tones each will do you (this is the
>octatonic scale, right?

I want 12 tones, I think I need 3 tones / period.

>> Now, how to extend this to the 7-limit? The 'from ets' script
>> gives...
>>
>> 16,28: 86-cent generator and [... [11, 1]] mapping,
>> $0.33 max error
>>
>> 8,12: 106-cent generator and [... [12, -2]] mapping,
>> $0.20 max error
>>
>> 8,28: 133-cent generator and [... [13, -4]] mapping,
>> $0.16 max error
>>
>> ...how do I tell what new commas are involved here? Too bad the
>> script doesn't give RMS error also.
>
>The Python library can do it, which you have always been able to
>download.

url?

>It's giving different mappings for ET pairs, probably because I
>switched from nearest-prime to optimal mappings.

What's nearest-prime? By optimal, do you mean least badness?

> >>> rmsError(16, 28)*1200
>13.982572846883539
> >>> rmsError(8, 28)*1200
>11.750812084722009
> >>> rmsError(8, 12)*1200
>20.963524907544105

So the best mapping is out of the range of a 12-tone tuning.

But the 2nd-best mapping (the worst according to max error)
is in range, giving...

!
12 tones of 7-limit diminished.
12
!
86.
172.
300.
386.
472.
600.
686.
772.
900.
986.
1072.
2/1
!

...with unforch. some nasty fifths. The 106-cent mapping gives...

!
12 tones of 7-limit diminished.
12
!
106.
212.
300.
406.
512.
600.
706.
812.
900.
1006.
1112.
2/1
!

...and looks like the best bet.

> >>> map(temper.getRatio,
>temper.Temperament(8,28,temper.limit7).getUnisonVectors())
>[(648, 625), (686, 675)]
> >>> map(temper.getRatio,
>temper.Temperament(16,28,temper.limit7).getUnisonVectors())
>[(525, 512), (648, 625)]
> >>> map(temper.getRatio,
>temper.Temperament(8,12,temper.limit7).getUnisonVectors())
>[(36, 35), (50, 49)]

Cool. Tx.

-Carl

🔗Graham Breed <graham@microtonal.co.uk>

7/14/2003 5:44:04 PM

Carl Lumma wrote:

> url?

http://x31eq.com/temper.html

> What's nearest-prime? By optimal, do you mean least badness?

Nearest-prime takes the nearest approximation to the logarithm of each prime number. The optimial mapping is that with the smallest worst error, which is one badness measure for equal temperaments.

> So the best mapping is out of the range of a 12-tone tuning.
> > But the 2nd-best mapping (the worst according to max error)
> is in range, giving...

No, it's the worst tuned one by either measure.

Graham

🔗Carl Lumma <ekin@lumma.org>

7/14/2003 5:52:06 PM

>http://x31eq.com/temper.html

Ah! (I've never seen that before)

>The optimial mapping is that with the smallest worst
>error, which is one badness measure for equal temperaments.

I must be missing how complexity is part of it (making it a
badness measure).

>> What's nearest-prime? By optimal, do you mean least badness?
>
>Nearest-prime takes the nearest approximation to the logarithm
>of each prime number.

Sounds like another error-only measure. I'm surprised you
get finite results without some sort of badness cutoff.

>> So the best mapping is out of the range of a 12-tone tuning.
>>
>> But the 2nd-best mapping (the worst according to max error)
>> is in range, giving...
>
>No, it's the worst tuned one by either measure.

According to your results, 8,12 has higher RMS error than
16,28 (the 86-cent mapping in question)...

> >>> rmsError(16, 28)*1200
>13.982572846883539
> >>> rmsError(8, 12)*1200
>20.963524907544105

-Carl

🔗Graham Breed <graham@microtonal.co.uk>

7/15/2003 2:57:50 AM

Carl Lumma wrote:

>>The optimial mapping is that with the smallest worst >>error, which is one badness measure for equal temperaments.
> > I must be missing how complexity is part of it (making it a
> badness measure).

It's only being used to compare equal temperaments with the same number of notes, so the only thing that changes is the error.

>>Nearest-prime takes the nearest approximation to the logarithm
>>of each prime number.
> > Sounds like another error-only measure. I'm surprised you
> get finite results without some sort of badness cutoff.

I get one finite result for one number of notes to the octave. For a list of equal temperaments, I start at 1 note to the octave and count up until I've got all I need. The error's calculated in terms of scale steps.

> According to your results, 8,12 has higher RMS error than
> 16,28 (the 86-cent mapping in question)...

And 8,12 has a higher maximum error as well and is the 86-cent mapping. This goes back to what I said about the results I get being different to what the website gives, because it uses a different version of the library.

Graham

🔗Carl Lumma <ekin@lumma.org>

7/15/2003 12:03:10 PM

>>>The optimial mapping is that with the smallest worst
>>>error, which is one badness measure for equal temperaments.
>>
>> I must be missing how complexity is part of it (making it a
>> badness measure).
>
>It's only being used to compare equal temperaments with the same
>number of notes, so the only thing that changes is the error.

But the ets aren't what we care about. Changing the mapping *does*
change the number of notes needed to express the target chord
(in this case 4:5:6:7, and with linear temperaments, you get the
utonal version for free), which is my definition of complexity.

>>>Nearest-prime takes the nearest approximation to the logarithm
>>>of each prime number.
>>
>> Sounds like another error-only measure. I'm surprised you
>> get finite results without some sort of badness cutoff.
>
>I get one finite result for one number of notes to the octave. For a
>list of equal temperaments, I start at 1 note to the octave and count up
>until I've got all I need. The error's calculated in terms of scale
>steps.

Ah.

>> According to your results, 8,12 has higher RMS error than
>> 16,28 (the 86-cent mapping in question)...
>
>And 8,12 has a higher maximum error as well and is the 86-cent mapping.

8,12 is the 86-cent mapping?

>This goes back to what I said about the results I get being different
>to what the website gives, because it uses a different version of the
>library.

SOB.

-Carl

🔗Gene Ward Smith <gwsmith@svpal.org>

7/15/2003 12:24:07 PM

--- In tuning-math@yahoogroups.com, Carl Lumma <ekin@l...> wrote:
> Graham, and all;

> So if one wants 12-tones of diminished, and one isn't planning
> on enforcing 300-cent octaves, it makes sense to take 4 periods
> of 3 tones each, no? And what is the optimal generator?

(1) You could take 12 tones of diminished and not enfore a uniform
size of generator as well, and optimize for that.

(2) Are you asking about a non-octave version of diminished?

🔗Carl Lumma <ekin@lumma.org>

7/15/2003 12:28:20 PM

>> So if one wants 12-tones of diminished, and one isn't planning
>> on enforcing 300-cent octaves, it makes sense to take 4 periods
>> of 3 tones each, no? And what is the optimal generator?
>
>(1) You could take 12 tones of diminished and not enforce a
>uniform size of generator as well, and optimize for that.

Yeah, I'm not particularly interested in that, but I'm willing
to view examples.

>(2) Are you asking about a non-octave version of diminished?

Diminished *is* non-octave.

-Carl

🔗Paul Erlich <perlich@aya.yale.edu>

7/15/2003 1:58:19 PM

--- In tuning-math@yahoogroups.com, Carl Lumma <ekin@l...> wrote:

> >(2) Are you asking about a non-octave version of diminished?
>
> Diminished *is* non-octave.

absolutely false!!

🔗Carl Lumma <ekin@lumma.org>

7/15/2003 4:37:05 PM

>> >(2) Are you asking about a non-octave version of diminished?
>>
>> Diminished *is* non-octave.
>
>absolutely false!!

That depends on how you read that sentence.

-Carl