Tuning-Math Digests messages 8800 - 8824

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 9

Previous Next

8000 8050 8100 8150 8200 8250 8300 8350 8400 8450 8500 8550 8600 8650 8700 8750 8800 8850 8900 8950

8800 - 8825 -



top of page bottom of page down


Message: 8800

Date: Mon, 15 Dec 2003 19:37:07

Subject: epimorphism

From: Carl Lumma

Definitions of tuning terms: epimorphic, (c) 2002 by Joe Monzo *

By the way, the definition on monz's site is woefully
inadequate.  For it to work, we need to know Gene's
definition of "scale" which isn't there or on his own
site, so we know what type of value we're plugging in
to h().  We also need to know what the hell kind of
operation is () here.

Furthermore, if CS = epimorphic it should say so.  If
there's some weaker relationship it should also say so.

Gene, what do you think about putting all your definitions
in one place, say on Wikipedia, where the interlinks will
happen automagically?

-Carl


top of page bottom of page up down


Message: 8801

Date: Mon, 15 Dec 2003 21:52:19

Subject: Re: epimorphism

From: Manuel Op de Coul

I found the bug, it will be fixed in the next version.

>Furthermore, if CS = epimorphic it should say so.  If
>there's some weaker relationship it should also say so.

Epimorphism implies CS, but not v.v. so it's not the same.

I also explained it in a few sentences in tips.par.
Suggestions for improvement are welcome.

Manuel


top of page bottom of page up down


Message: 8802

Date: Mon, 15 Dec 2003 22:00:33

Subject: Re: Question for Manuel, Gene, Kees

From: Manuel Op de Coul

>> We used different periodicity blocks to optimise.
>> At least that's what I think.

Gene wrote:
>That should make no difference.

But it means the results will not be the same,
doesn't it?

Manuel


top of page bottom of page up down


Message: 8805

Date: Mon, 15 Dec 2003 13:18:10

Subject: Re: epimorphism

From: Carl Lumma

>I found the bug, it will be fixed in the next version.
>
>>Furthermore, if CS = epimorphic it should say so.  If
>>there's some weaker relationship it should also say so.
>
>Epimorphism implies CS, but not v.v. so it's not the same.
>
>I also explained it in a few sentences in tips.par.
>Suggestions for improvement are welcome.

I didn't know this file existed.  I find it generally
obnoxious.  Why don't you fold it into the context-sensitive
help?  If you really must have a tip-of-the-day, you could
then take it from that unified source.

I read the file for the string "epi".  I thought the plain-
English version of Gene's def. on monz's site good, though
I'd still like to get the formal version cleaned up.  Note:

() I'm not clear whether "epimorphic" and "JI-epimorphic"
refer to separate things.  I don't see why epimorphism would
apply only to JI, but if they really are separate then a
discussion of the non-JI usage is missing.

Also it seems implied that non-torsion = epimorphic.  Is
that true?

-Carl


top of page bottom of page up down


Message: 8806

Date: Tue, 16 Dec 2003 12:23:57

Subject: Re: epimorphism

From: Carl Lumma

>Carl asked:
>>I didn't know this file existed.  I find it generally
>>obnoxious.  Why don't you fold it into the context-sensitive
>>help?
>
>Because a large part applies to the gui-elements, and the
>help file is about the core part of the program, the command
>functions.

But now the user has to check two separate sources of
information!

>>Also it seems implied that non-torsion = epimorphic.  Is
>>that true?
>
>I don't know, but I suspect it's not true.

The bit I was referring to is here:

>Smith's definition: "Torsion describes a condition wherein an
>independent set of n unison vectors {u1, u2, ..., un} defines a
>non-epimorphic periodicity block, because of the existence of
>a torsion element, meaning an interval which is not the product
>u1^e1 u2^e2 ... un^en of the set of unison vectors raised to
>(positive, negative or zero) integral powers, but some integer
>power of which is. An example would be a block defined by 648/625
>and 2048/2025; here 81/80 is not a product of these commas, but
>(81/80)^2 = (648/625) (2048/2025)^(-1)."

-Carl


top of page bottom of page up down


Message: 8807

Date: Tue, 16 Dec 2003 23:18:43

Subject: Re: epimorphism

From: Manuel Op de Coul

Carl wrote:
>But now the user has to check two separate sources of
>information!

I've mentioned them both in the readme file. Lots of
programs have separate tips and help file. Some info
might be moved, I agree.


>>I don't know, but I suspect it's not true.
>The bit I was referring to is here:

It doesn't say about the opposite. Anyway it's not true,
and I'll add it to the tip.

Manuel


top of page bottom of page up down


Message: 8809

Date: Tue, 16 Dec 2003 12:01:53

Subject: Re: Chromatic Unison Vector

From: Manuel Op de Coul

It's just a unison vector in the sense that it defines the
periodicity block in the same way, but it's a different one in
the strict sense because the periodicity block will have
intervals smaller than this chromatic unison vector, which is
normally avoided. So it's always the largest unison vector of
the set, and called "chromatic" because it's not supposed to
"vanish".

Manuel


top of page bottom of page up down


Message: 8810

Date: Tue, 16 Dec 2003 12:10:22

Subject: Re: Question for Manuel, Gene, Kees, or whomever . . .

From: Manuel Op de Coul

George wrote:
>Has anyone ever requested Scala capability to make the computer
>keyboard a polyphonic keyboard?  With what you now have, it is
>necessary to press the key again to stop a tone; instead, releasing a
>key would stop a tone.  I can think of several possibilities for
>arranging tones on the keyboard, and the cursor keys could be
>employed to scroll the pitches to avoid running out of keys.

Yes, Robert Walker has. I also tried to implement it, but it
didn't work under Windows. Under Linux it worked fine (as so often).
So I reversed the change, because under Windows the tone would go
off immediately and I don't like to maintain different versions.
There's a problem with the key-release event, which I hope will be
fixed someday.
Robert was kind enough to show how I could descend into the
Windows depths and might try to work around it, but I avoid
writing platform-specific code like the plague.

Manuel


top of page bottom of page up down


Message: 8811

Date: Tue, 16 Dec 2003 03:13:40

Subject: Re: Question for Manuel, Gene, Kees, or whomever . . .

From: Carl Lumma

>Robert was kind enough to show how I could descend into the
>Windows depths and might try to work around it, but I avoid
>writing platform-specific code like the plague.

Surely a 'typematic' sort of thing would work on all platforms?

-Carl


top of page bottom of page up down


Message: 8812

Date: Tue, 16 Dec 2003 12:15:07

Subject: Re: Question for Manuel, Gene, Kees, or whomever . . ..

From: Manuel Op de Coul

>Surely a 'typematic' sort of thing would work on all platforms?

No idea what you mean by that.

Manuel


top of page bottom of page up down


Message: 8813

Date: Tue, 16 Dec 2003 03:18:06

Subject: Re: Question for Manuel, Gene, Kees, or whomever . . .

From: Carl Lumma

>>Surely a 'typematic' sort of thing would work on all platforms?
>
>No idea what you mean by that.

Well if I hold down the "b" key, I'll get a string of bs until
I let it off.  That works on all platforms I've ever used.  So
one could simply have a buffer which would signal note-off if
it ever emptied.  Not that it's necessary to duplicate Robert's
work...

-Carl


top of page bottom of page up down


Message: 8814

Date: Tue, 16 Dec 2003 12:23:40

Subject: Re: epimorphism

From: Manuel Op de Coul

Carl asked:
>I didn't know this file existed.  I find it generally
>obnoxious.  Why don't you fold it into the context-sensitive
>help?

Because a large part applies to the gui-elements, and the
help file is about the core part of the program, the command
functions.

> I'm not clear whether "epimorphic" and "JI-epimorphic"
>refer to separate things.

No, but because epimorphism is such a broad term, I called
it "JI-epimorphic" to indicate that it applies to the interval
ratios. (Now Dave probably says then it should be RI-epimorphic
and he would be right).

>Also it seems implied that non-torsion = epimorphic.  Is
>that true?

I don't know, but I suspect it's not true.

Manuel


top of page bottom of page up down


Message: 8815

Date: Tue, 16 Dec 2003 12:30:36

Subject: Re: Question for Manuel, Gene, Kees, or whomever . . . .

From: Manuel Op de Coul

Hmm, what if the user has disabled key repetition.
Anyway then using Robert's solution would be preferable.

Manuel


top of page bottom of page up down


Message: 8816

Date: Tue, 16 Dec 2003 13:10:11

Subject: Re: epimorphism

From: Manuel Op de Coul

>Also it seems implied that non-torsion = epimorphic.  Is
>that true?

It's not true because I found a counterexample. The
[225/224, 1029/1024, 25/24] block is not a Constant Structure
and it has no torsion.

Manuel


top of page bottom of page up down


Message: 8818

Date: Tue, 16 Dec 2003 15:51:52

Subject: Re: Chromatic Unison Vector

From: Manuel Op de Coul

The non-chromatic unison vectors are called commatic unison
vectors. This is a simple example: 64/63 and 50/49 commatic and
36/35 chromatic. The PB is
21/20 8/7 6/5 49/40 4/3 7/5 3/2 8/5 12/7 7/4 28/15 2/1
This be tempered I think with a half-octave period.

Manuel


top of page bottom of page up down


Message: 8824

Date: Fri, 19 Dec 2003 21:02:37

Subject: Re: Question for Manuel, Gene, Kees, or whomever . . .

From: Paul Erlich

--- In tuning-math@xxxxxxxxxxx.xxxx "George D. Secor" <gdsecor@y...> 
wrote:
> --- In tuning-math@xxxxxxxxxxx.xxxx "Manuel Op de Coul" 
> <manuel.op.de.coul@e...> wrote:
> > 
> > >However useful those criteria may be, I consider 64/63 and 63/32
> > >simpler because:
> > >1) The prime numbers in the factors are lower; and
> > >2) The range of numbers in the ratios (32 to 64) is lower (than 
44 
> to
> > >88).
> > 
> > Still there are more consonant chords in the scale with the 
original
> > pitches.
> > 
> > Manuel
> 
> The next thing that I found was that I would have 28/27 and 27/14 
> instead of 25/24 and 48/25 (for which I would imagine that your 
reply 
> would be the same).

George, the reason for choices like these become clearer if you 
extend the scale slightly beyond one octave, by octave transposition.

> Another question is: why 15/14 and 15/8 (when 16/15 would have been 
> the inversion of 15/8)?

Aha -- looks like Manuel was making an arbitrary choice in the case 
of a tie, perhaps letting Tenney complexity break the tie.


top of page bottom of page up

Previous Next

8000 8050 8100 8150 8200 8250 8300 8350 8400 8450 8500 8550 8600 8650 8700 8750 8800 8850 8900 8950

8800 - 8825 -

top of page