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 8First Previous Next
7000 7050 7100 7150 7200 7250 7300 7350 7400 7450 7500 7550 7600 7650 7700 7750 7800 7850 7900 7950
7000 - 7025 -
Message: 7001 Date: Sun, 06 Jul 2003 09:19:37 Subject: 19-limit miracle From: Gene Ward Smith I was pondering the 351/350 comma, which allows the 1--9/7--20/13 triad to be considered as having a 6/5 from 9/7 to 20/13. This is a feature of 13-limit meanpop, and hence my "ratwolf" and what one might call "wilwolf", which is meanpop[12] using a Wilson fifth. It's also a feature of the logical extension of 11-limit miracle to 13-limit; one adds 351/350 to <225/224, 243/242, 385/384> and gets a 13-limit version of miracle which 72-et supports, but for which 175--which is poptimal--is a much better choice. We pick the second-best tuning for 13, and [175, 277, 406, 491, 605, 647] works out nicely. It also extends naturally to a 19-limit version, [175, 277, 406, 491, 605, 647, 715, 743]. A comma basis for this is [225/224, 243/242, 273/272, 324/323, 351/350, 375/374, 1445/1444]. If we leave off the 1445/1444 we get a basis for the 19-limit miracle, but really there seems little point in trying to separate this from 175, any more than much is to be gained by prying 11-limit miracle away from 72. It might be interesting to explore some of the Fokker blocks these comma sets lead to.
Message: 7002 Date: Mon, 07 Jul 2003 21:04:36 Subject: Re: Reply to Gene From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx "pitchcolor" <pitchcolor@a...> wrote:
> Hi Gene, > > Since it appears that you don't actually read anything that I
write,
> I'm not sure what else to say to you.
Read Manuel's reply, and the MTS. Before you claim to know how
> this stuff works, try building your own instruments using the
protocol. Before claiming to know how this works, try rendering a midi file.
Message: 7003 Date: Mon, 07 Jul 2003 22:45:58 Subject: Re: 19-limit miracle From: Dave Keenan So Gene, What is the mapping from generators to primes and what are the errors?
Message: 7004 Date: Mon, 07 Jul 2003 01:13:30 Subject: Re: Mu explained From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx pitchcolor@a... wrote:
> channel 1: MIDI note on 59, bend 127 (full bend upwards) > channel 2: MIDI note on 60, bend 64 (NO BEND) > > THESE PITCHES ARE NOT IN UNISON. > > > What does MIDI note 59 with bend 127 result in? It is slightly flat
of the
> halfstep above. Turn of all notes and then try this: > > channel 1: MIDI note 59, bend 127 (full bend upwards) > channel 1: MIDI note 60, bend 63 (bent one unit down) > > THESE PITCHES ARE IN UNISON. > > > To summarize: > > The range of 7 bit pitch bend is 0-127 > Absence of pitch bend is data 64 > Bend data 0 reaches an equal tempered halfstep below > Bend data 127 is one midi unit below an equal tempered halfstep
above
> > > > THE FULL RANGE 0-127 SPANS JUST UNDER A WHOLE STEP > THIS IS AN EQUAL DIVISION OF 128 UNITS PER WHOLESTEP. > > > > There are 6 equal tempered wholesteps in an octave, resulting in: > > > > 6 x 128 = 768 ED2 > What about the MIDI Tuning Standard? > > Although the MTS is not in use by most manufacturers, some do
support it, and
> we will see more units supporting it in the future. 14 bits may be
seen as 7
> bit units expanded by 128 values per unit. The 768 unit behavior -
the way
> they divide up a WHOLESTEP - is still in force as the MSB (Most
Significant
> _Byte) in a 2 byte message. The MTS at 14 bits gives: > > > > MTS = 768 x 128 = 98304 ED2 > > > So, once and for all, > > THE MTS DOES NOT RESULT IN 196608 DIVISIONS PER OCTAVE > THE MTS RESULTS IN 98304 DIVISIONS PER OCTAVE.
It does not. Before you set up a web page with incorrect information on it, please read and study the official standard. Putting up a web page with the wrong information is extemely counterproductive, and you should verify what you think you know by going to the official sources before doing so.
Message: 7005 Date: Mon, 07 Jul 2003 07:14:09 Subject: Re: Modulatory topology in 22-TET From: wallyesterpaulrus --- In tuning-math@xxxxxxxxxxx.xxxx "hstraub64" <straub@d...> wrote:
> OK, I checked it over now - and found out that Kalle is right. > In details: > Two pentachord major scales at the distance of 11 steps have 4 > tetrads in common (I, IV, VI and IX), while two pentachord major > scales at the distance of 2 steps have 3 tetrads in common (one of > II/III, VI/VII and VIII/IX each) and two at at the distance of 9 or > 13 (which, BTW, is 11 + 2 and 11 - 2) have 2 in common (one of I/VII > and IV/VIII each). > > So, if we use only modulations following the "easiest" path, they do > not lead all around the circle of fifths as in Z12 but oscillate > forever between just 2 tonalities... > > But if we include the next-easiest step, we still get the 2- > dimensional structure of Z11 x Z2 I described! (Just not with equal > distances - the tritone distance is smaller.)
you could also look at the number of *notes* in common, and get back to the two distances being the same.
Message: 7007 Date: Mon, 7 Jul 2003 16:23:00 Subject: Re: Reply to Gene From: Manuel Op de Coul Dear Aaron, So there are two different implementations of pitch bend messages. I didn't know that and you probably either.
> > bit units expanded by 128 values per unit. The 768 unit behavior -
> the way
> > they divide up a WHOLESTEP - is still in force as the MSB (Most
> Significant
> > _Byte) in a 2 byte message.
Now I get it, you're talking about the two-byte octave tuning dump! We were referring to the older and more widely adopted bulk dump and single note change messages. Anyway you could have studied the standard better before being so convinced. Manuel
Message: 7008 Date: Tue, 08 Jul 2003 22:56:47 Subject: Re: 19-limit miracle From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx "Dave Keenan" <D.KEENAN@U...> wrote:
> I'm afraid that jump in complexity from 22 to 49, in going from > 11-limit to 13-limit, (and then 88 for 19-limit) makes it fairly > uninteresting, except perhaps as a way of mapping higher primes to a > miracle (decimal) keyboard.
This more or less says that 19-limit temperaments are never interesting.
Message: 7009 Date: Tue, 08 Jul 2003 01:36:36 Subject: Re: 19-limit miracle From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx "Dave Keenan" <D.KEENAN@U...> wrote:
> What is the mapping from generators to primes and what are the errors?
Mapping to primes: [[1, 1, 3, 3, 2, 7, 7, -1], [0, 6, -7, -2, 15, -34, -30, 54]] Errors of the primes, in cents: [-2.52, -2.32, -1.97, -2.76, -3.96, -2.09, -2.66] commas: [225/224, 243/242, 273/272, 324/323, 351/350, 375/374] (Since this is in effect 175-et, we may want to add 1445/1444) 175-et val: [175, 277, 406, 491, 605, 647, 715, 743] (not "standard") rms secor: .09714280747968 = 16.999991308944 / 175
Message: 7010 Date: Tue, 8 Jul 2003 19:41:21 Subject: Re: 768 and the Hexe temperament From: monz thanks, Gene! i suddenly have a tremendous interest in 768edo, since i've found out that that's what my microtonal music has effectively been tuned in for years! i'm looking forward to making lattices of this data, but at this point any new lattices will have to wait until my software can produce them ... which it will soon. -monz ----- Original Message ----- From: "Gene Ward Smith" <gwsmith@xxxxx.xxx> To: <tuning-math@xxxxxxxxxxx.xxx> Sent: Tuesday, July 08, 2003 5:25 PM Subject: [tuning-math] 768 and the Hexe temperament
> Here are some TM-reduced comma bases for the 768-et: > > 5-limit > [476837158203125/474989023199232, > 1350851717672992089/1342177280000000000] > > 7-limit > [65625/65536, 250047/250000, 49589822592/49433168575] > > 11-limit > [9801/9800, 19712/19683, 703125/702464, 1296000/1294139] > > > If we take 65625/65536 and 240047/250000 we get a linear temperament > I'll name Hexe (which, despite being German, you aren't required to > capitalize unless you wish.) > > Wedgie [12, 3, -36, -44, -116, -92] > > Mapping [[3, 5, 7, 8], [0, -7, -1, 12]] > > Generators (in terms of 768-et) [256, 9] > > Hexe is really pretty much of a 171-et specialty, but 768 does it > also. Aside from 171, we get decent MOS for 84 and 87.
Message: 7011 Date: Tue, 08 Jul 2003 02:02:24 Subject: Re: 19-limit miracle From: Dave Keenan --- In tuning-math@xxxxxxxxxxx.xxxx "Gene Ward Smith" <gwsmith@s...> wrote:
> --- In tuning-math@xxxxxxxxxxx.xxxx "Dave Keenan" <D.KEENAN@U...> wrote: >
> > What is the mapping from generators to primes and what are the errors?
> > Mapping to primes: > [[1, 1, 3, 3, 2, 7, 7, -1], [0, 6, -7, -2, 15, -34, -30, 54]] > > Errors of the primes, in cents: > [-2.52, -2.32, -1.97, -2.76, -3.96, -2.09, -2.66] > > commas: [225/224, 243/242, 273/272, 324/323, 351/350, 375/374] > (Since this is in effect 175-et, we may want to add 1445/1444) > > 175-et val: [175, 277, 406, 491, 605, 647, 715, 743] (not "standard") > > rms secor: .09714280747968 = 16.999991308944 / 175
I'm afraid that jump in complexity from 22 to 49, in going from 11-limit to 13-limit, (and then 88 for 19-limit) makes it fairly uninteresting, except perhaps as a way of mapping higher primes to a miracle (decimal) keyboard.
Message: 7012 Date: Wed, 09 Jul 2003 10:00:07 Subject: xenharmony.org From: Carl Lumma Funny; the DNS doesn't seem to be available yet. http://66.246.86.148/~xenharmo/intval.html * [with cont.] (Wayb.) I understand everything here but the last paragraph. -Carl
Message: 7013 Date: Wed, 09 Jul 2003 00:25:46 Subject: 768 and the Hexe temperament From: Gene Ward Smith Here are some TM-reduced comma bases for the 768-et: 5-limit [476837158203125/474989023199232, 1350851717672992089/1342177280000000000] 7-limit [65625/65536, 250047/250000, 49589822592/49433168575] 11-limit [9801/9800, 19712/19683, 703125/702464, 1296000/1294139] If we take 65625/65536 and 240047/250000 we get a linear temperament I'll name Hexe (which, despite being German, you aren't required to capitalize unless you wish.) Wedgie [12, 3, -36, -44, -116, -92] Mapping [[3, 5, 7, 8], [0, -7, -1, 12]] Generators (in terms of 768-et) [256, 9] Hexe is really pretty much of a 171-et specialty, but 768 does it also. Aside from 171, we get decent MOS for 84 and 87.
Message: 7015 Date: Wed, 09 Jul 2003 21:33:09 Subject: Re: xenharmony.org From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx Carl Lumma <ekin@l...> wrote:
> Funny; the DNS doesn't seem to be available yet.
I've written to complain. I'll poke them again.
> http://66.246.86.148/~xenharmo/intval.html * [with cont.] (Wayb.) > > I understand everything here but the last paragraph.
This? Given the p-limit group Np of intervals, there is a non-canonically isomorphic dual group Vp of vals. A val is a homomorphism of Np to the integers Z. Just as an interval may be regarded as a Z-linear combination of basis elements representing the prime numbers, a val may be regarded as a Z-linear combination of a dual basis, consisting of the p-adic valuations. For a given prime p, the corresponding p- adic valuation vp gives the p-exponent of an interval q, so for instance v2(5/4) = -2, v3(5/4) = 0, v5(5/4) = 1. If an interval is written as a row vector of intervals, a val is simply a column vector of intervals. It does read a lot like math, now that I look at it. Maybe I need a translator.
Message: 7016 Date: Wed, 09 Jul 2003 04:16:04 Subject: Re: 768 and the Hexe temperament From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx "monz" <monz@a...> wrote:
> thanks, Gene! > > i suddenly have a tremendous interest in > 768edo, since i've found out that that's > what my microtonal music has effectively > been tuned in for years!
Next we need to measure the pitch accuracy of the sound samples people use if we are really going to pin this down.
Message: 7017 Date: Wed, 09 Jul 2003 22:03:32 Subject: Re: xenharmony.org From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx "Gene Ward Smith" <gwsmith@s...> wrote: If an interval is
> written as a row vector of intervals, a val is simply a column
vector
> of intervals.
I see I said "intervals" twice when I mean "integers". That could be a teeny-weeny problem. :) Keep up the good work, Carl.
Message: 7018 Date: Wed, 09 Jul 2003 08:19:30 Subject: Re: 768 and the Hexe temperament From: Paul Erlich --- In tuning-math@xxxxxxxxxxx.xxxx "Gene Ward Smith" <gwsmith@s...> wrote:
> Here are some TM-reduced comma bases for the 768-et: > > 5-limit > [476837158203125/474989023199232, > 1350851717672992089/1342177280000000000] > > 7-limit > [65625/65536, 250047/250000, 49589822592/49433168575] > > 11-limit > [9801/9800, 19712/19683, 703125/702464, 1296000/1294139]
iirc, 768-equal isn't consistent in the 9-limit, so there is probably a different 11-limit mapping, besides the "standard" one, which gives good results.
Message: 7019 Date: Wed, 09 Jul 2003 08:28:47 Subject: Re: 768 and the Hexe temperament From: Gene Ward Smith --- In tuning-math@xxxxxxxxxxx.xxxx "Paul Erlich" <perlich@a...> wrote:
> iirc, 768-equal isn't consistent in the 9-limit, so there is
probably
> a different 11-limit mapping, besides the "standard" one, which
gives
> good results.
I don't think so, but I'll look again. It's occurred to be that the gram or zeta tunings might be another way to define a "standard" val, by the way. Would that be too far out? It would tend to home in on the more interesting stuff.
Message: 7020 Date: Wed, 09 Jul 2003 09:42:56 Subject: Re: 768 and the Hexe temperament From: Graham Breed Gene Ward Smith wrote:
> I don't think so, but I'll look again. It's occurred to be that the > gram or zeta tunings might be another way to define a "standard" val, > by the way. Would that be too far out? It would tend to home in on > the more interesting stuff.
The best 9-limit mapping is
[768, 1217, 1783, 2156]
which has a worst error of 0.502 scale steps.
Graham
Message: 7021 Date: Thu, 10 Jul 2003 00:34:52 Subject: Re: hexaMu vs. heptaMu From: monz hi Aaron,
> From: "pitchcolor" <pitchcolor@xxx.xxx> > To: <tuning-math@xxxxxxxxxxx.xxx> > Sent: Wednesday, July 09, 2003 1:50 PM > Subject: [tuning-math] hexaMu vs. heptaMu > > > Here is the issue as I see it: does the number of bits specified > by the unit name reflect the proper subdivision of the halfstep as > well as the MIDI data format? My feeling is that it needs to do > both. How do we accomplish this? Here's my answer: > > > <snip> > > 'Center detent' data such as the data I have on my pitch bend > page can also be seen as a form of _signed data. The 7 data > bits can just as well be seen as 6 data bits with a least > significant sign bit.
no, actually, it's the *most* significant bit which acts as the sign flag. as i explained here on Monday Yahoo groups: /tuning/message/45352 * [with cont.]
>> the "x" represents the status flag at the >> beginning of the byte, and is not recognized >> as part of the tuning resolution. >> >> >> >> x 64 32 16 8 4 2 1 -- decimal value >> x 1 0 0 0 0 0 0 -- bits >> >> = 64 decimal = the plain MIDI-note, >> 0 cents deviation from 12edo. >> >> >> >> x 64 32 16 8 4 2 1 -- decimal value >> x 1 0 0 0 0 0 1 -- bits >> >> = 65 decimal = one unit (1.5625 cents) >> above the 12edo MIDI-note. >> >> >> >> x 64 32 16 8 4 2 1 -- decimal value >> x 0 1 1 1 1 1 1 -- bits >> >> = 63 decimal = one unit (1.5625 cents) >> below the 12edo MIDI-note.
> 0 = below, 1 = above. Thus the 7 data bits > become 6 data bits with a _sign _bit. I hope this is not > something somene already pointed out and I just missed it.
i already revised my hexamu page a couple of days ago to say this. Definitions of tuning terms: hexamu, (c) 2003 ... * [with cont.] (Wayb.) it's in the second paragraph quoted here:
>> "However, as of 2003, almost all MIDI hardware, including >> both keyboards and other "regular" musical instruments >> and most computer soundcards, ignores the less significant >> byte of the two MIDI pitch-bend data bytes, thus limiting >> tuning resolution to only 7 bits. >> >> Because the pitch-bend protocol uses the most significant >> of these bits only to designate the frequency of the 12edo >> MIDI-note which lies as close as possible to the center >> of the pitch-bend range (namely, 1/2-unit above the exact >> center), in effect making this bit merely a flag which >> indicates the sign showing the direction of the pitch-bend, >> and because the smallest total pitch-bend range from this >> center is +/- 100 cents, the effective maximum resolution >> for all of this hardware is 6 bits per Semitone.
-monz
Message: 7023 Date: Thu, 10 Jul 2003 11:55:56 Subject: Re: hexaMu vs. heptaMu From: monz hi Aaron,
> From: "pitchcolor" <pitchcolor@xxx.xxx> > To: <tuning-math@xxxxxxxxxxx.xxx> > Sent: Thursday, July 10, 2003 11:31 AM > Subject: [tuning-math] Re: hexaMu vs. heptaMu > > > Hi monz, >
> > > The 7 data > > > bits can just as well be seen as 6 data bits > > > with a least significant sign bit.
> > > > > > no, actually, it's the *most* significant bit which > > acts as the sign flag.
> > In any case, the interpretation is unorthodox. > Usually a sign bit indicates that the 2s complement > will be taken from the data bits, and that isn't > what goes on here. This unusual 'sign' bit isn't > really a sign bit. Let's call it a 'flag'. It > means specifically: > > 0 = n - 1 > 1 = n > > where n is the given MIDI note number > > The 6 data bits then indicate 64 versions of a MIDI note, either > focused on n-1 or n according to the flag. > > Now, this interpretation may cause some minor > confusion in the relation of a MIDI note with > a sample. No matter what the flag is, the sample > is still taken from n. When the flag is 0, the > sample is still taken from n, not from n-1.
i agree with what you say, and in fact that bit doesn't *really* indicate sign, since the values which are less than "n" (the 12edo MIDI-note) are not measured downward from n (i.e., using negative numbers), but rather as you say, upward from "n-1". but in practice it might still be easier to think of it as a sign bit, and in fact, in the dodekamu implementation in Cakewalk and numerous other software sequencers, it does actually work that way. the user actually has a choice to render a note with pitch-bend either by using negative values for the pitch-bend data or by keeping track of the MIDI-notes by assigning them mentally to 8192 dodekamus above the MIDI-note specified as "0". i've seen it done both ways, but of course the method using negative numbers works better because the score shows the MIDI-note that's closest to the target microtonal note, which is what one expects to see. -monz
Message: 7024 Date: Thu, 10 Jul 2003 22:14:12 Subject: Meantones of 768 From: Gene Ward Smith As Graham pointed out, it's not really necessary to use the same fifth to get a decent meantone. However, it might be worth looking at the available meantone fifths for the 768-et 149/256 This is a good Mozart-type meantone, .07 cents flatter than 39/67. It is interesting to note that this meantone is also available in 512-et systems such as Paul's. 223/384 This is quite close to 18/31, with a fifth about a tenth of a cent sharper. 445/768 This is another good meantone, .32 cents flatter than Wilson and .58 cents sharper than 19-equal.
First Previous Next
7000 7050 7100 7150 7200 7250 7300 7350 7400 7450 7500 7550 7600 7650 7700 7750 7800 7850 7900 7950
7000 - 7025 -