Yahoo Tuning Groups Ultimate Backup tuning Carl's listening example request

Here's the gammatone filter plots:

http://www.mikebattagliamusic.com/music/gammafirstwithbuzz.png
http://www.mikebattagliamusic.com/music/gammasecondnobuzz.png
http://www.mikebattagliamusic.com/music/gammathirdnobuzz.png
http://www.mikebattagliamusic.com/music/gammafourthslightbuzz.png

This is with another random set of four, which sounds kind of similar
to the first set. Here's the picture of the waveforms:

http://www.mikebattagliamusic.com/music/567buzztest2.png

And the wav file:

http://www.mikebattagliamusic.com/music/567buzztest2.wav

This categorically proves that critical band roughness is involved.
No, just kidding, I only said that to annoy Carl. But although the
cochlea doesn't really consist of actual gammatone filters, it's still
true that the cochlea follows this general pattern: quicker damping up
top, slower damping on the bottom. Thus this graph will look pretty
much the same even if you ditch the crude "gammatone" approximation
and put in a much better representation of the impulse response of the
auditory filter of the ear, so useful information can be gleaned out
of this nonetheless.

It appears that when you jump to a mixed time-frequency representation
like this, playing 5:6:7 at the same time doesn't actually turn into
activation at 5, 6, and 7 uniformly throughout the length of the
period. Rather, the harmonics vary in where they are localized
-within- the period, which is what I had predicted in the other
thread. In this case, it looks like when 5, 6, and 7 are all aligned,
you get more "buzz." When they aren't, you get less buzz. If we were
using a single-resolution time-frequency plot, however, such as a
common spectrogram/the STFT, you wouldn't see this - you'd see a
uniform activation of 5, 6, and 7 throughout the signal.

So periodicity buzz in real life instruments, then, presumably has
something to do with random phases from the notes involved aligning to
cause this sort of thing to happen.

And for the record, this is why I said that beating, roughness, and
periodicity buzz were all related to the same thing. Although we don't
usually think of 5:6:7 as falling within a critical band, the
frequencies are close enough to get slightly trapped in one another's
auditory filter, which in a time-frequency plot leads to the above
phenomenon.

-Mike

🔗Michael <djtrancendance@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

On Sun, Jan 16, 2011 at 3:55 AM, Carl Lumma <carl@...> wrote:
>
> > So this proves categorically that periodicity buzz is yet
> > another type of consonance, not related to the VF mechanism.
>
> How so?

Because the VF doesn't change, but the buzz does. The same also
applies when the sounds are split between the two ears.

> Mike, check out this paper:
> http://cercor.oxfordjournals.org/content/13/7/765.full
>
> It conclusively demonstrates my assertion that the cochlea
> has nothing to do with it. No, not quite, I just said that
> to annoy you. However we should definitely procure some
> of these RI sounds... -Carl

The RI sounds are what we've been working with - they're periodic
noise. See here:

> The RI sound was constructed by delaying a sample of random noise by 8 ms (1/125 Hz), adding it back to the original noise and iterating the process 16 times.

Go back to the other listening example thread and you'll see that's
what I did. The three techniques I used were to play an impulse train
by itself, to play an impulse train convolved with a parabola, and to
play an impulse train convolved with noise. Impulse train convolved
with noise = superimposing another copy of the noise signal at each
impulse. The listening test I just did here was an RI sound as applied
to just three sine waves instead of an impulse train. So I guess it
really has been talked about in the psychoacoustics literature then.

Note that in the case of the impulse train, the timbre of the sound
actually does change between the impulse train and the noise - so I
guess the VF mechanism might really be involved. However, if the
cochlea were involved, it would still lead to the same behavior - if
harmonics are jumping in and out of existence really fast, then the
resultant timbre that the VF mechanism generates would be changing
really fast.

The gammatone plots I made should apply decently well to any mixed
time-frequency resolution plot, or any filterbank where damping
changes with respect to frequency - they will all exhibit a similar
behavior in which harmonics are localizes. So if the VF mechanism can
be represented as a filterbank doing the same thing, then the same
behavior would apply up there.

I actually suggested this myself when I talked about the impulse
response decaying in the VF filterbank a while ago - that was the
time-domain equivalent of the same principle. You then turned it
around and proved that this wasn't the case because the buzz
disappears when the signal is dispersed between the two ears. Now
we've switched sides.

I'll have to delve further into this paper later.

-Mike

🔗Michael <djtrancendance@...>

Via Gene's suggestion...I finally attempted a multi-threaded program which
uses pre-calculated dyad tables in all the possible dyads in 31TET to find the
"best" 12-tone scales within 31TET far as number of pure dyads within a
user-specified odd-limit.

Granted it analyzes all possible dyads for around 54 million 12-tone scale
combinations in 31TET so it takes a while... But still...you can make a list of
dyads with it (IE click on "add all 3,5,7,9,11,13,or15-limit") to a list and
then click "calculate scale with most dyads in this tuning" and it will find the
"best" 12-tone dyadic scale for you within, say, 10-15 minutes.

I'm pretty sure the code is mathematically accurate IE that it does not miss
any dyads in its calculations...though I'm still robustness testing it.
----------------------------------------
Just for grins...here's the best scale so far it as come up with under 31TET
for including both 3 and 5-odd-limit ratios (index 0 is assumed to be the root
tone):

"ultimate" 3-5 odd limit dyad 12 tone scale under 31TET
0 8 10 11 13 15 16 18 19 21 23 29
---------------------------------------
This is a 12-tone scale within 31TET with 53 3 to 5-odd-limit dyads within 8
cents of perfect. Though the fact the scale includes a 1/4-tone-ish interval
between scale steps 10 and 11, 15 and 16....plus the resulting scale's looking
very little like mean-tone all strike me as a bit odd...

I also believe 72 would be the ultimate number of 5-limit dyads in a scale as
there appear to me to be 6 dyads within 3 and 5 limit and 12 possible root tones
IE 12 * 6 = 72. Still, 53 of 72 is not too bad...

Can any of you think of a 12-tone scale under 31TET with better results far
as number of 5-or-less-odd-limit dyad? If so...guess I need to do more quality
checking on the code...

For those interested in where the dyads where found in said scale, here is
a table

(note: indexes 0 to 30 are on the first octave and 31+ are on the second
octave):

good dyad from 0 to 8 of 1.195873
<and> good dyad from 0 to 10 of 1.250565
<and> good dyad from 0 to 13 of 1.337329
<and> good dyad from 0 to 18 of 1.495517
<and> good dyad from 0 to 21 of 1.599275
<and> good dyad from 0 to 23 of 1.672416
<and> good dyad from 0 to 21 of 1.599275
<and> good dyad from 0 to 23 of 1.672416
<and> good dyad from 8 to 16 of 1.195873
<and> good dyad from 8 to 18 of 1.250565
<and> good dyad from 8 to 21 of 1.337329
<and> good dyad from 8 to 29 of 1.599275
<and> good dyad from 8 to 31 of 1.672419
<and> good dyad from 8 to 21 of 1.337329
<and> good dyad from 8 to 31 of 1.672419
<and> good dyad from 10 to 18 of 1.195873
<and> good dyad from 10 to 23 of 1.337328
<and> good dyad from 10 to 31 of 1.599277
<and> good dyad from 10 to 23 of 1.337328
<and> good dyad from 10 to 31 of 1.599277
<and> good dyad from 10 to 33 of 1.672419
<and> good dyad from 11 to 19 of 1.195873
<and> good dyad from 11 to 21 of 1.250565
<and> good dyad from 11 to 29 of 1.495516
<and> good dyad from 11 to 21 of 1.250565
<and> good dyad from 13 to 21 of 1.195873
<and> good dyad from 13 to 23 of 1.250565
<and> good dyad from 13 to 31 of 1.495519
<and> good dyad from 13 to 21 of 1.195873
<and> good dyad from 13 to 23 of 1.250565
<and> good dyad from 13 to 31 of 1.495519
<and> good dyad from 15 to 23 of 1.195873
<and> good dyad from 15 to 23 of 1.195873
<and> good dyad from 15 to 33 of 1.495519
<and> good dyad from 16 to 29 of 1.337328
<and> good dyad from 16 to 37 of 1.599277
<and> good dyad from 16 to 39 of 1.672419
<and> good dyad from 18 to 31 of 1.337331
<and> good dyad from 18 to 31 of 1.337331
<and> good dyad from 18 to 39 of 1.599277
<and> good dyad from 19 to 29 of 1.250565
<and> good dyad from 19 to 27 of 1.195873
<and> good dyad from 19 to 37 of 1.495519
<and> good dyad from 21 to 29 of 1.195873
<and> good dyad from 21 to 31 of 1.250567
<and> good dyad from 21 to 31 of 1.250567
<and> good dyad from 21 to 39 of 1.495519
<and> good dyad from 23 to 31 of 1.195875
<and> good dyad from 23 to 31 of 1.195875
<and> good dyad from 23 to 33 of 1.250567
<and> good dyad from 29 to 37 of 1.195875
<and> good dyad from 29 to 39 of 1.250567
<and> good dyad from 29 to 47 of 1.495519

🔗Michael <djtrancendance@...>

In addition to my last post about my program's results for 5-or-less-limit
dyads.......

Results from that program are also in for 12-tone scale with most 7-or-less
limit dyads under the 31TET tuning.

That 12-tone scale under 31TET is
---------------------

0 6 7 8 10 11 13 14 15 16 17 23

-------------------

The dyad results/list for that scale are

good dyad from 0 to 6 of 1.143573
<and> good dyad from 0 to 7 of 1.16943
<and> good dyad from 0 to 8 of 1.195873
<and> good dyad from 0 to 10 of 1.250565
<and> good dyad from 0 to 13 of 1.337329
<and> good dyad from 0 to 15 of 1.39849
<and> good dyad from 0 to 16 of 1.430112
<and> good dyad from 0 to 23 of 1.672416
<and> good dyad from 0 to 13 of 1.337329
<and> good dyad from 0 to 15 of 1.39849
<and> good dyad from 0 to 21 of 1.599275
<and> good dyad from 0 to 23 of 1.672416
<and> good dyad from 6 to 13 of 1.16943
<and> good dyad from 6 to 14 of 1.195873
<and> good dyad from 6 to 16 of 1.250565
<and> good dyad from 6 to 31 of 1.748905
<and> good dyad from 6 to 13 of 1.16943
<and> good dyad from 6 to 21 of 1.39849
<and> good dyad from 6 to 27 of 1.599275
<and> good dyad from 6 to 29 of 1.672416
<and> good dyad from 6 to 31 of 1.748905
<and> good dyad from 7 to 13 of 1.143573
<and> good dyad from 7 to 14 of 1.16943
<and> good dyad from 7 to 15 of 1.195873
<and> good dyad from 7 to 17 of 1.250565
<and> good dyad from 7 to 23 of 1.430112
<and> good dyad from 7 to 31 of 1.710234
<and> good dyad from 7 to 13 of 1.143573
<and> good dyad from 7 to 15 of 1.195873
<and> good dyad from 7 to 17 of 1.250565
<and> good dyad from 7 to 23 of 1.430112
<and> good dyad from 7 to 31 of 1.710234
<and> good dyad from 8 to 14 of 1.143573
<and> good dyad from 8 to 15 of 1.16943
<and> good dyad from 8 to 16 of 1.195873
<and> good dyad from 8 to 23 of 1.39849
<and> good dyad from 8 to 31 of 1.672419
<and> good dyad from 8 to 15 of 1.16943
<and> good dyad from 8 to 21 of 1.337329
<and> good dyad from 8 to 23 of 1.39849
<and> good dyad from 8 to 29 of 1.599275
<and> good dyad from 8 to 31 of 1.672419
<and> good dyad from 8 to 33 of 1.748905
<and> good dyad from 10 to 16 of 1.143573
<and> good dyad from 10 to 17 of 1.16943
<and> good dyad from 10 to 23 of 1.337328
<and> good dyad from 10 to 31 of 1.599277
<and> good dyad from 10 to 17 of 1.16943
<and> good dyad from 10 to 23 of 1.337328
<and> good dyad from 10 to 31 of 1.599277
<and> good dyad from 10 to 33 of 1.672419
<and> good dyad from 10 to 35 of 1.748905
<and> good dyad from 11 to 17 of 1.143573
<and> good dyad from 11 to 17 of 1.143573
<and> good dyad from 11 to 21 of 1.250565
<and> good dyad from 11 to 27 of 1.430112
<and> good dyad from 11 to 29 of 1.495516
<and> good dyad from 11 to 35 of 1.710234
<and> good dyad from 13 to 23 of 1.250565
<and> good dyad from 13 to 31 of 1.495519
<and> good dyad from 13 to 21 of 1.195873
<and> good dyad from 13 to 23 of 1.250565
<and> good dyad from 13 to 29 of 1.430112
<and> good dyad from 13 to 31 of 1.495519
<and> good dyad from 14 to 21 of 1.16943
<and> good dyad from 14 to 27 of 1.337328
<and> good dyad from 14 to 29 of 1.39849
<and> good dyad from 14 to 35 of 1.599277
<and> good dyad from 15 to 23 of 1.195873
<and> good dyad from 15 to 31 of 1.430114
<and> good dyad from 15 to 21 of 1.143573
<and> good dyad from 15 to 23 of 1.195873
<and> good dyad from 15 to 31 of 1.430114
<and> good dyad from 15 to 33 of 1.495519
<and> good dyad from 16 to 23 of 1.16943
<and> good dyad from 16 to 31 of 1.398492
<and> good dyad from 16 to 23 of 1.16943
<and> good dyad from 16 to 29 of 1.337328
<and> good dyad from 16 to 31 of 1.398492
<and> good dyad from 17 to 23 of 1.143573
<and> good dyad from 17 to 23 of 1.143573
<and> good dyad from 17 to 27 of 1.250565
<and> good dyad from 17 to 33 of 1.430114
<and> good dyad from 17 to 35 of 1.495519
<and> good dyad from 23 to 31 of 1.195875
<and> good dyad from 23 to 29 of 1.143573
<and> good dyad from 23 to 31 of 1.195875
<and> good dyad from 23 to 33 of 1.250567
<and> good dyad from 23 to 47 of 1.710234

🔗Michael <djtrancendance@...>

In addition to my last post about my program's results for 5-or-less-limit
dyads.......

Results from that program are also in for 12-tone scale with most 7-or-less
limit dyads under the 31TET tuning.

That 12-tone scale under 31TET is
---------------------

0 6 7 8 10 11 13 14 15 16 17 23

-------------------
>>>There are 89 dyads within 8 cents of 7-or-less-limit dyads<<<< (forgot to post
>>>this last message)
The dyad results/list for that scale are

________________________________

In addition to my last post about my program's results for 5-or-less-limit
dyads.......

Results from that program are also in for 12-tone scale with most 7-or-less
limit dyads under the 31TET tuning.

That 12-tone scale under 31TET is
---------------------

0 6 7 8 10 11 13 14 15 16 17 23

-------------------

The dyad results/list for that scale are

🔗genewardsmith <genewardsmith@...>

🔗Michael <djtrancendance@...>

Ok, found a fairly major bug in the program concerning how it counted (or
rather, neglected to count) some of the octave-equivalent IE "across octaves"
dyads and re-ran it.

Here are the best scales it gave for a 12-tone scale under 31TET for......

0 2 5 7 10 12 15 18 20 23 25 28 - 3 and 5-limit (56 "good" dyads)

0 3 5 8 10 13 15 18 21 23 26 28 - 3,5,7-limit (78 "good" dyads..well spaced)
0 5 6 7 8 13 14 15 21 23 29 30 - 3,5,7-limit (80 "good" dyads - badly spaced)
0 3 5 8 10 13 15 18 21 23 26 28 - 3,5,7,9-limit (92 good dyads, well
spaced...same scale as for up to 7-limit)
0 2 5 7 10 12 15 18 20 23 25 28 - 3,5,7,9-limit (92 good dyads, well
spaced...same scale as for up to 5-limit)
0 1 2 7 8 9 15 16 17 23 24 25 - 3,5,7,9,11-limit (101 "good" dyads - badly
spaced)

-----scales from my preferred dyad sets----------------
0 3 5 8 10 13 15 18 21 23 26 28 - 3,5,7,9 limit plus 22/15 fifth from favorites
list allowed (99 good dyads...well spaced)
0 2 5 7 10 12 15 18 20 23 25 28 - - 3,5,7,9 limit plus 22/15...same as 3,5-limit
scale (99 good dyads...well spaced)
0 3 5 6 8 13 16 19 21 23 26 29 - Favorite list (86 "good" dyads...well
spaced)

All in all....the 5-limit scale seems to have the most good dyads out of
anything across almost all limits except including 11-limit. Plus it looks
peculiarly (no surprise) like the 31TET approximation of quarter comma mean-tone
even at a glance...and I can swear it is that scale with the looping 5th at
position 18 in the scale.

🔗Michael <djtrancendance@...>

Gene>"Again, the count has to be an even number."

How come? I'm guessing that's because all inversions must also be within
the octave IE 2/(5/4) = 8/5? There might be an index off by one somewhere.

I also noticed...I always get even numbers with 3,5,7-limit calculations.
It's those 9-limit+ ones where it gives odd-numbered results...might have
something to do with multiple dyads being too near the same area IE 16/9 and
11/6 being almost exactly the same distance from the nearest 31TET note.

Again look at the last scale list I got from the most updated version of the
code...

0 2 5 7 10 12 15 18 20 23 25 28 - 3 and 5-limit (56 "good" dyads)

...only the 9-limit+ scales come up with odd numbers like 99 and
101.................

🔗genewardsmith <genewardsmith@...>

🔗Michael <djtrancendance@...>

> Gene>"Again, the count has to be an even number."
>
Me> How come?
Gene>Every interval less than 600 cents is paired with another greater than 600
cents. Unless your target interval list contains 600 cents, the dyad count will
be even. Since 31 is an odd number, this can't happen.

Ok, I fixed it and now it gets only even numbers. :-)

There were a few weird cases where the accuracy was a bit off and, for
example, 6/5 was put in the good list of intervals approximated well by 31TET,
but 5/3 was sometimes not.

So here are new/fixed result scales for

5,7,9, and 11-limit: 0 3 4 6 10 12 13 19 21 25 27 28 (92 good dyads, good
spacing)
0 1 2 7 8 9 15 16 17 23 24 25 (94 good
dyads, bad spacing)
5,7, and 9-limit: 0 3 5 8 10 13 15 18 21 23 26 28 (78 good dyads,
good spacing)
0 1 2 3 8 9 10 16 18 24 25 26 (80 good
dyads, bad spacing)

Funny, the one the program came up for in the up to 11-limit case doesn't
look unlike a mode from my Dimension tuning rounded to 31TET...can you confirm
if that is the case?

One other thing....31TET seems to be no champion at 9-limit...the results it
gets for the best scales in 9 or under limit are exactly the same ones it gets
under 7-or-under limit....
----------------------------------------
Note: I might re-work the code not to handle "across octave dyads" for speed
at least when making scales from subsets of TET tunings (since you seem to say
considering/calculating dyads that from from notes under 2/1 to over 2/1 are
redundant)...but other than that the code seems to be working....
A few caveats....suppose one person likes the dyad of 27/20 but does not like
the octave inverse of 40/27 and thus wants to count the 27/20 on his "desired
list" but forgot about the resulting 40/27 from the presence of the octave. Or
what if the tuning is a stretched or otherwise non-octave tuning....or the input
scale is not equally tempered. Would handling any of these situations require
considering "across octave" dyads?

🔗Michael <djtrancendance@...>

Gene>"Why do you say 8 cents? 31 gets the 5-limit to within 6 cents."
Versatility toward new features in the future was/is my reasoning. :-)

Don't get me wrong, I made this program to solve the 12-tone scales in 31TET
problem you posted.

However...I also built it with the idea of expanding things like non-TET tunings
(including irregularly tempered tunings). I also built the program to handle
TET tunings of any size (up to about 200) in mind...realizing many of them don't
have so much accuracy as 31TET and that over 8 cents, I've found, is usually
where my ears start complaining something is "off", regardless of what tuning is
used.

>"Also, the inverted version of this scale gives the same dyad count. Did it
>appear when you ran the program?"

No, my program only holds and displays one "mode" at once, and only swaps
the screen contents when it finds something with a higher dyad count IE if the
highest dyad count is 24 and a new scale it just calculated has 24...it will
only display the old scale. If it's really essential...I can add a feature that
rotates the mode to its "lowest hash value" using your system once scale
processing is done...but I fear the program will be too slow if I try doing that
real-time.
Oddly enough, I've found every time you concatenate new scale contents to a
string for user interface display in the innermost loop of the code (the one
where the dyads are compared)...it slows the code a whole lot. Meaning...by 5+
times as much! That can be the difference between waiting an hour for scale
processing and waiting 10 minutes (and that's with processing split onto two
independent threads)...

My rule of thumb so far...only use arrays in the inner loops of code and
compare dyads from arrays with pre-calculated values IE an array with all
possible dyads under 31TET with zeroes representing dyads not within the user's
desired dyad list. That and don't use strings or Microsoft "arraylists'...which
are both painfully slow.

🔗genewardsmith <genewardsmith@...>

--- In tuning@yahoogroups.com, Michael <djtrancendance@...> wrote:
>
> Gene>"Why do you say 8 cents? 31 gets the 5-limit to within 6 cents."
> Versatility toward new features in the future was/is my reasoning. :-)

It seems to me that this isn't versatile. If you gave the program the target list of n-edo intervals between 0 < i < n in the form of a list of integers you want it to check for, that would be more versatile. I suspect you are tossing out 5\31 as a 9-limit consonance, which makes sense but it isn't the "offical" 9-limit. Running it both and without {5\31, 26\31} would make sense.

The idea is that to do the 5-limit, you should just feed your program the set {8, 10, 13, 18, 21, 23}. For the 7-limit, you would feed it {6, 7, 8, 10, 13l 15, 16, 18, 21, 23, 24, 25}. To get the 9-limit, you would add {5, 11, 20, 26} to the 7-limit, and for the 11-limit, you'd add {4, 9, 14, 17, 22, 27}. You could add or subtract intervals from these lists, of course, but it would be nice to get the winners for the full 9 and 11 limits.

> Don't get me wrong, I made this program to solve the 12-tone scales in 31TET
> problem you posted.
>
> However...I also built it with the idea of expanding things like non-TET tunings
> (including irregularly tempered tunings).

Not a bad idea, but I'd like to see results from a program which works for equal divisions and any list of targets, and specifically tonality diamond targets, first.

I also built the program to handle
> TET tunings of any size (up to about 200) in mind...realizing many of them don't
> have so much accuracy as 31TET and that over 8 cents, I've found, is usually
> where my ears start complaining something is "off", regardless of what tuning is
> used.

I'd say to start out with forget about your ears and go with the results of what the edo mapping (the val) gives you.

> If it's really essential...I can add a feature that
> rotates the mode to its "lowest hash value" using your system once scale
> processing is done...but I fear the program will be too slow if I try doing that
> real-time.

I'm not worried about modes; the point is you are missing actually distinct scales.

🔗genewardsmith <genewardsmith@...>

🔗Michael <djtrancendance@...>

Gene>"It seems to me that this isn't versatile. If you gave the program the
target list of n-edo intervals between 0 < i < n in the form of a list of
integers you want it to check for, that would be more versatile."

What do you mean by "target list of n-edo intervals"...only the
x-specified limit intervals that exist within the TET tuning? Are you saying
you should be able to pick a number like 4 and have the program come up with any
approximations of 5/4, 4/3, 6/4 7/4...within the EDO? Sounds kind of odd....

Right now the system lets you pick a prime number, click "add", and then
all fractions with an odd-limit of that prime numbers are added onto on your
list (I thought that's what you asked for in the first place anyhow). :-S
Plus, you can delete any of those fractions from the list you don't like
before running the calculations.
One missing feature...the abilityadd custom fractions not included within
15-odd-limit to the list.
Of course, the program checks all fractions and deletes and dyads in the
list NOT approximated well by the current tuning and stores the results in
arrays before doing any calculations done in scale-creation loops (hence the
program's stress on "pre-calculation")

-------------------------------------------
The point of "versatility" is that this is meant to be an "all types of
tuning" program...and not made to only handle TET type tunings.

-------------------------------------------
Me>I also built the program to handle TET tunings of any size (up to about 200)
in mind...realizing many of >them don't have so much accuracy as 31TET and that
over 8 cents, I've found, is usually

> where my ears start complaining something is "off", regardless of what tuning
>is
>
> used.

Gene>"I'd say to start out with forget about your ears and go with the results
of what the edo mapping (the val) gives you."

Which would mean
1) if the user, say, specified 5/3 and the closest thing in the TET (assuming
I'm not in 31TET in the future) was 17/10 I should go with that? If I just grab
the closest dyad in the mapping....I'm afraid I may end up giving credit for
dyads nothing like what the use suggested.
Or are you
2) simply saying only accept dyads within the closest range the tuning allows
rather than an arbitrary value that may actually give different dyads based on
couple of cents' difference (if, say, the tuning is something ridiculously
accurate like, say, 160+ TET)?
...problem is 2 seems to lead to 1...in some cases......

Gene>"Not a bad idea, but I'd like to see results from a program which works for
equal divisions and any list of targets, and specifically tonality diamond
targets, first."

Well, I am already on my way to multiple size scales from multiple-sized
TET's....soon as I can get my programming loops (now 12 embedded loops for a 12
tone scale) to work as scalable recursive functions.

How do "tonallity diamond targets" work vs. the user being able to add all
dyads of x-limit to a list? Again, all I thought you wanted originally was an
easy way to add x-limit dyads to a list and then find them....

Me> If it's really essential...I can add a feature that
> rotates the mode to its "lowest hash value" using your system once scale
> processing is done...but I fear the program will be too slow if I try doing
>that
>
> real-time.
Gene>I'm not worried about modes; the point is you are missing actually distinct
scales.

Ok, so let me get this straight. You want my program to not only return the
scale with the highest number of dyads, but
A) Multiple scales say...the top 10 or so with the highest number of dyads
B) Check if those 10 unique IE one can not be a transposed version of the other
...if so I will have to restructure my program a bit to handle "stacks" of
scales and sorting/storing of transposed versions of each scale as it gets them
AKA problems I don't have with my existing method of only selecting the one
scale with the highest number of dyads.

🔗Michael <djtrancendance@...>

🔗genewardsmith <genewardsmith@...>

🔗Michael <djtrancendance@...>

Gene>"For instance, for 31 you map 2 to 31, 3 to 49, 5 to 72, 7 to 87 and 11 to
107. "

Sounds more like a "fact" than a "method". I'm guessing 2 is to 31 because
31 is the octave and 3 is to 49 because note 49 would be the "tritave"?

Now pick and 11-limit interval, say 7/6 = 2^(-1) 3^(-1) 5^0 7^1
....ok...that seems to make sense.......1/2 * 1/3 * 1 * 7 = 7/6....you are
splitting up the interval into primes...

....11^+87*10;
but how did that 11^(87*10) get there? Why wouldn't it be 11^0? If it
weren't for that last part...I'd say you're the first one here to really
summarize effectively to me how this factorization works (well,
non-programmatically...at least)....

>"Then <<31 49 72 87 107|-1 -1 0 1 0>> = 31*(-1)+49*(-1)+72*0+87*1+107*0 = 7, so
>7/6 is mapped to 7."

So, in other words, all these calculations are done to figure out that 7/6
is the 7th note of 31TET? This doesn't seem to say anything about dyadic
error...the point I thought you were making...hmm....

The other question is...how do you prime-factorize an arbitrary fraction?
Say it was 14/9 or something not well approximated in 31TET....how would you
rule it out? I'm pretty sure "prime factorization" that's NOT in vb.Net's
standard math functions. :-D And I'm guessing I would need the scale mappings
hard coded...or how could I derive them from scratch?

>"No floating point computations are used, and in my opinion they should at no
>point be used anywhere in a program just for the edos, unless you count
>computing a val automatically rather than inputting one. Integers only!"

It's crafty you can do this all with integers but I kind of wonder...what's
the point far as speed advantage or otherwise advantage of this?

The only thing I can think of off the top of my head is once you know what
interval each index stands for, you can make a table and say, if you have a dyad
between notes 2 and 9 of the scale...you can do 9 - 2 = 7 and then look up
equivalentfractionarray[7] to get 7/6 (or zero AKA false-match if 7/6 is not in
your desired fraction list).

So it would be the difference between handling
1) That subtraction and single-element array lookup or
2) My dyadtable[from,to] data structure which gives either a value of true (if
there is a desired dyad there) or a value of false (if there is no desired dyad
there).

Yes....1 would probably be a little bit faster in the program's inner loop.
And yes...the dyadtable is calculated between all dyads in 31TET via
floating point (where each multiplication takes twice as long as it would in
fixed-point/integer).... But then again, that only takes about 2 seconds to
pre-calculate (it just fills valid dyads in a 31 by 31 array once before the
scale-creation loops start)... So swapping that with your vals method, though
elegant, would most likely make a very small speed difference IE something like
9 minutes 58 seconds vs. 10 minutes 5 second. If I understand it well...I'll
probably throw that shortcut in when I find time for it.

>"And not what I am saying at all. But you can have more than one val for the
>same edo. If you were to count 11-limit dyads in 99, you could count using the
>val <<99 157 230 278 342||, the val <<99 157 230 278 343||, or you could count
>both."
One question before any others....how are you getting the different vals IE
the 157? If I do 99 * 3/2 I get 148 and 99 * 11/7 = 156...or what is multiplied
by or otherwise manipulates the value of 99 to get 157?

🔗genewardsmith <genewardsmith@...>

--- In tuning@yahoogroups.com, Michael <djtrancendance@...> wrote:
>
> Gene>"For instance, for 31 you map 2 to 31, 3 to 49, 5 to 72, 7 to 87 and 11 to
> 107. "
>
> Sounds more like a "fact" than a "method". I'm guessing 2 is to 31 because
> 31 is the octave and 3 is to 49 because note 49 would be the "tritave"?

Right. But the point is, this is all the info you need.

>
> ....11^+87*10;
> but how did that 11^(87*10) get there?

Some mistake cutting and pasting? I'm not sure.

Why wouldn't it be 11^0?

It would be, of course.

> So, in other words, all these calculations are done to figure out that 7/6
> is the 7th note of 31TET? This doesn't seem to say anything about dyadic
> error...the point I thought you were making...hmm....

No, I'm suggesting worry about the error later if you wish to.

> The other question is...how do you prime-factorize an arbitrary fraction?

There's a can of worms, but these aren't arbitrary fractions; they have only small primes in their factorization, which makes it trivial to compute by brute force.

> Say it was 14/9 or something not well approximated in 31TET....how would you
> rule it out?

If you don't like it, take it off your target list. But hopefully after first running it with it in.

I'm pretty sure "prime factorization" that's NOT in vb.Net's
> standard math functions. :-D And I'm guessing I would need the scale mappings
> hard coded...or how could I derive them from scratch?

It's easy to do when the edo approximates the prime limit well, by rounding log2(p) where p is a prime to the nearest integer. Why not stick with those for now?

> It's crafty you can do this all with integers but I kind of wonder...what's
> the point far as speed advantage or otherwise advantage of this?

Do it this way and you are less likely to get tangled up in problems, I suspect, and other people (me, for instance) will be more certain we know what you actually did.

> The only thing I can think of off the top of my head is once you know what
> interval each index stands for, you can make a table and say, if you have a dyad
> between notes 2 and 9 of the scale...you can do 9 - 2 = 7 and then look up
> equivalentfractionarray[7] to get 7/6 (or zero AKA false-match if 7/6 is not in
> your desired fraction list).

Why in the world do that?? You just want the 7; it's all you need.

>
> So it would be the difference between handling
> 1) That subtraction and single-element array lookup or
> 2) My dyadtable[from,to] data structure which gives either a value of true (if
> there is a desired dyad there) or a value of false (if there is no desired dyad
> there).
>
> Yes....1 would probably be a little bit faster in the program's inner loop.
> And yes...the dyadtable is calculated between all dyads in 31TET via
> floating point

Which slows things down, and provides an opportunity to screw things up.

> One question before any others....how are you getting the different vals IE
> the 157? If I do 99 * 3/2 I get 148 and 99 * 11/7 = 156...or what is multiplied
> by or otherwise manipulates the value of 99 to get 157?

99 * log2(3) = 156.911.

🔗Michael <djtrancendance@...>

Me> The other question is...how do you prime-factorize an arbitrary
fraction?

Gene>There's a can of worms, but these aren't arbitrary fractions; they have
only small primes in their factorization, which makes it trivial to compute by
brute force.
So I'd do something like

for u = -3 to 3
for v = -3 to 3
for w = -3 to 3
for x = -3 to 3
for y = -3 to 3
for z = -3 to 3
begin
if 2^u * 3^v * 5^w + 7^x + 9^y + 11^z = desiredfraction then
u*31*log2(2) + v*31*log2(3) + w*31*log2(5) + x*31*log2(5) +
y*31*log2(5) + z*31*log2(5)
end if
end if

If so....the loop would involve some 7^6 (6 loops and 7 values from -3 to
3) = some 117000-ish or so iterations for the one calculations (not to mention
the fact taking exponentials and logarithms is pretty slow even with
integers)....vs. the 31*31 (or so) = 961 floating point division calculations
per dyad I'm doing for the isdyadinlist[fromtuningindex,totuningindex] table
pre-calculation (make that 1922 if you count floating point as being twice as
slow).
So far, I'm still not so convinced any of this wizardry is actually going to
make the program faster. Though I am fairly convinced I should at the very
least try your formulas and put them in comment blocks so people know the more
widely accepted mathematical equivalent to what I'm doing.

The one key advantage I see to your method...is that if a dyad like 7/6 has
two very close equivalents in a tuning (IE say one note in the tuning has it 7
cents sharp and the other has it 6 cents flat)...the program will be guaranteed
to go for the one that's 7 cents flat and not get confused because they are both
under my 8 cents limit (correct?!). Otherwise I'm pretty sure I don't see the
point of doing anything more than documenting it...because looking at it
carefully it seems much slower than what I'm already doing.

me> The only thing I can think of off the top of my head is once you know
what

> interval each index stands for, you can make a table and say, if you have a
>dyad
>
> between notes 2 and 9 of the scale...you can do 9 - 2 = 7 and then look up
> equivalentfractionarray[7] to get 7/6 (or zero AKA false-match if 7/6 is not in
>
> your desired fraction list).
gene>"Why in the world do that?? You just want the 7; it's all you need."

I don't get it. My ultimate goal is to test for dyads between two points in
the scale....and the first point is not always the root at 0.
So say I'm in a loop and the loop asks me to compare dyads 16 and 9 from
the scale...how would you want me to calculate it and/or have it stored for
retrieval? I'm 99% sure I'm at LEAST have to do 16 - 9 = 7 before I either try
to look up or calculate anything....

The other thing is...why do you seem to object so heavily to my array/index
look up? You seem to be saying "why use an array to look it up when you already
'have' the 7"...and I'm saying "ok, but is/how-is the 7 stored or are we
consistently re-retrieving it from scratch?

I figure either I can
A) Calculate the translation from any point in the tuning to any other (I can
easily use you calculation instead of mine) BEFORE I start doing that huge loop
through the 54 million or so possible scales and STORE it an an array for
look-up IE equivalentfractionarray[7] = 7/6 or even equivalentfractionarray[7]
= "good" or TRUE...where good means a dyad that matches the list.
OR
B) Perform your said calculation from scratch every time for each of the
dyads....so I'd end up doing it 54 million times (for the 54 million scale) *
the number of dyads in the scale per each scale and per each dyad compared!

So A seems to have a brutally obvious speed/efficiency
advantage....performing the same calculation a billion times to avoid using an
indexing array seems like an obvious programming no-no. Yes, it's an
"opportunity to make an indexing error"...but shouldn't that be worth it to make
something several hundred times (if not more) faster?

me> One question before any others....how are you getting the different vals
IE

> the 157? If I do 99 * 3/2 I get 148 and 99 * 11/7 = 156...or what is
>multiplied
>
> by or otherwise manipulates the value of 99 to get 157?

gene>99 * log2(3) = 156.911.

Ah, ok....and the next number would be 31 log2(5)?

🔗genewardsmith <genewardsmith@...>

--- In tuning@yahoogroups.com, Michael <djtrancendance@...> wrote:
>
> Me> The other question is...how do you prime-factorize an arbitrary
> fraction?
>
> Gene>There's a can of worms, but these aren't arbitrary fractions; they have
> only small primes in their factorization, which makes it trivial to compute by
> brute force.
> So I'd do something like
>
>
>
> for u = -3 to 3
> for v = -3 to 3
> for w = -3 to 3
> for x = -3 to 3
> for y = -3 to 3
> for z = -3 to 3
> begin
> if 2^u * 3^v * 5^w + 7^x + 9^y + 11^z = desiredfraction then
> u*31*log2(2) + v*31*log2(3) + w*31*log2(5) + x*31*log2(5) +
> y*31*log2(5) + z*31*log2(5)
> end if
> end if

Yipe! No; you have a fraction N/D, say, where N and D are only divisible by 2, 3, 5, or 7. So you keep dividing N by 2 until it is no longer divisible by 2 without remainder (ie, is odd.) Then you keep dividing by 3, and then by 5. What's left is either 1 or a power of 7; you count how many times 7 divides it. Then you do the same for D, and you are done.

> The one key advantage I see to your method...is that if a dyad like 7/6 has
> two very close equivalents in a tuning (IE say one note in the tuning has it 7
> cents sharp and the other has it 6 cents flat)...the program will be guaranteed
> to go for the one that's 7 cents flat and not get confused because they are both
> under my 8 cents limit (correct?!).

Right. It counts dyads consistently. This you may or may not want to do, but you ought to know and be in control of the process.

Otherwise I'm pretty sure I don't see the
> point of doing anything more than documenting it...because looking at it
> carefully it seems much slower than what I'm already doing.

This I doubt.

> I don't get it. My ultimate goal is to test for dyads between two points in
> the scale....and the first point is not always the root at 0.
> So say I'm in a loop and the loop asks me to compare dyads 16 and 9 from
> the scale...how would you want me to calculate it and/or have it stored for
> retrieval? I'm 99% sure I'm at LEAST have to do 16 - 9 = 7 before I either try
> to look up or calculate anything....

Yes; you subtract two small integers. Why is that a problem?

>
> The other thing is...why do you seem to object so heavily to my array/index
> look up? You seem to be saying "why use an array to look it up when you already
> 'have' the 7"...and I'm saying "ok, but is/how-is the 7 stored or are we
> consistently re-retrieving it from scratch?

The 7 is a small integer which is in a list or array of small integers. Again, why is that a problem?

> I figure either I can
> A) Calculate the translation from any point in the tuning to any other (I can
> easily use you calculation instead of mine) BEFORE I start doing that huge

And that seems easy enough, though it's just saving a subtraction table. Considering that looking something up in a subtraction table isn't going to be either faster or than subtracting, I don't see the point.

> gene>99 * log2(3) = 156.911.
>
> Ah, ok....and the next number would be 31 log2(5)?

Right. Round it off. This only creates a problem when it isn't obvious which integer to round it off to, which for 7 or 11 limit 31et isn't the case.

🔗genewardsmith <genewardsmith@...>

🔗Michael <djtrancendance@...>

>"Yipe! No; you have a fraction N/D, say, where N and D are only divisible by 2,
>3, 5, or 7. So you keep dividing N by 2 until it is no longer divisible by 2
>without remainder (ie, is odd.) Then you keep dividing by 3, and then by 5.
>What's left is either 1 or a power of 7; you count how many times 7 divides it.
>Then you do the same for D, and you are done."

So it would be more like

n = 14
d = 9
divides = true

bytwo = 0
bythree = 0
byfive = 0
byseven = 0 etc..........

byovertwo = 0
byoverthree = 0
byoverfive = 0
byoverseven = 0 etc......

..........

while divides
begin
divides = false

if n % 2 = 0
{
n = n / 2
bytwo++
divides = true
}

if n % 3 = 0 and divides = false
{
n = n / 3
bythree++
divides = true
}
etc...........................
if d % 2 = 0
{
d = d / 2
bytwo--
divides = true
}

if d % 3 = 0 and divides = false
{
d = d / 3
bythree--
divides = true
}
etc...........................

end

indexin31tet = 31*(bytwo)+49*(bythtee)+....

>"Yes; you subtract two small integers. Why is that a problem?"
This has NOTHING to do with the subtraction (and in fact, it sounded
before like you were complaining about the subtraction and I was wondering
why). To be clear, I'm not storing the subtraction in the array.

What I am storing the result from said formula you gave above.... I need
to do the subtraction to find the index in the array IE dyadin31tet[7] = "good"
(7/6)....so I can look up

if dyadin31TET[16-9] = "good" then gooddyads = gooddyads + 1 in the main
loop....when, say dealing with a scale with notes at indexes 16 and 9 in
31TET....instead of doing all the calculations above repeatedly.

>"The 7 is a small integer which is in a list or array of small integers. Again,
>why is that a problem?"
It's not at all....in fact that's exactly what I said I was going to do when
it seems you quipped at me "now why would you want to do THAT?" :-D But now you
seem to be saying you agree with the original statement I made...which you, at
the time, seemed to say was crazy. I'm all for array lists over calculations
whenever anything more complex than a multiplication is involved with
integers...in fact back when I did game programming I even bothered to put my
cosine/rotation values in lookup tables.