uneven quantization in Cakewalk/soundcard tuning

hi all,

it seems that these two posts from a library never
made it to the list, so i'm forwarding them now.
apologies if they are duplicates.

-monz

FIRST FORWARDED POST:

-----Original Message-----
From: monz [mailto:monz@attglobal.net]
Sent: Monday, July 14, 2003 6:13 PM
To: monz
Subject: uneven quantization in Cakewalk/soundcard tuning

--- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:

/tuning/topicId_45368.html#45373

> <snip>
>
> i did a listening test on my computer with Cakewalk,
> using hexamus (my definition, 768edo) and all the
> finer resolutions down to dodekamus (49152edo,
> the Cakewalk limit).
>
> i can hear that there is a difference with the
> hexamu but not the heptamu or any smaller mu.
> therefore, i know for sure now that my soundcard
> has hexamu resolution and no better.

OK, over the weekend (while i was hearning
those "beautiful harmonies in the sky") i did
a very thorough listening test of Cakewalk
playing pitchbends on my computer soundcard.
i found something very strange.

Cakewalk allows dodekamu tuning resolution
in editing MIDI-files -- that is, 12 bits per
semitone, which equals 4096 units (dodekamus)
per 12edo Semitone.

and the actual resolution i heard was indeed
64 units per semitone, which is hexamu resolution,
and which gives 768edo, as i posted last week.

however -- here's the strange part -- those
64 divisions are *not equal*!

for purposes of explaining this, i'll call
each range of dodekamu numbers which results
in the same hexamu sound, a "zone".

the plain 12edo "MIDI-note", which lies at
the center of the +/- 200 cents pitch-bend
range, lies in the central zone, which extends
to +40 dodekamus above the center value of zero,
and -40 dodekamus below it, for a total size
of 81 units in this zone.

but then, going upwards to the next higher
semitone pitch, which is 4096 dodekamus,
the next zone covers +40 to +80, which is
only 40 units in that zone!

then the next zone is 81 units large, then
next one 40, then the next *two* zones are
both 81 units. then the pattern repeats,
altho it changes in the top half of the semitone
range, and also sometimes a zone is 39 units
instead of 40, or 80 instead of 81.

i made a precise map of the entire semitone
range, indicate the boundaries of each zone,
then compared it with straight 768edo. in
most of the cases, a 768edo note falls within
a zone, but not every time -- i.e., thus once
in a while there is a zone which contains
two 768edo notes, and then the next zone above
it will contain none.

i've even mapped out all the bits, to see if
i could find any patterns that would explain
how this works, but didn't notice any patterns.

of course, now this means that i am not
entirely sure that the output i'm getting
really *is* 768edo -- it might actually be,
say, the lowest bounding dodekamu value for
each zone, in which case the result is an
*unequal* temperament. more tests needed to
confirm what frequencies i'm actually getting.

can anyone explain why this works like this?
and how it works? it doesn't make sense to me.
why not just a quantization resulting in perfectly
equal 768edo, instead of this strange pattern?

-monz

SECOND FORWARDED POST:

-----Original Message-----
From: monz [mailto:monz@attglobal.net]
Sent: Tuesday, July 15, 2003 12:10 PM
To: monz
Subject: Re: 768edo de facto tuning standard? + pitchbend webpage
updated!

i'm posting right now from a public library.
i was hoping to supplement something i posted
from here yesterday, but i don't see it on the
list yet. anyway ...

the point of my post yesterday was an explanation
of how my Cakewalk/soundcard combo quantizes MIDI
pitch resolution into unequal "zones", 64 per
semitone, but which are generally 40 and 81 dodekamus
in size, which does *not* give 768edo!

the extra information i'm providing now which i
left out yesterday is this: each "zone" begins at
the closest 49152edo approximation to the next cent.

IOW, the central data value, which gives the plain
12edo MIDI-note (with no pitch-bend) and is rendered
in bits as x100 0000 , which equals 64 in decimal,
lies in the center of a "zone" which extends from
-0.9765625 cents to +0.9765625 cents.

the first "zone" above the center covers the range
from +1.000976563 to +1.977539063 cents.

the second "zone" begins at +2.001953125 cents.

some zones cover 39 dodekamus instead of 40, and
some cover 80 instead of 81. this is done to keep
the lower bound of each "zone" at the closest possible
49152edo approximation to the exact cents values.

however, because the "zones" are both ~40 and ~81
dodekamus in size, the quantization is unequal,
giving some "zones" which are 1 cent large, and
others which are 2 cents.

so my question still remains: why is this unusual
quantization implemented, instead of just a regular
768edo?

-monz

> From: monz [mailto:monz@attglobal.net]
> Sent: Monday, July 14, 2003 6:13 PM
> To: monz
> Subject: uneven quantization in Cakewalk/soundcard tuning
>
> From: monz [mailto:monz@attglobal.net]
> Sent: Tuesday, July 15, 2003 12:10 PM
> To: monz
> Subject: Re: 768edo de facto tuning standard? + pitchbend webpage
> updated!
>
>
> i'm posting right now from a public library.
> i was hoping to supplement something i posted
> from here yesterday, but i don't see it on the
> list yet. anyway ...
>
>
> the point of my post yesterday was an explanation
> of how my Cakewalk/soundcard combo quantizes MIDI
> pitch resolution into unequal "zones", 64 per
> semitone, but which are generally 40 and 81 dodekamus
> in size, which does *not* give 768edo!
>
> the extra information i'm providing now which i
> left out yesterday is this: each "zone" begins at
> the closest 49152edo approximation to the next cent.
>
> IOW, the central data value, which gives the plain
> 12edo MIDI-note (with no pitch-bend) and is rendered
> in bits as x100 0000 , which equals 64 in decimal,
> lies in the center of a "zone" which extends from
> -0.9765625 cents to +0.9765625 cents.
>
> the first "zone" above the center covers the range
> from +1.000976563 to +1.977539063 cents.
>
> the second "zone" begins at +2.001953125 cents.
>
> some zones cover 39 dodekamus instead of 40, and
> some cover 80 instead of 81. this is done to keep
> the lower bound of each "zone" at the closest possible
> 49152edo approximation to the exact cents values.
>
> however, because the "zones" are both ~40 and ~81
> dodekamus in size, the quantization is unequal,
> giving some "zones" which are 1 cent large, and
> others which are 2 cents.
>
> so my question still remains: why is this unusual
> quantization implemented, instead of just a regular
> 768edo?

so, in effect, what i'm getting is a subset tuning,
768-out-of-1200edo. (similar to the way Joe Pehrson's
version of blackjack is an unequal 21-out-of-72).

here's a list of all the possible pitch-bends on
my system for the range of 0 to +100 cents:

12mus cents

4096 100
4015 98
3974 97
3892 95
3851 94
3769 92
3728 91
3646 89
3605 88
3523 86
3441 84
3400 83
3318 81
3277 80
3195 78
3154 77
3072 75
3032 74
2950 72
2909 71
2827 69
2745 67
2704 66
2622 64
2581 63
2499 61
2458 60
2376 58
2335 57
2253 55
2171 53
2130 52
2048 50
2008 49
1926 47
1885 46
1803 44
1721 42
1680 41
1598 39
1557 38
1475 36
1393 34
1352 33
1270 31
1229 30
1147 28
1065 26
1024 25
943 23
902 22
820 20
738 18
697 17
615 15
574 14
492 12
410 10
369 9
287 7
246 6
164 4
82 2
+41 +1
-41 -1
-82 -2
etc.

-monz