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 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: 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: 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: 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 * I understand everything here but the last paragraph. -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: 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 * >> 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 by Joe Monzo * 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
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 -