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 98000 8050 8100 8150 8200 8250 8300 8350 8400 8450 8500 8550 8600 8650 8700 8750 8800 8850 8900 8950
8800 - 8825 -
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
8000 8050 8100 8150 8200 8250 8300 8350 8400 8450 8500 8550 8600 8650 8700 8750 8800 8850 8900 8950
8800 - 8825 -