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 - Home - Section 98000 8050 8100 8150 8200 8250 8300 8350 8400 8450 8500 8550 8600 8650 8700 8750 8800 8850 8900 8950
8800 - 8825 -
Message: 8800 - Contents - Hide Contents Date: Mon, 15 Dec 2003 19:37:07 Subject: epimorphism From: Carl Lumma Definitions of tuning terms: epimorphic, (c) 2... * [with cont.] (Wayb.) 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 - Contents - Hide Contents 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 - Contents - Hide Contents Date: Mon, 15 Dec 2003 22:00:33 Subject: Re: Question for Manuel, Gene, Kees From: Manuel Op de Coul>> >e 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: 8804 - Contents - Hide Contents Date: Mon, 15 Dec 2003 22:42:46 Subject: Re: Question for Manuel, Gene, Kees, or whomever . . . From: George D. Secor --- In tuning-math@xxxxxxxxxxx.xxxx "Manuel Op de Coul" <manuel.op.de.coul@e...> wrote:> > George wrote:>> If 15/14 were changed to 16/15, the tuning would still be a constant >> structure. >> Sorry, yes. I must have made a typo when I tried it. > Those changes are ok indeed, since 225/224 is one of the unison vectors, > the others are 3025/3024, 1375/1372 and 4375/4374. > I'll change it in the archive too. >>> Is there now a definition that does not require a >> degree in mathematics to comprehend? > > See Definitions of tuning terms: epimorphic, (c) 2... * [with cont.] (Wayb.)This was the same definition that I saw before, but now that I have read this again (along with the one for vals), it makes a lot more sense now, and I now see how this property is more stringent than CS. I guess it just needed some time to to sink in. :-)> Considering all the higher than 11-limit ratios, I can imagine > it would take a lot of time to change the diagram.It depends mainly on how many of the ratios I have to change. ^>> (I'm presently trying to finish up the rest of the >> sagittal graphics for Scala.) >> Splendid, by the way I now don't use xpm files anymore, but png, > but that doesn't matter to you.Yes, I see that now. BTW, thanks for implementing mid-seq conversions. I haven't had a chance to try these out yet, but once things settle down a bit ... 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. --George
Message: 8805 - Contents - Hide Contents 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 - Contents - Hide Contents 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 - Contents - Hide Contents 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: 8808 - Contents - Hide Contents Date: Tue, 16 Dec 2003 22:24:04 Subject: Re: Chromatic Unison Vector From: d.keenan@xxxxxxx.xxx.xx --- In tuning-math@xxxxxxxxxxx.xxxx "Paul G Hjelmstad" <paul.hjelmstad@u...> wrote:> Hate to ask this, but could someone give me a good definition of a > chromatic unison vector? I'm fiddling with matrices and need to knowHave you read these excellent articles by Paul Erlich? A gentle introduction to Fokker periodicity bl... * [with cont.] (Wayb.) http://lumma.org/tuning/erlich/erlich-tFoT.pdf - Type Ok * [with cont.] (Wayb.) ________________________________________________________________________ ________________________________________________________________________ To unsubscribe from this group, send an email to: tuning-math-unsubscribe@xxxxxxxxxxx.xxx ------------------------------------------------------------------------ Yahoo! Groups Links To visit your group on the web, go to: Yahoo groups: /tuning-math/ * [with cont.] To unsubscribe from this group, send an email to: tuning-math-unsubscribe@xxxxxxxxxxx.xxx Your use of Yahoo! Groups is subject to: Yahoo! Terms of Service * [with cont.] (Wayb.)
Message: 8809 - Contents - Hide Contents 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 - Contents - Hide Contents 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 - Contents - Hide Contents 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 - Contents - Hide Contents 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 - Contents - Hide Contents Date: Tue, 16 Dec 2003 03:18:06 Subject: Re: Question for Manuel, Gene, Kees, or whomever . . . From: Carl Lumma>> >urely 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 - Contents - Hide Contents 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 - Contents - Hide Contents 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 - Contents - Hide Contents 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 - Contents - Hide Contents 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: 8819 - Contents - Hide Contents Date: Wed, 17 Dec 2003 20:34:22 Subject: A higher dimensional continued fraction From: gwsmith@xxxxx.xxx There are many analogues to the continued fraction algorithm for multiple Diophantine approximation, none very good. After asnwering a question on the main list which involved the fact that being the first smaller value |q x - p| is equivalent to being the next convergent p/q to x, it occured to me that we could extend the definition, by taking the sums of the |q x - p| for fixed q and x log2(3), log2(5) and log2(5/3). This is not an algorithm, but rather a definition. In other and more precise words, we take the sums |q*log2(3) - h(q, 3)| + |q*log2(5) - h(q, 5)| + |log2(5)*h(q, 3)-log2(3)*(h(q, 5)| and take the successive minima, which corresponds to making the product of the {2,3}-comma, the {2,5}-comma and the {3,5}-comma minimal. When I do this, I get the following list of ets and products of commas: 1 2.210897 2 1.485097 3 .794231 7 .530043 12 .418729 19 .311429 53 .156774 118 .117232 171 .090692 441 .087385 612 .061480 1171 .045611 1783 .038109 2513 .032660 4296 .011628 This can, of course, be extended to higher limits. I'd better ask on sci.math if anyone's heard of this. Or maybe email Jeff Shallet.
Message: 8820 - Contents - Hide Contents Date: Thu, 18 Dec 2003 00:55:01 Subject: Re: A higher dimensional continued fraction From: d.keenan@xxxxxxx.xxx.xx --- In tuning-math@xxxxxxxxxxx.xxxx gwsmith@s... wrote:> There are many analogues to the continued fraction algorithm for > multiple Diophantine approximation, none very good. ... > This can, of course, be extended to higher limits. ...This is interesting. I am curious to see the results for higher limits.
Message: 8821 - Contents - Hide Contents Date: Thu, 18 Dec 2003 01:32:36 Subject: Re: A higher dimensional continued fraction From: gwsmith@xxxxx.xxx --- In tuning-math@xxxxxxxxxxx.xxxx d.keenan@b... wrote:> --- In tuning-math@xxxxxxxxxxx.xxxx gwsmith@s... wrote:>> There are many analogues to the continued fraction algorithm for >> multiple Diophantine approximation, none very good. > ...>> This can, of course, be extended to higher limits. > ... >> This is interesting. I am curious to see the results for higher limits.I've concluded that the whole thing makes more sense if we treat 2 the same as the odd primes. Let me make some definitions. If v is a val and a and b are relatively prime positive integers, I'll define the {a,b}-comma, or a/b-comma, for v as either a^v(b)/b^v(a) or b^v(a)/a^v(b) depending on which is greater than 1. If either of a or b is 1, the a/b-comma is also 1, so we can ignore this case and assume both a and b are greater than 1 if we wish. For a given postive integer L, the L-even-limit, or L-cap consonances, are a/b, a, b <= L, a and b relatively prime and where we may additionally assume a/b > 1. The L-cap badness measure for v is then defined as the product of all a/b-commas for a/b an L-cap consonance. Below I list successively better standard vals for cap limits from 5 to 13, and n from 1 to 1000; as usual it makes no real difference to restrict to standard vals because we are looking at best of breed anyway. I list the equal division n, and next to it the log base 2 of the L-cap badness measure (which is an ugly looking rational number I don't want to mess with.) 5 cap 1 1 3.684828 2 2.537235 3 1.352888 7 1.226512 12 .731555 34 .669239 53 .287177 118 .193352 612 .107366 6 cap 1 5.480687 2 3.852407 3 1.833575 7 1.661817 12 1.130734 19 .809398 34 .786874 53 .440938 118 .285008 441 .213453 612 .165899 730 .164162 7 cap 1 8.936697 2 7.674194 3 7.312043 4 4.175933 12 3.815278 19 3.065070 31 2.008584 72 1.808742 99 1.392254 171 .568097 8 cap 1 11.725529 2 10.408271 3 9.416222 4 6.746879 5 6.049309 10 5.867766 12 5.219740 19 4.777064 22 4.702956 31 2.554792 99 2.261336 171 .976047 9 cap 1 21.373486 2 16.540848 3 16.101527 4 12.672183 5 8.378538 12 7.076935 19 6.744799 31 5.509181 41 4.969997 53 4.356189 99 3.598852 171 1.366268 10 cap 1 28.584111 2 20.207791 3 19.879698 4 14.736610 5 10.703392 12 8.573892 19 8.130354 31 7.088977 41 6.302737 53 5.494689 72 5.153786 99 3.992756 171 1.466939 11 cap 1 42.871697 2 26.752811 4 25.759778 5 20.792831 7 17.489047 12 17.427374 15 17.181518 22 14.358025 31 11.034810 72 7.688143 270 5.353860 342 3.990495 12 cap 1 48.546856 2 31.161133 4 27.891159 5 23.685995 7 20.139916 15 18.691086 22 16.281841 31 12.099355 72 8.314304 270 5.991772 342 4.719771 13 cap 1 61.688418 2 43.938450 4 42.273300 5 35.573172 7 28.108502 15 27.801661 19 26.452925 31 23.684039 41 22.121134 53 19.854742 72 16.495624 224 14.411084 270 10.995631 494 8.532451
Message: 8822 - Contents - Hide Contents Date: Thu, 18 Dec 2003 04:31:18 Subject: Re: A higher dimensional continued fraction From: d.keenan@xxxxxxx.xxx.xx --- In tuning-math@xxxxxxxxxxx.xxxx gwsmith@s... wrote:> Below I list successively better standard vals for cap limits from > 5 to 13, and n from 1 to 1000; as usual it makes no real difference to > restrict to standard vals because we are looking at best of breed > anyway. I list the equal division n, and next to it the log base 2 of > the L-cap badness measure (which is an ugly looking rational number I > don't want to mess with.) ...I'd appreciate it if you could give these sequences for integer-limits to 31 and ETs to 5000. The reason I'm interested is because it may help us decide the best places to site the various precision-levels of Sagittal JI notation. Only one such level is effectively set in stone now, and that's the medium-precision "athenian" set which is similar (epimorphic?) to 224-ET. I notice 224-ET first appears in the 13-integer-limit list. Of course, integer limit is not really what would be most relevant to this application, but I'm interested nonetheless. On the subject of what sort of "limit" would be most relevant to this: If anyone can come up with a simple real-valued function of the following 2,3-free ratios (or rather their exponent vectors) that would give roughly monotonically increasing values for the following ratio sequence I'd be very interested. This might then be extrapolated back to include powers of 2 and 3 in some reasonable way. These are listed in popularity order from the Scala archive. 1 5 7 25 5:7 11 35 125 49 13 5:11 7:11 17 7:25 5:49 5:13 175 19 245 7:13 625 23 25:49 55 77 5:17 5:19 11:35 11:13 31 343 29 7:125 7:55 11:17 5:77 7:19 385 49:55 7:17 1225 37 121 5:23 13:19 13:17 7:23 11:25 11:31 65 47 13:25 3125 11:49 11:19 5:343 91 43 5:29 11:37 11:23 13:23 25:77 49:125 15625 143 5:31 13:35 25:343 5:37 17:19 41 95 53 17:23 ________________________________________________________________________ ________________________________________________________________________ To unsubscribe from this group, send an email to: tuning-math-unsubscribe@xxxxxxxxxxx.xxx ------------------------------------------------------------------------ Yahoo! Groups Links To visit your group on the web, go to: Yahoo groups: /tuning-math/ * [with cont.] To unsubscribe from this group, send an email to: tuning-math-unsubscribe@xxxxxxxxxxx.xxx Your use of Yahoo! Groups is subject to: Yahoo! Terms of Service * [with cont.] (Wayb.)
Message: 8824 - Contents - Hide Contents 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 -