Tuning-Math messages 75 - 99

This is an Opt In Archive . We would like to hear from you if you want your posts included. For the contact address see About this archive. All posts are copyright (c).

Contents Hide Contents S 1

Previous Next

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950

50 - 75 -



top of page bottom of page down


Message: 75

Date: Wed, 30 May 2001 13:48 +0

Subject: Re: Temperament program issues

From: graham@m...

In-Reply-To: <9f166e+2vcv@e...>
Paul Erlich wrote:

> I looked at the 7-limit results and they're fascinating. While I 
> don't see paultone, I see a 5/11 oct. generator with a half-octave 
> interval of repetition. So 22-tET should work very well for it. Can 
> you talk about the structure of this scale at all?

There was a bug in the program when I generated the exp files.  The 
routine for optimizing the minimax was ignoring octave-divisions, and this 
got reflected in the scoring.  I don't think it affected the top of any of 
the lists, but that's how this scale got in.

5/11, 274.511 cent generator

basis:
(0.5, 0.22875937481971093)

mapping by period and generator:
([2, 0], ([5, 6, 7], [-4, -3, -3]))

mapping by steps:
([18, 4], [(29, 6), (42, 9), (51, 11)])

highest interval width: 4
complexity measure: 8  (10 for smallest MOS)
highest error: 0.014573  (17.488 cents)

The period is 7:5, like for diaschismic.  So the max error is for that 
7:5.  You'll probably find it has good approximations to the rest of the 
7-limit.  It's also consistent with 26=, so can be generated from 22 and 
26 and will have been in previous charts as this.  Here's how you prove 
that:

>>> import temper
>>> tuning = temper.Temperament(22,26,temper.primes[:3])
>>> tuning.mapping
([5, 6, 7], [-4, -3, -3])


Calling it 18r+4s, we have

3:2 => 11r+2s
5:4 => 6r+s
7:4 => 15r+3s
7:8 => 3r+s

 r r r r s r r r r r s r r r r s r r r r r s
1         7 6 5       7   3         7
-         - - -       -   -         -
1         6 5 4       5   2         4

I think that's right.  r=1/22 or 1/26, s=1/22 or 2/26.


                  Graham


top of page bottom of page up down


Message: 77

Date: Wed, 30 May 2001 06:11:04

Subject: Pseudo-Erlich-symmetric-decatonic in Blackjack

From: Dave Keenan

Here's the closest I can find to an Erlich-symmetric-decatonic in 
Blackjack, expressed as degrees of 72-EDO

0  7 14 23 30 37 42 49 58 65(72)
 7  7  9  7  7  5  7  9  7  7

On a chain of 20 miracle generators it looks like
 2  9 16 23 30 37 44 51 58 65  0  7 14 21 28 35 42 49 56 63 70
          +--+--+--------+--+--+--+--+-----------+--+
          5--------------7-----1-----------------3
            1/3---------------1/1---1/7------------1/5
          7-----1-----------------3-----------------9

So, you can see that it occurs at 7 positions in Blackjack (two of 
which are a perfect fifth apart), but it only has 2 otonal and 2 
utonal 7-limit tetrads and one otonal 1-3-7-9 tetrad.

So Paul, can you tell us what your adaptive decatonic is, in 72-EDO? 
And what it looks like on a Miracle chain?


top of page bottom of page up down


Message: 80

Date: Wed, 30 May 2001 21:37:20

Subject: Fwd: Re: Musical practice and discourse about musicc

From: Paul Erlich

This is what I meant:

] = 1/4 tone up
> = 1/6 tone up
^ = 1/12 tone up
v = 1/12 tone down
< = 1/6 tone down
[ = 1/4 tone down

The "two decatonic scales a twelfth-tone apart in 72-tET", for the 
dynamic symmetrical case, would be (with the number of tetrads each 
pitch is involved in in parentheses):

C   (3)     C^  (1)
C#  (2)     C#^ (1)
Eb< (1)     Ebv (2)
E<  (1)     Ev  (3)
Fv  (1)     F   (1)
F#  (3)     F#^ (1)
G   (2)     G^  (1)
A<  (1)     Av  (2)
Bb< (1)     Bbv (3)
Bv  (1)     B   (1)


top of page bottom of page up down


Message: 82

Date: Wed, 30 May 2001 22:32:49

Subject: Re: Temperament program issues

From: Paul Erlich

--- In tuning-math@y..., "Dave Keenan" <D.KEENAN@U...> wrote:
> --- In tuning-math@y..., graham@m... wrote:
> > In-Reply-To: <3.0.6.32.20010530034550.00a72d90@u...>
> > Dave Keenan wrote:
> > 
> > > Here's how to calculate the notes per octave of the smallest 
MOS 
> > > containing
> > > a complete otonality. In pseudo Pascal.
> > 
> > I've updated that.  It's showing 22 as a schismic MOS, which is 
> wrong.
> 
> I disagree. I think it's correct. With a period of an octave won't 
any 
> generator in the range 489 to 492 cents generate a proper MOS? 
490.9 c 
> will give you 22-EDO itself which is certainly a proper MOS (albeit 
a 
> boring one melodically). Although 22-EDO has a half-ocatve it is 
still 
> a single chain of fifths within the octave.

But it's not _schismic_!


top of page bottom of page up down


Message: 83

Date: Wed, 30 May 2001 22:38:08

Subject: Re: Temperament program issues

From: Dave Keenan

--- In tuning-math@y..., "Paul Erlich" <paul@s...> wrote:
> --- In tuning-math@y..., "Dave Keenan" <D.KEENAN@U...> wrote:
> > --- In tuning-math@y..., graham@m... wrote:
> > > In-Reply-To: <3.0.6.32.20010530034550.00a72d90@u...>
> > > Dave Keenan wrote:
> > > 
> > > > Here's how to calculate the notes per octave of the smallest 
> MOS 
> > > > containing
> > > > a complete otonality. In pseudo Pascal.
> > > 
> > > I've updated that.  It's showing 22 as a schismic MOS, which is 
> > wrong.
> > 
> > I disagree. I think it's correct. With a period of an octave won't 
> any 
> > generator in the range 489 to 492 cents generate a proper MOS? 
> 490.9 c 
> > will give you 22-EDO itself which is certainly a proper MOS 
(albeit 
> a 
> > boring one melodically). Although 22-EDO has a half-ocatve it is 
> still 
> > a single chain of fifths within the octave.
> 
> But it's not _schismic_!

Ok. So what are the generator and period we are talking about here. 
The algorithm doesn't take "schismic" as input.


top of page bottom of page up down


Message: 84

Date: Wed, 30 May 2001 23:31:44

Subject: Re: Temperament program issues

From: Dave Keenan

--- In tuning-math@y..., "Dave Keenan" <D.KEENAN@U...> wrote:
Ok. Pardon my ignorance. I looked up Schismic on Graham's website. 
It's what I call simply Pythagorean. A 498 cent generator with an 
octave period.

My Excel implementation of the algorithm gives
Proper MOS sequence:
1
2
5
12
41
53

So I agree. 22 shouldn't be there.

Either I've given the algorithm wrongly in Pseudo-Pascal or Graham's 
implemented it wrongly. Probably the former. I'll have a look when I 
get the time.

-- Dave Keenan


top of page bottom of page up down


Message: 85

Date: Thu, 31 May 2001 00:29:41

Subject: Re: Temperament program issues

From: David C Keenan

I goofed. It should have been (changes shown with *):

Given period p and generator g (both in octaves) and
w as the width of the complete otonality (in generators).

r := g/p
i := INT(r)          *
m_prev := 0
m := 1

WHILE m <= w DO
  r := 1/(r-i)       *
  i := INT(r)        *
  temp := m
  m := m*i + m_prev
  m_prev := temp

return m/p

Here's a trace for a schismic generator of 498 cents.

g = 0.415
p = 1
r = 0.415
i = 0
m_prev = 0
m = 1
iteration 1 
r = 2.410
i := 2
temp = 1
m = 2
m_prev = 1
iteration 2
r = 2.441
i = 2
temp = 2
m = 5
m_prev = 2
iteration 3
r = 2.267
i = 2
temp = 5
m = 12
m_prev = 5
iteration 4
r = 3.750
i = 3
temp = 12
m = 41
m_prev = 12

etc.

Regards,
-- Dave Keenan
Brisbane, Australia
Dave Keenan's Home Page *


top of page bottom of page up down


Message: 86

Date: Thu, 31 May 2001 10:35 +0

Subject: Re: Temperament program issues

From: graham@m...

In-Reply-To: <3.0.6.32.20010531002941.00a80540@u...>
Dave Keenan wrote:

> Given period p and generator g (both in octaves) and
> w as the width of the complete otonality (in generators).
> 
> r := g/p
> i := INT(r)          *
> m_prev := 0
> m := 1
> 
> WHILE m <= w DO
>   r := 1/(r-i)       *
>   i := INT(r)        *
>   temp := m
>   m := m*i + m_prev
>   m_prev := temp
> 
> return m/p

Right, here's my method with a bit of debugging code:

  def getSmallestContainingMOS(self, consonances=None):
    consonances = consonances or self.consonances

    width = self.getWidestInterval(consonances)[0]

    print "generator=%s"%self.basis[1]
    print "period=%s"%self.basis[0]
    ratio = self.basis[1]/self.basis[0]
    i = int(ratio)
    print str(locals())

    mPrev = 0
    m = 1
    while m <= width:
      ratio = 1/(ratio-i)
      i = int(ratio)
      mPrev, m = m, m*i + mPrev
      print str(locals())

    return m*self.octaveDivision

So that should be the same

> Here's a trace for a schismic generator of 498 cents.
> 
> g = 0.415
> p = 1
> r = 0.415
> i = 0
> m_prev = 0
> m = 1
> iteration 1 
> r = 2.410
> i := 2
> temp = 1
> m = 2
> m_prev = 1
> iteration 2
> r = 2.441
> i = 2
> temp = 2
> m = 5
> m_prev = 2
> iteration 3
> r = 2.267
> i = 2
> temp = 5
> m = 12
> m_prev = 5
> iteration 4
> r = 3.750
> i = 3
> temp = 12
> m = 41
> m_prev = 12

So, for this temperament it gives, with cleaned up output:

>>> reload(temper)
<module 'temper' from 'temper.py'>
>>> tuning = temper.Temperament(12,29,temper.primes[:2])
>>> tuning.setConsonanceLimit(temper.limit5)
>>> tuning.optimizeMinimax()
>>> tuning.getSmallestContainingMOS()
generator=0.415218399352
period=1.0
{'ratio': 0.4152183993518006,
   'consonances': [(0, 0), (1, 0), (0, 1), (-1, 1)],
   'width': 9,   'i': 0}
{'m': 2, 'i': 2, 'mPrev': 1,
 'ratio': 2.4083711164079067,
 'width': 9}
{'m': 5,
 'i': 2,
 'mPrev': 2,
 'ratio': 2.448753008773366,
 'width': 9}
{'m': 12,
 'i': 2,
 'mPrev': 5,
 'ratio': 2.2283973153370669
 'width': 9}
12

I think that's equivalent.  Anyway, the answer's 12, which is more like 
it.  So I'll update the main stuff to show this.


               Graham


top of page bottom of page up down


Message: 87

Date: Thu, 31 May 2001 09:20:55

Subject: Re: Temperament program issues

From: David C Keenan

--- In tuning-math@y..., graham@m... wrote:
> Right, here's my method with a bit of debugging code:
...
> I think that's equivalent.

Yes. Looks good.

> Anyway, the answer's 12, which is more 
> like it.  So I'll update the main stuff to show this.

Note that the algorithm I gave does not necessarily give the smallest
containing MOS, but it gives the smallest containing strictly-proper-MOS.
i.e. It only calculates the denominators of the _convergents_ of the ratio,
not the _semi-convergents_ which correspond to improper MOS.

See 404 Not Found * Search for http://depts.washington.edu/pnm/clampitt.pdf in Wayback Machine

Actually, I have no proof of this correspondence, only the lack of a
counterexample.

Here's the algorithm modified to return the smallest containing MOS, and
tell you whether it is strictly proper.

  def getSmallestContainingMOS(self, consonances=None):
    consonances = consonances or self.consonances

    width = self.getWidestInterval(consonances)[0]

    ratio = self.basis[1]/self.basis[0]
    i = int(ratio)
    mPrev, m = 0, 1
    n = i

    while m <= width:
      ratio = 1/(ratio-i)
      i = int(ratio)
      mPrev, m = m, mPrev + m
      n = 1
      while (n < i) & (m <= width):
        m = m + mPrev
        n = n+1

    strictlyProper = (n == i)

    return m*self.octaveDivision, strictlyProper

Alternatively, you might prefer to have it return both the smallest
containing MOS and the smallest strictly-proper containing MOS.

  def getSmallestContainingMOS(self, consonances=None):
    consonances = consonances or self.consonances

    width = self.getWidestInterval(consonances)[0]

    ratio = self.basis[1]/self.basis[0]
    i = int(ratio)
    mPrev, m = 0, 1
    smallest = 1
    n = i

    while m <= width:
      ratio = 1/(ratio-i)
      i = int(ratio)
      mPrev, m = m, mPrev + m
      if (m > width) & (smallest == 1):
        smallest = m
      n = 1

      while (n < i):
        m = m + mPrev
        if (m > width) & (smallest == 1):
          smallest = m
        n = n+1

    return smallest*self.octaveDivision, m*self.octaveDivision

You're gonna have to correct my syntax for sure.

I think the following is equivalent.

  def getSmallestContainingMOS(self, consonances=None):
    consonances = consonances or self.consonances

    width = self.getWidestInterval(consonances)[0]

    ratio = self.basis[1]/self.basis[0]
    i = int(ratio)
    mPrev, m = 0, 1
    smallest = 1
    n = i

    while m <= width:
      ratio = 1/(ratio-i)
      i = int(ratio)
      mPrev, m = m, mPrev
      n = 0

      repeat:
        m = m + mPrev
        if (m > width) & (smallest == 1):
          smallest = m
        n = n+1
      until n >= i

    return smallest*self.octaveDivision, m*self.octaveDivision

Regards,
-- Dave Keenan
Brisbane, Australia
Dave Keenan's Home Page *


top of page bottom of page up down


Message: 88

Date: Thu, 31 May 2001 19:00 +0

Subject: Re: Temperament program issues

From: graham@m...

In-Reply-To: <3.0.6.32.20010531092055.00a85990@u...>
Dave Keenan wrote:

> Note that the algorithm I gave does not necessarily give the smallest
> containing MOS, but it gives the smallest containing 
> strictly-proper-MOS.
> i.e. It only calculates the denominators of the _convergents_ of the 
> ratio,
> not the _semi-convergents_ which correspond to improper MOS.

We don't want to reject Blackjack as an MOS, do we?

> See 404 Not Found * Search for http://depts.washington.edu/pnm/clampitt.pdf in Wayback Machine
> 
> Actually, I have no proof of this correspondence, only the lack of a
> counterexample.

It looks like it works.

> You're gonna have to correct my syntax for sure.

Both examples run.  The only quibbles are:

It'd be better to use and than &.

There are no brackets round the condition of the first while loop, so they 
aren't needed for the other one either.

> I think the following is equivalent.

...

>       repeat:
>         m = m + mPrev
>         if (m > width) & (smallest == 1):
>           smallest = m
>         n = n+1
>       until n >= i
> 
>     return smallest*self.octaveDivision, m*self.octaveDivision

Only the repeat...until had to be converted for this, and it's the one I 
left active after uploading.

Although it gives good, quick data, I don't think we should be returning 
two results.  It'll cause confusion later on.  The best thing would be to 
have a condition on input to do the check or not.  Hopefully, this would 
avoid duplication of code.

Does

    while m <= width:
      ratio = 1/(ratio-i)
      i = int(ratio)

      if mustBeStrictlyProper:
        mPrev, m = m, m*i + mPrev

      else:
        mPrev, m = m, mPrev      
        n = 0

        while 1:
          m = m + mPrev
          if m > width and smallest == 1:
            smallest = m
          n = n+1
          if n >= i: break

look right?

In fact, couldn't that inner loop be

        for n in range(i):
          m = m + mPrev
          if m > width and smallest == 1:
            smallest = m

looping n from 0 to i?  There also seems to be a redundant n=i in there.  
Ah, wouldn't have worked before because you were testing n at the end.

Right I think this is the thing:


  def getSmallestContainingMOS(
        self, consonances=None, mustBeStrictlyProper=0):
    """Dave Keenan's Algorithm"""

    consonances = consonances or self.consonances
    width = self.getWidestInterval(consonances)[0]

    ratio = self.basis[1]/self.basis[0]
    i = int(ratio)

    mPrev, m = 0, 1
    while m <= width:
      ratio = 1/(ratio-i)
      i = int(ratio)

      if mustBeStrictlyProper:
        mPrev, m = m, m*i + mPrev

      else:
        mPrev, m = m, mPrev      

        for n in range(i):
          m = m + mPrev
          if m > width:
            return m*self.octaveDivision ###

    return m*self.octaveDivision

But I haven't uploaded it because you get more information in the txt 
files the other way.


                           Graham


top of page bottom of page up down


Message: 89

Date: Thu, 31 May 2001 18:02:15

Subject: blackjack group

From: carl@l...

Looks like I'm the 21st member of this group!

I have to say, though, that I don't plan to follow this list
closely (I have many other fish to fry right now).  I hope
you will all understand.  I am subscribed with the "no e-mail"
option.  I _will_ drop in on the web occasionally, and see
what's going on!

I am similarly subscribed to the harmonic entropy list, and
to the original tuning list.  Does anybody know what happened
to Practical Microtonality?

It seems Yahoo's list listings are not in sync with their
list existings.  This list isn't listed, but Practical
Microtonality is, but if you follow the links to PM you get
a 'list doesn't exist' error.

What else...  Monz, you were asking about Norman Henry?  What
would you like to know?

-Carl


top of page bottom of page up down


Message: 90

Date: Fri, 01 Jun 2001 02:06:53

Subject: Re: Temperament program issues

From: Dave Keenan

--- In tuning-math@y..., graham@m... wrote:
> In-Reply-To: <3.0.6.32.20010531092055.00a85990@u...>
> Dave Keenan wrote:
> 
> > Note that the algorithm I gave does not necessarily give the 
smallest
> > containing MOS, but it gives the smallest containing 
> > strictly-proper-MOS.
> > i.e. It only calculates the denominators of the _convergents_ of 
the 
> > ratio,
> > not the _semi-convergents_ which correspond to improper MOS.
> 
> We don't want to reject Blackjack as an MOS, do we?

There's no question that Blackjack is a MOS. But it doesn't contain a 
hexad so its a moot point and you'll get 31 for the 11-limit MOS 
whether you insist it be proper or not. But of course Blackjack does 
contain complete otonalities at odd-limits lower than 11. Really we 
want to see both sets of generator rankings (those where we insist it 
be proper and those where we don't).

Note that because we are dealing with generators which are irrational 
fractions of an octave, we don't have to worry about the distinction 
between proper and strictly-proper. No generator will ever be 
precisely on the borderline, i.e. merely-proper. However you should be 
aware that this algorithm, if fed rational generators, may include the 
merely-proper with either the improper, or the strictly-proper, 
depending on floating point precision.

Did you spot the unintentional almost-pun above. "_dealing_ with 
generators" in Blackjack and Canasta. :-)

> >       repeat:
> >         m = m + mPrev
> >         if (m > width) & (smallest == 1):
> >           smallest = m
> >         n = n+1
> >       until n >= i
> > 
> >     return smallest*self.octaveDivision, m*self.octaveDivision
> 
> Only the repeat...until had to be converted for this, and it's the 
one I 
> left active after uploading.
> 
> Although it gives good, quick data, I don't think we should be 
returning 
> two results.  It'll cause confusion later on.  The best thing would 
be to 
> have a condition on input to do the check or not.  Hopefully, this 
would 
> avoid duplication of code.

Yes. I agree with this approach.

> Right I think this is the thing:
> 
> 
>   def getSmallestContainingMOS(
>         self, consonances=None, mustBeStrictlyProper=0):
>     """Dave Keenan's Algorithm"""
> 
>     consonances = consonances or self.consonances
>     width = self.getWidestInterval(consonances)[0]
> 
>     ratio = self.basis[1]/self.basis[0]
>     i = int(ratio)
> 
>     mPrev, m = 0, 1
>     while m <= width:
>       ratio = 1/(ratio-i)
>       i = int(ratio)
> 
>       if mustBeStrictlyProper:
>         mPrev, m = m, m*i + mPrev
> 
>       else:
>         mPrev, m = m, mPrev      
> 
>         for n in range(i):
>           m = m + mPrev
>           if m > width:
>             return m*self.octaveDivision ###
> 
>     return m*self.octaveDivision

Yes. That looks to be correct.

So where are the results of the latest runs and what is your ranking 
based on now?

Is the current Figure of Demerit (FoD) the size of smallest MOS (of 
any propriety) containing a complete otonality, divided by the 
probability of misrecognition of the MA error with a standard error of 
10 cents?

Could you give the values of the parameters at the top of the output 
file (MA versus RMS, MOS versus any, strictly proper MOS versus any 
MOS, standard error). And could you give the actual FoD for each 
generator so we can see _how_much_ better some generator might be than 
its runner-ups?

I'm sure you can knock up a simple numerical min RMS finder to give 
you the RMS optimium generator within say 0.01 c. Take an initial 
estimate of the generator, calculate the RMS errors for generators 
0.01 cents on either side. Figure out which direction reduces the RMS 
error. Head downhill in increments of 0.01 cents until the error 
increases again. Return the generator and RMS error before last.

Regards,
-- Dave Keenan


top of page bottom of page up down


Message: 91

Date: Fri, 01 Jun 2001 02:25:43

Subject: Re: Temperament program issues

From: Dave Keenan

Note that the current implementation of this algorithm may fail with a 
divide by zero error or a floating-point overflow with a generator 
that is a rational fraction of the period. It should probably check 
for the case where i and r differ by some really tiny amount and exit. 
But maybe this will never happen with any "real" generators.


top of page bottom of page up down


Message: 92

Date: Fri, 1 Jun 2001 12:39 +01

Subject: Re: Temperament program issues

From: graham@m...

In-Reply-To: <9f6tbt+q4km@e...>
Dave Keenan wrote:

> So where are the results of the latest runs and what is your ranking 
> based on now?

They're at <Automatically generated temperaments *> where they always 
were.  The ranking is how it always was, as I didn't get explicit 
instructions on that, but it shows the outputs from your function.

At this point I add that if you got the interpreter and code you could try 
whatever rankings you wanted without having to bounce them through the 
list every time.

One thing you can do, and maybe I should add an example, is supply your 
own cmp function to sort() instead of using the built-in comparisons.  
Then you can do multiple runs with different FoDs.  It may even be 
possible to supply a custom FoD interactively.

I'm also thinking of getting it to automatically upload the results by 
FTP.  That would make it a lot easier to spew out a load of different 
results.

> Is the current Figure of Demerit (FoD) the size of smallest MOS (of 
> any propriety) containing a complete otonality, divided by the 
> probability of misrecognition of the MA error with a standard error of 
> 10 cents?

No, but I could do that.

> Could you give the values of the parameters at the top of the output 
> file (MA versus RMS, MOS versus any, strictly proper MOS versus any 
> MOS, standard error). And could you give the actual FoD for each 
> generator so we can see _how_much_ better some generator might be than 
> its runner-ups?

I could do that.

> I'm sure you can knock up a simple numerical min RMS finder to give 
> you the RMS optimium generator within say 0.01 c. Take an initial 
> estimate of the generator, calculate the RMS errors for generators 
> 0.01 cents on either side. Figure out which direction reduces the RMS 
> error. Head downhill in increments of 0.01 cents until the error 
> increases again. Return the generator and RMS error before last.

Yes, but that wouldn't avoid local minima.  In the 15-limit I think these 
may be a problem.  It'd also likely overrun my lunch hour (again) if I did 
all these things.

                         Graham


top of page bottom of page up down


Message: 93

Date: Fri, 01 Jun 2001 16:39:43

Subject: Re: Temperament program issues

From: Paul Erlich

--- In tuning-math@y..., graham@m... wrote:
> In-Reply-To: <9f6tbt+q4km@e...>
> Dave Keenan wrote:
> 
> > So where are the results of the latest runs and what is your 
ranking 
> > based on now?
> 
> They're at <Automatically generated temperaments *

So under 7-limit, I presume this refers to my decatonic:

2/11, 111.043 cent generator

basis:
(0.5, 0.092535859554517375)

mapping by period and generator:
([2, 0], ([3, 5, 6], [1, -2, -2]))

mapping by steps:
([12, 10], [(19, 16), (28, 23), (34, 28)])

highest interval width: 3
complexity measure: 6  (8 for smallest MOS)
highest error: 0.014573  (17.488 cents)

Can you explain where you're getting 8 for smallest MOS? There are 
MOSs with 2, 4, 6, 8 notes, but 10 is the first proper one . . . how 
is complexity measure defined now?

P.S. If you're using propriety for anything, I'd chuck it in favor of 
CS.


top of page bottom of page up down


Message: 97

Date: Fri, 01 Jun 2001 19:37:06

Subject: Re: Fwd: A great new keyboard pattern in Blackjack (for Joseph Pehrson))

From: jpehrson@r...

--- In tuning-math@y..., "Paul Erlich" <paul@s...> wrote:

Yahoo groups: /tuning-math/message/95 *


> Did anyone notice that with this keyboard pattern, each chord looks 
> like a subset of a diminished seventh chord on the keyboard. In 
fact, 
> if you play what looks like a diminished seventh chord arpeggiated 
> all the way up and down the keyboard, you get the Mohajira scale, 
or 
> what Graham Breed calls (I think) the "neutral diatonic" scale. 
> Graham uses _still other_ chords with this scale, such as 
> the "neutral seventh chord", which is obtained in a majority of 
> positions on the keyboard when using the pattern TT-TT-TT. Which 
> reminds me, the pattern P5-P5-P5 gives you a nice "just" augmented 
> triad (in some inversion) _everywhere_ on the keyboard.

Thanks, Paul... I'll try this!

Joseph


top of page bottom of page up down


Message: 99

Date: Fri, 1 Jun 2001 12:52:57

Subject: Re: 22

From: monz

> ----- Original Message ----- 
> From: Paul Erlich <paul@s...>
> To: <tuning-math@xxxxxxxxxxx.xxx>
> Sent: Friday, June 01, 2001 12:34 PM
> Subject: [tuning-math] 22
>

> This list has 22 members. The tuning list had 2222 messages (not 
> 2221) in May. Now, where did I put the "22" T-shirt I was wearing 
> when performing my 22-tET music at the Microthon?
> 
> (where are the irrational microtonalists and numerologists when you 
> need them?)


On their respective other lists.

:)


And don't forget about the title of your old paper, which chimes
in wonderfully with "Tuning, Tonality, and 22-tone Temperament".


-monz
Yahoo! GeoCities *
"All roads lead to n^0"


 


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at Yahoo! Mail Setup *


top of page bottom of page up

Previous Next

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950

50 - 75 -

top of page