Yahoo Tuning Groups Ultimate Backup tuning 768edo de facto tuning standard

hi Kraig,

> From: "Kraig Grady" <kraiggrady@anaphoria.com>
> To: <tuning@yahoogroups.com>
> Sent: Tuesday, July 08, 2003 9:56 PM
> Subject: [tuning] 768edo de facto tuning standard
>
>
> >
> > From: "monz" <monz@attglobal.net>
> > Subject: 768edo de facto tuning standard?
> >
> > hello all,
> >
> >
> >
> > whichever method of defining "mus" is finally accepted
> > by the general tuning community, i propose recognizing
> > 768edo as the _de facto_ hardware tuning standard.
> >
> > any objections?
>
> 768 IS UNUSABLE, HORRIBLE, AND SOUND LIKE CRAP
> I wouldn't use it to to wipe with. you can't even tune
> a pythagorean pentatonic with it

umm ...

-- Pythagorean -- ---- 768edo ----
note 3^x cents degree cents cents deviation

A 3 905.8650026 580 906.25 0.384997404
G 1 701.9550009 449 701.5625 -0.392500865
E 4 407.8200035 261 407.8125 -0.007503462
D 2 203.9100017 131 204.6875 0.777498269
C 0 0 0 0 0

looks pretty darn good to me!

*total* error of only 1 & 9/16 cents.

average error 5/16 of a cent.

and look at that nice "major-3rd"! i defy
anyone to hear the difference between 2^(261/768)
and 81:64. it's only about 1/133 of a cent.

if you played any "pythagorean pentatonic" music
with this 768edo subset, i'm pretty sure that
even hardcore Pythagoreans would love it.
is Margo around?

-monz

🔗Paul Erlich <perlich@aya.yale.edu>

--- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> hi Kraig,
>
>
> > From: "Kraig Grady" <kraiggrady@a...>
[...]
> > 768 IS UNUSABLE, HORRIBLE, AND SOUND LIKE CRAP
> > I wouldn't use it to to wipe with. you can't even tune
> > a pythagorean pentatonic with it
>
>
> umm ...
>
>
> -- Pythagorean -- ---- 768edo ----
> note 3^x cents degree cents cents deviation
>
> A 3 905.8650026 580 906.25 0.384997404
> G 1 701.9550009 449 701.5625 -0.392500865
> E 4 407.8200035 261 407.8125 -0.007503462
> D 2 203.9100017 131 204.6875 0.777498269
> C 0 0 0 0 0
>
>
> looks pretty darn good to me!
>
> *total* error of only 1 & 9/16 cents.
>
> average error 5/16 of a cent.

monz, i don't like the way you calculate errors.

look at the four perfect fifths in your scale and tell me what you
see.

> and look at that nice "major-3rd"! i defy
> anyone to hear the difference between 2^(261/768)
> and 81:64. it's only about 1/133 of a cent.

81:64 doesn't matter. if all four fifths sound good, the 81;64 they
form will be fine whatever it is -- you certainly can't hear the
*beating* between the 81st harmonic of one note and the 64th of the
other!

🔗Paul Erlich <perlich@aya.yale.edu>

🔗monz <monz@attglobal.net>

hi paul,

> From: "Paul Erlich" <perlich@aya.yale.edu>
> To: <tuning@yahoogroups.com>
> Sent: Wednesday, July 09, 2003 12:46 AM
> Subject: [tuning] Re: 768edo de facto tuning standard
>
>
> --- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> > hi Kraig,
> >
> >
> > > From: "Kraig Grady" <kraiggrady@a...>
> [...]
> > > 768 IS UNUSABLE, HORRIBLE, AND SOUND LIKE CRAP
> > > I wouldn't use it to to wipe with. you can't even tune
> > > a pythagorean pentatonic with it
> >
> >
> > umm ...
> >
> >
> > -- Pythagorean -- ---- 768edo ----
> > note 3^x cents degree cents cents deviation
> >
> > A 3 905.8650026 580 906.25 0.384997404
> > G 1 701.9550009 449 701.5625 -0.392500865
> > E 4 407.8200035 261 407.8125 -0.007503462
> > D 2 203.9100017 131 204.6875 0.777498269
> > C 0 0 0 0 0
> >
> >
> > looks pretty darn good to me!
> >
> > *total* error of only 1 & 9/16 cents.
> >
> > average error 5/16 of a cent.
>
> monz, i don't like the way you calculate errors.
>
> look at the four perfect fifths in your scale and tell me what you
> see.
>
> > and look at that nice "major-3rd"! i defy
> > anyone to hear the difference between 2^(261/768)
> > and 81:64. it's only about 1/133 of a cent.
>
> 81:64 doesn't matter. if all four fifths sound good, the 81;64 they
> form will be fine whatever it is -- you certainly can't hear the
> *beating* between the 81st harmonic of one note and the 64th of the
> other!

i *knew* you were going to reply with this, and in
fact had already calculated a "bingo" version and
was almost ready to send it last night before you
sent this post, but for some reason i went to bed first.
here it is:

-------

i didn't bother to consider consistency with
that pythagorean pentatonic i just posted, so
paul will probably mention it. ;-)

here's a nice, consistent 13-tone bingo-card
pythagorean chain of 5ths, where each 5th is
449 degrees of 768edo.

--Pythagorean-- --- 768edo ---
note 3^x cents degree cents cents deviation

D# 6 611.7300052 390 609.375 - 2.355005192
G# 5 1109.775004 709 1107.8125 - 1.962504327
C# 4 407.8200035 260 406.25 - 1.570003462
F# 3 905.8650026 579 904.6875 - 1.177502596
B 2 203.9100017 130 203.125 - 0.785001731
E 1 701.9550009 449 701.5625 - 0.392500865
A 0 0 0 0 0
D -1 498.0449991 319 498.4375 + 0.392500865
G -2 996.0899983 638 996.875 + 0.785001731
C -3 294.1349974 189 295.3125 + 1.177502596
F -4 792.1799965 508 793.75 + 1.570003462
Bb -5 90.22499567 59 92.1875 + 1.962504327
Eb -6 588.2699948 378 590.625 + 2.355005192

D#:Eb gives the 768edo version of the pythagorean comma,
which here is 18.75 cents.

-monz

🔗monz <monz@attglobal.net>

(if viewing this on the Yahoo web interface,
please use "Expand Messages" mode to view correctly
... otherwise the many tables i've put in this
post will look a mess.)

> From: "monz" <monz@attglobal.net>
> To: <tuning@yahoogroups.com>
> Sent: Wednesday, July 09, 2003 8:21 AM
> Subject: Re: [tuning] Re: 768edo de facto tuning standard
>
>
> hi paul,
>
>
> > From: "Paul Erlich" <perlich@aya.yale.edu>
> > To: <tuning@yahoogroups.com>
> > Sent: Wednesday, July 09, 2003 12:46 AM
> > Subject: [tuning] Re: 768edo de facto tuning standard
> >
> >
> > --- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> > > hi Kraig,
> > >
> > >
> > > > From: "Kraig Grady" <kraiggrady@a...>
> > [...]
> > > > 768 IS UNUSABLE, HORRIBLE, AND SOUND LIKE CRAP
> > > > I wouldn't use it to to wipe with. you can't even tune
> > > > a pythagorean pentatonic with it
> > >
> > >
> > > umm ...
> > >
> > >
> > > -- Pythagorean -- ---- 768edo ----
> > > note 3^x cents degree cents cents deviation
> > >
> > > A 3 905.8650026 580 906.25 0.384997404
> > > G 1 701.9550009 449 701.5625 -0.392500865
> > > E 4 407.8200035 261 407.8125 -0.007503462
> > > D 2 203.9100017 131 204.6875 0.777498269
> > > C 0 0 0 0 0
> > >
> > >
> > > looks pretty darn good to me!
> > >
> > > *total* error of only 1 & 9/16 cents.
> > >
> > > average error 5/16 of a cent.
> >
> > monz, i don't like the way you calculate errors.
> >
> > look at the four perfect fifths in your scale and tell me what you
> > see.

but see? ... this makes a point about something
important, which Aaron mentioned in the "MIDI tuning"
thread:

if:

1)
you aren't aware from the start that your final
result will be tuned in 768edo, and

2)
your software isn't sophisticated enough to *round*
the values, rather than simply truncate them by
ignoring the LSB (least significant byte) of the
tuning data stream -- which in fact is how it's
usually done --

... then you're going to end up with those kinds
of inconsistencies.

as an example, let's take a look at the pitch-bend
data i've been using for years to create pythagorean
intonation using Cakewalk on my computer, with the
soundcard which gives only 768edo resolution.
it's in a graphic at the bottom of my old "cawapu" page:

http://sonic-arts.org/dict/cawapu.htm

the numbers here i'm now calling "dodekamus",
abbreviated 12mus. this shows the amount of
pitch-bend i need to use in Cakewalk to produce
the closest 49152edo approximation to a 5-limit
lattice.

if you look along the center row, you'll see the
values which give pythagorean tuning:

0 1 2 3 4 5 6 7 = exponent of 3
0 80 160 240 320 400 480 561 = 12mu correction from 12edo

now below, i'm going to analyze the MIDI data
stream, and we'll see what happens when my 768edo
soundcard ignores the LSB and *truncates* the
pitch-bend data to that resolution, rather than
rounding it to the nearest 6mu (hexamu).

LEGEND:
- "ST" means "12edo Semitone",
- the numbers after that from 13 down to 0 are powers of 2,
- "MSB" and "LSB" mean "most" and "least significant byte",
- "trunc. 12mu" means "truncated dodekamus",

--------- MIDI data stream --------
------ MSB ------- ---- LSB ----- trunc.
ST 13 12 11 10 9 8 7 6 5 4 3 2 1 0 12mu 12mu 6mu 768edo

C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
G 7 0 0 0 0 0 0 0 1 0 1 0 0 0 0 80 0 0 448
D 2 0 0 0 0 0 0 1 0 1 0 0 0 0 0 160 128 1 129
A 9 0 0 0 0 0 0 1 1 1 1 0 0 0 0 240 128 1 577
E 4 0 0 0 0 0 1 0 1 0 0 0 0 0 0 320 256 2 258
B 11 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400 384 3 707
F# 6 0 0 0 0 0 1 1 1 1 0 0 0 0 0 480 384 3 387
C# 1 0 0 0 0 1 0 0 0 1 1 0 0 0 1 561 512 4 68

so, compare *this* pythagorean pentatonic scale with
the one i quoted above.

-- Pythagorean -- ---- 768edo ----
note 3^x cents degree cents cents deviation

A 3 905.8650026 577 901.5625 - 4.302502596
G 1 701.9550009 448 700 - 1.955000865
E 4 407.8200035 258 403.125 - 4.695003462
D 2 203.9100017 129 201.5625 - 2.347501731
C 0 0 0 0 0

pretty lousy, i think.

now of course, as paul pointed out in connection
with my pentatonic scale quoted at the top of this
post, simply rounding off to the *nearest* 768edo
degree will also not give the best results ... but
they *are* better than what i've been getting all
these years from truncation.

anyway, to get a nice, consistent scale out of my
768edo soundcard, i'd be much better off rounding
the Cakewalk 12mu/cawapu values like this:

0 1 2 3 4 = exponent of 3
0 128 256 384 512 = 12mu correction from 12edo

which can be analyzed as follows:

MIDI data stream
------ MSB -------
ST 13 12 11 10 9 8 7 12mu 6mu 768edo

C 0 0 0 0 0 0 0 0 0 0 0
G 7 0 0 0 0 0 0 1 128 1 449
D 2 0 0 0 0 0 1 0 256 2 130
A 9 0 0 0 0 0 1 1 384 3 579
E 4 0 0 0 0 1 0 0 512 4 260

and which results in this:

-- Pythagorean -- ---- 768edo ----
note 3^x cents degree cents cents deviation

E 4 407.8200035 260 406.25 - 1.570003462
A 3 905.8650026 579 904.6875 - 1.177502596
D 2 203.9100017 130 203.125 - 0.785001731
G 1 701.9550009 449 701.5625 - 0.392500865
C 0 0 0 0 0

and which is a subset of the "nice, consistent scale"
which appeared in my other post.

... it looks like our MIDI software ought to be
using some more sophisticated algorithms for the
conversion from one tuning resolution to another.
otherwise, we have to do all this work ourselves.

-monz

🔗monz <monz@attglobal.net>

oops...

near the end of my last post, i wrote:

> From: "monz" <monz@attglobal.net>
> To: <tuning@yahoogroups.com>
> Sent: Wednesday, July 09, 2003 10:29 AM
> Subject: Re: [tuning] Re: 768edo de facto tuning standard
>
>
> <big snip>
>
> anyway, to get a nice, consistent scale out of my
> 768edo soundcard, i'd be much better off rounding
> the Cakewalk 12mu/cawapu values like this:
>
> 0 1 2 3 4 = exponent of 3
> 0 128 256 384 512 = 12mu correction from 12edo
>
>
> which can be analyzed as follows:
>
> MIDI data stream
> ------ MSB -------
> ST 13 12 11 10 9 8 7 12mu 6mu 768edo
>
> C 0 0 0 0 0 0 0 0 0 0 0
> G 7 0 0 0 0 0 0 1 128 1 449
> D 2 0 0 0 0 0 1 0 256 2 130
> A 9 0 0 0 0 0 1 1 384 3 579
> E 4 0 0 0 0 1 0 0 512 4 260
>
>
> and which results in this:
>
> -- Pythagorean -- ---- 768edo ----
> note 3^x cents degree cents cents deviation
>
> E 4 407.8200035 260 406.25 - 1.570003462
> A 3 905.8650026 579 904.6875 - 1.177502596
> D 2 203.9100017 130 203.125 - 0.785001731
> G 1 701.9550009 449 701.5625 - 0.392500865
> C 0 0 0 0 0
>
> and which is a subset of the "nice, consistent scale"
> which appeared in my other post.

for the sake of comparing that pentatonic scale to
the other two, i should have rearranged the order of
the notes in the last table:

-- Pythagorean -- ---- 768edo ----
note 3^x cents degree cents cents deviation

A 3 905.8650026 579 904.6875 - 1.177502596
G 1 701.9550009 449 701.5625 - 0.392500865
E 4 407.8200035 260 406.25 - 1.570003462
D 2 203.9100017 130 203.125 - 0.785001731
C 0 0 0 0 0

-monz

🔗Graham Breed <graham@microtonal.co.uk>

🔗monz <monz@attglobal.net>

----- Original Message -----
From: "Graham Breed" <graham@microtonal.co.uk>
To: <tuning@yahoogroups.com>
Sent: Wednesday, July 09, 2003 11:12 AM
Subject: [tuning] Re: 768edo de facto tuning standard

> monz wrote:
>
> > now of course, as paul pointed out in connection
> > with my pentatonic scale quoted at the top of this
> > post, simply rounding off to the *nearest* 768edo
> > degree will also not give the best results ... but
> > they *are* better than what i've been getting all
> > these years from truncation.
>
> It doesn't matter if you round or truncate, as long as you're consistent.

that's true ... but the point is that, AFAIK,
the truncation that is done by the hardware
doesn't bother to check for intervallic consistency.
it simply lops off the LSB, and those results are
horrible.

here's the interval matrix for the "truncated 768edo"
pythagorean pentatonic example i used in my last post.

(IOW, this is what i've been *getting* on my soundcard,
even when i *thought* i had a nice accurate approximation
to pythagorean.)

768edo degrees are shown next to the letters on
the left and below those at the top. the interval
values within the table are in cents.

C D E G A
0 129 258 448 577
-------+--------------------------------------------------
A 577 | 298.4375 500 701.5625 998.4375 0
G 448 | 500 701.5625 903.125 0 201.5625
E 258 | 796.875 998.4375 0 296.875 498.4375
D 129 | 998.4375 0 201.5625 498.4375 700
C 0 | 0 201.5625 403.125 700 901.5625

you can see that it's not at all consistent, giving
two "perfect 5ths" of 700 cents and two of 701.5625 cents!

the moral of the story: getting microtonal music
out of your electronic instruments to your desired
accuracy requires *even more work* than what i
thought it required, which was already a lot!

-monz

🔗pitchcolor <Pitchcolor@aol.com>

🔗Gene Ward Smith <gwsmith@svpal.org>

🔗Paul Erlich <perlich@aya.yale.edu>

🔗monz <monz@attglobal.net>

hi paul, Graham, and Gene,

> From: "Paul Erlich" <perlich@aya.yale.edu>
> To: <tuning@yahoogroups.com>
> Sent: Wednesday, July 09, 2003 2:41 PM
> Subject: [tuning] Re: 768edo de facto tuning standard
>
>
> --- In tuning@yahoogroups.com, "Gene Ward Smith" <gwsmith@s...> wrote:
> > --- In tuning@yahoogroups.com, Graham Breed <graham@m...> wrote:
> >
> > > It doesn't matter if you round or truncate, as long as
> > > you're consistent.
> >
> > Why do you need to be consistent? 768 can use both 74/768
> > and 75/768 for a secor, but neither is all that terrific.
> > I would think you would do better with some sort of
> > alternation of 75 with 74 hexemus.
>
> this kind of alternation is exactly what i proposed in
> the context of margo schulter's "nanotemperament" thread,
> if you look back in the archives.

and this kind of alternation is pretty much what i
proposed in my original 768edo pythagorean pentatonic,
where C:G was 449 degrees, G:D was 450, and D:A was 449
again. however, A:E was also 449, so it wasn't strict
alternation. but alternation like that will still
gives two different sizes for each interval.

> but i think graham was speaking of a poor-man's
> approach to rendering a set of exact pitches of
> unknown source and intent -- in that case, he's
> right that one can either round or truncate (that
> is, use the floor function), but as long as one
> consistently uses one or the other, the resulting
> distribution of errors will be approximately the
> same -- the pitch of one will simply be, on average,
> half a unit higher than the pitch of the other!

hmm ... i understood Graham's comment different,
to mean consistent in the sense of your definition
of consistency as a tuning term. Graham?

-monz

🔗Graham Breed <graham@microtonal.co.uk>

monz wrote:

> hmm ... i understood Graham's comment different,
> to mean consistent in the sense of your definition
> of consistency as a tuning term. Graham?

No, Paul got it right. I thought about this when I was working on MIDI Relay -- should there be an option for pre-rounding to the devices effective resolution? I came to the conclusion that it doesn't matter. The only problem would be if you set the tonic as 0 pitch bend, so an important interval is more likely to be almost a whole tuning step out. Use a random tonic, and all is well.

There are ways you can construct consistent temperaments around the resolution. Like 384-equal makes quite a good meantone, and I used to tune my TX81Z to it. But I eventually decided that this doesn't really matter either. Tunings sound roughly like what they're supposed to, and the effective resolution isn't usually published anyway. After all, this fuss started with controlled experiments, not somebody's subjective reaction to retuned music.

I tested an AWE soundcard once, and found it was using all bits of the pitch bends, but only tuning in cent steps, and not accurately to that. The old Soundblaster FM tuning works with a certain number of equal frequency steps to each octave. You can probably find the details online. So you could probably find a set of pitch bends that give exact just intonation. But you wouldn't really want to, because it'll still be a shitty little synth and you could use CSound or some other soft synth to get better results with less trouble.

I'll look at Timidity sometime and get it to use full keyboard tunings. In the process, I'll no doubt discover what its resolution is. Currently, it won't compile because it can't find a file called stdint.h, which seems to be part of mingw.

Graham

🔗pitchcolor <Pitchcolor@aol.com>

🔗Paul Erlich <perlich@aya.yale.edu>

--- In tuning@yahoogroups.com, "pitchcolor" <Pitchcolor@a...> wrote:
> Hi Graham,
>
> > I thought about this when I was working on MIDI
> > Relay -- should there be an option for pre-rounding to the
> devices
> > effective resolution? I came to the conclusion that it doesn't
> matter.
> > The only problem would be if you set the tonic as 0 pitch
> bend, so an
> > important interval is more likely to be almost a whole tuning
> step out.
>
> This is exactly why rounding makes a difference in this case.
> Even if the 'distribution of errors' ends up being about the same
> whether one uses trucating and rounding, the placements of the
> errors makes all the difference here. Why would one want to
> equate a false mapping resulting from truncation with a true
> mapping resulting from rounding?

this last sentence carries no meaning for me. "true"? "false"?

> They are not equally
> desirable. Moving from fine to coarse resolution always requires
> rounding if you want a true mapping.
>
> Aaron

"true"?

if one wanted to use a single priviledged tonic in one's music and
felt that the intervals it participates in are the most important
ones to accurately represent, one could simply set the tonic
initially to be half a pitch bend unit high, and construct the scale
from there. then truncation will produce exactly the same results as
rounding from a basis of tonic=0. for the example in question,
pythagorean tuning, what matters are not the intervals from a given
fixed tonic, but rather all of the perfect fifths, and possibly the
major ninths, in the chain (unless one wanted to use the tuning very
unidiomatically) . . . so graham's initial comment still strikes me
as correct in the context in which it was issued.

🔗Paul Erlich <perlich@aya.yale.edu>

--- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> hi paul,
>
>
> > From: "Paul Erlich" <perlich@a...>
> > To: <tuning@yahoogroups.com>
> > Sent: Wednesday, July 09, 2003 12:46 AM
> > Subject: [tuning] Re: 768edo de facto tuning standard
> >
> >
> > --- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> > > hi Kraig,
> > >
> > >
> > > > From: "Kraig Grady" <kraiggrady@a...>
> > [...]
> > > > 768 IS UNUSABLE, HORRIBLE, AND SOUND LIKE CRAP
> > > > I wouldn't use it to to wipe with. you can't even tune
> > > > a pythagorean pentatonic with it
> > >
> > >
> > > umm ...
> > >
> > >
> > > -- Pythagorean -- ---- 768edo ----
> > > note 3^x cents degree cents cents deviation
> > >
> > > A 3 905.8650026 580 906.25 0.384997404
> > > G 1 701.9550009 449 701.5625 -0.392500865
> > > E 4 407.8200035 261 407.8125 -0.007503462
> > > D 2 203.9100017 131 204.6875 0.777498269
> > > C 0 0 0 0 0
> > >
> > >
> > > looks pretty darn good to me!
> > >
> > > *total* error of only 1 & 9/16 cents.
> > >
> > > average error 5/16 of a cent.
> >
> > monz, i don't like the way you calculate errors.
> >
> > look at the four perfect fifths in your scale and tell me what
you
> > see.
> >
> > > and look at that nice "major-3rd"! i defy
> > > anyone to hear the difference between 2^(261/768)
> > > and 81:64. it's only about 1/133 of a cent.
> >
> > 81:64 doesn't matter. if all four fifths sound good, the 81;64
they
> > form will be fine whatever it is -- you certainly can't hear the
> > *beating* between the 81st harmonic of one note and the 64th of
the
> > other!
>
>
>
> i *knew* you were going to reply with this, and in
> fact had already calculated a "bingo" version and
> was almost ready to send it last night before you
> sent this post, but for some reason i went to bed first.
> here it is:
>
> -------
>
>
> i didn't bother to consider consistency with
> that pythagorean pentatonic i just posted, so
> paul will probably mention it. ;-)
>
>
> here's a nice, consistent 13-tone bingo-card
> pythagorean chain of 5ths,

monz, "consistency" is not what i was getting at here -- and btw this
is a different definition of "consistency" anyhow than the one
usually associated with me (which concerns whether approximations to
simple ratios add up as expected to approximations to other simple
ratios). but as you should know from my contributions to
the "nanotemperament" thread, i would certainly never insist that all
the like intervals in an intended scale be implemented with the same
number of units of synthesizer resolution -- in particular, i
recommended implementing meantone with two different sizes of fifth,
so that all the thirds and sixths end up more accurate than would be
possible with a single, "consistent" size of fifth.

what i was getting at (note that my comment was simply "monz, i don't
like the way you calculate errors") is that the relevant errors to
measure are the deviations from the simple-whole-number-ratio
*intervals*, wherever they may occur in the scale, rather than the
deviations from the (often complex-ratio) *pitches*. or, in other
words, you're looking at the deviations in all the intervals, simple-
ratio and otherwise, formed with an arbitrarily chosen *tonic*, and
no other intervals -- while i'd only be concerned with the deviations
in the intervals that one can possibly hope to tune by ear anyway (so
the p5s/p4s and possibly the M9s/M2s depending on timbre), but i'd
look at all of them whether they occured against the "tonic" or
between any other pair of pitches. other, more complex-ratio
intervals, whether they occur against the tonic or otherwise, are of
little interest to me error-wise, because they don't sound "just" to
begin with, so any deviation will simply change the size of the
interval slightly, without damaging consonance at all.

🔗Joseph Pehrson <jpehrson@rcn.com>

--- In tuning@yahoogroups.com, "Paul Erlich" <perlich@a...> wrote:

/tuning/topicId_45398.html#45403

> --- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> > hi Kraig,
> >
> >
> > > From: "Kraig Grady" <kraiggrady@a...>
> [...]
> > > 768 IS UNUSABLE, HORRIBLE, AND SOUND LIKE CRAP
> > > I wouldn't use it to to wipe with. you can't even tune
> > > a pythagorean pentatonic with it
> >
> >
> > umm ...
> >
> >
> > -- Pythagorean -- ---- 768edo ----
> > note 3^x cents degree cents cents deviation
> >
> > A 3 905.8650026 580 906.25 0.384997404
> > G 1 701.9550009 449 701.5625 -0.392500865
> > E 4 407.8200035 261 407.8125 -0.007503462
> > D 2 203.9100017 131 204.6875 0.777498269
> > C 0 0 0 0 0
> >
> >
> > looks pretty darn good to me!
> >
> > *total* error of only 1 & 9/16 cents.
> >
> > average error 5/16 of a cent.
>
> monz, i don't like the way you calculate errors.
>
> look at the four perfect fifths in your scale and tell me what you
> see.
>
> > and look at that nice "major-3rd"! i defy
> > anyone to hear the difference between 2^(261/768)
> > and 81:64. it's only about 1/133 of a cent.
>
> 81:64 doesn't matter. if all four fifths sound good, the 81;64 they
> form will be fine whatever it is -- you certainly can't hear the
> *beating* between the 81st harmonic of one note and the 64th of the
> other!

***So how *is* one supposed to calculate these errors?? (I guess the
plot is thickening now, and I should wait fully for
the "denouement..." :)

J. Pehrson

🔗pitchcolor <Pitchcolor@aol.com>

Hi Paul,

> > Even if the 'distribution of errors' ends up being about the
same
> > whether one uses trucating and rounding, the placements of
the
> > errors makes all the difference here. Why would one want to
> > equate a false mapping resulting from truncation with a true
> > mapping resulting from rounding?
>
> this last sentence carries no meaning for me. "true"? "false"?
>
> > They are not equally
> > desirable. Moving from fine to coarse resolution always
requires
> > rounding if you want a true mapping.
> >
> > Aaron
>
> "true"?
>
> if one wanted to use a single priviledged tonic in one's music
and
> felt that the intervals it participates in are the most important
> ones to accurately represent, one could simply set the tonic
> initially to be half a pitch bend unit high, and construct the scale
> from there. then truncation will produce exactly the same
results as
> rounding from a basis of tonic=0. for the example in question,
> pythagorean tuning, what matters are not the intervals from a
given
> fixed tonic, but rather all of the perfect fifths, and possibly the
> major ninths, in the chain (unless one wanted to use the
tuning very
> unidiomatically) . . . so graham's initial comment still strikes
me
> as correct in the context in which it was issued.

I was using the words 'true' and 'false' to refer to a retention or
loss of precision. If we map a fine resolution to a coarse
resolution, we must round the mapping to maintain precision. If
we want to manipulate intervals by linear addition and
subtraction as mapped in the coarse resolution, the precision
matters a lot. No matter what we do we have errors, but when we
round, the errors are not as great as when we truncate. I'm sure
you know this. It isn't a matter of 'overall error' it's a matter of
specific errors for specific values, mapped with greater or lesser
precision.

http://www.angelfire.com/oh/cmulliss/round7.html

Aaron

768edo de facto tuning standard

🔗Kraig Grady <kraiggrady@anaphoria.com>

🔗Gene Ward Smith <gwsmith@svpal.org>

🔗monz <monz@attglobal.net>

🔗Paul Erlich <perlich@aya.yale.edu>

🔗Paul Erlich <perlich@aya.yale.edu>

🔗monz <monz@attglobal.net>

🔗monz <monz@attglobal.net>

🔗monz <monz@attglobal.net>

🔗Graham Breed <graham@microtonal.co.uk>

🔗monz <monz@attglobal.net>

🔗pitchcolor <Pitchcolor@aol.com>

🔗pitchcolor <Pitchcolor@aol.com>

🔗pitchcolor <Pitchcolor@aol.com>

🔗pitchcolor <Pitchcolor@aol.com>

🔗Gene Ward Smith <gwsmith@svpal.org>

🔗Paul Erlich <perlich@aya.yale.edu>

🔗monz <monz@attglobal.net>

🔗Graham Breed <graham@microtonal.co.uk>

🔗pitchcolor <Pitchcolor@aol.com>

🔗Paul Erlich <perlich@aya.yale.edu>

🔗Paul Erlich <perlich@aya.yale.edu>

🔗Joseph Pehrson <jpehrson@rcn.com>

🔗pitchcolor <Pitchcolor@aol.com>

🔗Graham Breed <graham@microtonal.co.uk>