back to list

Fw: [tuning-math] Re: Greekish names for tuning units.

🔗monz <monz@attglobal.net>

7/4/2003 5:15:44 PM

hello all,

there's been some discussion the last few days
on the tuning-math list about a good, consistent
set of names for the units of MIDI tuning resolution.

some of us have come to agree on using Greek
prefixes followed by "mu" for "midi unit".
the prefixes indicate the numbers up to 14,
which is the greatest number of bits resolution
in the MIDI tuning specification.

> From: "Gene Ward Smith" <gwsmith@svpal.org>
> To: <tuning-math@yahoogroups.com>
> Sent: Friday, July 04, 2003 2:31 PM
> Subject: [tuning-math] Re: Greekish names for tuning units.
>
>
> --- In tuning-math@yahoogroups.com, John Chalmers wrote:
>
> > The well-formed Greek term for 14- is
> > tetrakaidek(a)-, but organic chemists have
> > shortened it to tetradec(a)- as in tetradecane,
> > a saturated hydrocarbon with 14 carbon atoms.
> > The 14-sided space-filling solid is thus a
> > tetrakaidekahedron.
>
> Tetradecamu works for me.

yes, i too prefer the shorter version.
"tetrakaidek(a)-" simply means "4 + 10"
of something.

a pedantic theorist might prefer to keep the
"kai", because the normal form for 14 has
"deka" first and *then* "tessera" (= 10 + 4),
and i could see how the "tetradek(a)-" form
might be mistaken for 40 (= 4 * 10, "four tens").

(40 actually has a totally different word: "saranta".)

the "tetradekamu" form comes by way of analogy
with "en-dek(a)-" for 11 and "do-dek(a)-" for 12.
but then at 13 the normal form switches and puts
the word for 10 first.

thus, the regular form for 12 is "dodek(a(-",
which has been used for a long time as prefix
to refer to 12-tone serialism as "dodecaphonic".
i think we can stretch the analogy to use
"tridekamu" for 13 and "tetradekamu" for 14.

OK, then how's this for the whole set? ...

bits EDO name

1 24 enamu (quarter-tone)
2 48 duomu / doamu (eighth-tone)
3 96 triamu
4 192 tesseramu / tetramu
5 384 pentemu / pentamu
6 768 heximu / hexamu
7 1536 heptamu
8 3072 oktomu /oktamu
9 6144 enneamu
10 12288 dekamu
11 24576 endekamu
12 49152 dodekamu (cawapu)
13 98304 dekatriamu / tridekamu
14 196608 dekatesseramu / tetradekamu (midipu)

the first term in the "name" column follows
strict Greek linguistic derivation.

the ones after the slashes are alternates which
i prefer. for one thing, they all end the
prefix with "a", so it's a nice, consistent
naming scheme, which i think others will
probably go along with. also note that i
prefer to use "k" instead of "c" for the
"k" sound, but if there's a lot of disagreement
about this i can be flexible. :)

so, a unit of tuning resolution which is used
on many electronic instruments which give 64
(= 2^6) units per semitone, and which AFAIK has
never had a name, can now be called a "hexamu".

back in the late 1980s and early 1990s, when
the software MIDI sequencer i used was Texture,
my microtonal music had heptamu precision.

if i have my information straight about Quicktime,
then its finest resolution is oktamus.

"cawapus" now thus become "dodekamus".
i don't think we really need to be concerned
with precision beyond that level of resolution.

and "midipus" become "tetradekamus".
i'm *certain* that we don't need to go
beyond *that*.

any big objections to this naming scheme?
speak now, or forever be condemned to using
this terminology for MIDI tuning! ;-)

... well, OK ... i doubt that "enamu" is
going to replace "quarter-tone" ...

... and so, would something like "midenamu"
(zero bits for tuning, i.e., a plain MIDI-note
in 12edo) be the equivalent for "semitone"?

-monz

🔗Gene Ward Smith <gwsmith@svpal.org>

7/4/2003 8:30:45 PM

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

also note that i
> prefer to use "k" instead of "c" for the
> "k" sound, but if there's a lot of disagreement
> about this i can be flexible. :)

The "k" is Greek, the "c" Latinized Greek; we are mostly used to the
Latinized forms and I don't see what's wrong with them.

🔗pitchcolor <Pitchcolor@aol.com>

7/5/2003 12:28:56 PM

Hi, Joe. You wrote:

> bits EDO name
>
> 1 24 enamu (quarter-tone)
> 2 48 duomu / doamu (eighth-tone)
> 3 96 triamu
> 4 192 tesseramu / tetramu
> 5 384 pentemu / pentamu
> 6 768 heximu / hexamu
> 7 1536 heptamu
> 8 3072 oktomu /oktamu
> 9 6144 enneamu
> 10 12288 dekamu
> 11 24576 endekamu
> 12 49152 dodekamu (cawapu)
> 13 98304 dekatriamu / tridekamu
> 14 196608 dekatesseramu / tetradekamu (midipu)

In each case the numbers in the EDO column should be half of
those you give here. This is the initial problem that started the
whole discussion. Remember, 7 bits is 768 ET, not 1536. 14
bits is 98304 ET, not 196608. In each case, for the number of
bits n, the number of divisions in the ED2 is 6 x 2^n, not 12 x 2^n.
Just to keep this straight, I think it might help to have a standard
form for the expression as:

n-mu = 6 x 2^n = x ED2

for example,

heptamu = 6 x 2^7 = 768 ED2

Second point: for all the discussion of Greek for 14, I'm glad that
John Chalmers spoke up - I had seen tetra kai deka as three
words before but not one... BUT, I think the best solution to the
name for the 14-bit mu is just to call it 'mu' = 'MIDI unit' because it
is the MIDI tuning standard, after all. I'm not sure of the necessity
to name mus under 4, but here is a revised list based on Joe's
suggestions:

bits - ED2 - name
1 - 12 - enamu
2 - 24 - duomu
3 - 48 - triamu
4 - 96 - tetramu
5 - 192 - pentamu
6 - 384 - hexamu
7 - 768 - heptamu
8 - 1536 - octamu
9 - 3072 - enneamu
10 - 6144 - dekamu
11 - 12288 - endekamu
12 - 24576 - dodekamu
13 - 49152 - tridekamu
14 - 98304 - mu

The other idea that comes to mind if we call 14-but 'mu' is to
name the others as versions of 'mu-minus-n' instead of 'n-mu'.
Not sure how this would translate into a name,. but it would
make sense. I think it makes a lot of sense to call the MTS
simply 'mu'.

Aaron

🔗monz <monz@attglobal.net>

7/5/2003 2:36:22 PM

hi Aaron,

> From: "pitchcolor" <Pitchcolor@aol.com>
> To: <tuning@yahoogroups.com>
> Sent: Saturday, July 05, 2003 12:28 PM
> Subject: [tuning] Fw: [tuning-math] Re: Greekish names for tuning units.
>
>
> Hi, Joe. You wrote:
>
> > bits EDO name
> >
> > 1 24 enamu (quarter-tone)
> > 2 48 duomu / doamu (eighth-tone)
> > 3 96 triamu
> > 4 192 tesseramu / tetramu
> > 5 384 pentemu / pentamu
> > 6 768 heximu / hexamu
> > 7 1536 heptamu
> > 8 3072 oktomu /oktamu
> > 9 6144 enneamu
> > 10 12288 dekamu
> > 11 24576 endekamu
> > 12 49152 dodekamu (cawapu)
> > 13 98304 dekatriamu / tridekamu
> > 14 196608 dekatesseramu / tetradekamu (midipu)
>
> In each case the numbers in the EDO column should be half of
> those you give here. This is the initial problem that started the
> whole discussion. Remember, 7 bits is 768 ET, not 1536. 14
> bits is 98304 ET, not 196608. In each case, for the number of
> bits n, the number of divisions in the ED2 is 6 x 2^n, not 12 x 2^n.
> Just to keep this straight, I think it might help to have a standard
> form for the expression as:
>
> n-mu = 6 x 2^n = x ED2
>
> for example,
>
> heptamu = 6 x 2^7 = 768 ED2

ugh! i thought we solved this, and that my definitions
had turned out to be correct after all ... and now you've
got me confused again.

is it because of a bit being used to indicate the
sign of the pitch-bend? i really don't get it.

let's forget about 2^14 and 2^7, and just start with
the simplest cases as examples. it helps me if we
use diagrams indicating the actual bit stream.

there has to be another bit in addition to
the numeric data bits, which designates the
direction of the bend up or down. to keep
things simple, let's assume here that this
"sign" bit is always set positive, to indicate
a raising of the pitch. all my confusion concerns
the numeric bits, and once i get that right, the
same information applies in the opposite direction
if the "sign" bit is negative.

so ...

if there is no pitch-bend command being sent, and
the MIDI-file is simply playing straight 12edo MIDI-notes,
then there are zero bits being used for pitch-bend data.

if there is one numeric bit being used, then that
means the data stream can be either 1 or 0. now
what exactly is that data indicating? the pitch-bend
command gives a maximum range of a semitone, up or
down depending on the data in the "sign" bit.

if the numeric data bit is 0, i get regular 12edo,
and if it's 1, i still get regular 12edo because
the "1" means to bend the pitch up a whole semitone.
correct so far?

now for the case of 2 numeric bits, which can
indicate any of the following data:

00 = 0
01 = 1
10 = 2
11 = 3

again, if the data is 0, there is no pitch-bend.
again, if it's 3, i'm getting the maximum pitch-bend
of a semitone, which still gives 12edo.

but if it's 1 or 2, then it looks like i get a
raise in pitch by 1/3-tone and 2/3-tone, respectively.
is that correct? if it is, then i need to look into
this more deeply. if it's incorrect, then what *is*
correct?

i'm not going any further until i get this much straight.

-monz

🔗Gene Ward Smith <gwsmith@svpal.org>

7/5/2003 3:38:02 PM

--- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
> hi Aaron,
> > From: "pitchcolor" <Pitchcolor@a...>

> > In each case the numbers in the EDO column should be half of
> > those you give here. This is the initial problem that started the
> > whole discussion. Remember, 7 bits is 768 ET, not 1536. 14
> > bits is 98304 ET, not 196608.

The midi tuning standard is the 12*128^2 = 196608-et, as anyone may
check for themselves. (By the way this is a paricularly rotten et in
some theoretical sense, as it mostly uses the 98304 numbers anyway.)

Since Aaron has gotten this part wrong, I think we would need some
very convincing evidence before buying the idea that he is right and
Manuel is wrong in general.

🔗monz <monz@attglobal.net>

7/5/2003 5:07:24 PM

> From: "monz" <monz@attglobal.net>
> To: <tuning@yahoogroups.com>
> Sent: Saturday, July 05, 2003 2:36 PM
> Subject: Re: [tuning] Fw: [tuning-math] Re: Greekish names for tuning
units.
>
>
> now for the case of 2 numeric bits, which can
> indicate any of the following data:
>
> 00 = 0
> 01 = 1
> 10 = 2
> 11 = 3
>
> again, if the data is 0, there is no pitch-bend.
> again, if it's 3, i'm getting the maximum pitch-bend
> of a semitone, which still gives 12edo.
>
> but if it's 1 or 2, then it looks like i get a
> raise in pitch by 1/3-tone and 2/3-tone, respectively.
> is that correct? if it is, then i need to look into
> this more deeply. if it's incorrect, then what *is*
> correct?

but of course i know this is wrong. all MIDI
tuning commands divide the semitone by powers of 2.

would someone who really knows this stuff please help me out?

-monz

🔗Gene Ward Smith <gwsmith@svpal.org>

7/6/2003 2:41:09 AM

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

> would someone who really knows this stuff please help me out?

I have no idea where these two bits come from; the important thing
seems to be seven bits, or 0-127 as a range. As I remarked before, the
midi tuning standard is to represent a pitch by three base 128 (7 bit)
digits. Here's the official line:

Frequency data shall be defined in units which are fractions of a
semitone. The frequency range starts at MIDI note 0, C = 8.1758 Hz,
and extends above MIDI note 127, G = 12543.875 Hz. The first byte of
the frequency data word specifies the nearest equal-tempered semitone
below the frequency. The next two bytes (14 bits) specify the fraction
of 100 cents above the semitone at which the frequency lies. Effective
resolution = 100 cents / 2^14 = .0061 cents.

One of these values ( 7F 7F 7F ) is reserved to indicate not frequency
data but a "no change" condition. When an instrument receives these
bytes as frequency data, it should make no change to its stored
frequency data for that MIDI key number. This is to prevent
instruments which do not use the full range of 128 MIDI key numbers
from sending erroneous tuning data to instrument which do use the full
range. The three-byte frequency representation may be interpreted as
follows:

0xxxxxxx 0abcdefg 0hijklmn
xxxxxxx = semitone
abcdefghijklmn = fraction of semitone, in .0061-cent units
Examples of frequency data:

00 00 00 = 8.1758 Hz (C – normal tuning of MIDI key no. 0)
<<00 00 01 = 8.2104 Hz>> (This is an error)
01 00 00 = 8.6620 Hz
0C 00 00 = 16.3516 Hz
3C 00 00 = 261.6256 Hz (middle C)
3D 00 00 = 277.1827 Hz (C# – normal tuning of MIDI key no. 61)
44 7F 7F = 439.9984 Hz
45 00 00 = 440.0000 Hz (A-440)
45 00 01 = 440.0016 Hz
78 00 00 = 8372.0190 Hz (C – normal tuning of MIDI key no. 120)
78 00 01 = 8372.0630 Hz
7F 00 00 = 12543.8800 Hz (G – normal tuning of MIDI key no. 127)
7F 00 01 = 12543.9200 Hz
7F 7F 7E = 13289.7300 Hz (top of range)
7F 7F 7F = no change (reserved)

These people seem a little sloppy, leaving numerical errors on their
web page, but presumably they know their own tuning standard, which
clearly states, giving a little deciphering, that they are using
the 196608-et, with each step of size 100/2^14 = .006103515625 cents
exactly.

🔗monz <monz@attglobal.net>

7/6/2003 6:49:51 AM

right, Gene, that's exactly how i understand it.

i'm in the process of creating detailed
Tuning Dictionary pages for every one of these
14 MIDI-units, and another "overview" page with
all of them.

the 14-bit unit (tetradekamu) need not be the
only one of concern: several of the others (tho
not all) are in use to various degrees by different
software and hardware manufacturers, in particular
the 12-bit dodekamu (Cakewalk and other software
sequencers), 8-bit oktamu (Quicktime), and
7-bit heptamu (many Ensoniq and other synths).

and since 96edo has its following (1924 Juli�n Carrillo,
1980 Pascale Criton, 2001 Vincent-Olivier Gagnon),
and it's a 3-bit triamu, it merits recognition too.

i explain the whole MIDI tuning deal here:

http://sonic-arts.org/monzo/miditune/miditune.htm

and ... what a coincidence that you've just
posted that erroneous table here, because i
just appended a corrected version to my webpage
before i read your post!

-monz

----- Original Message -----
From: "Gene Ward Smith" <gwsmith@svpal.org>
To: <tuning@yahoogroups.com>
Sent: Sunday, July 06, 2003 2:41 AM
Subject: [tuning] Fw: [tuning-math] Re: Greekish names for tuning units.

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

> would someone who really knows this stuff please help me out?

I have no idea where these two bits come from; the important thing
seems to be seven bits, or 0-127 as a range. As I remarked before, the
midi tuning standard is to represent a pitch by three base 128 (7 bit)
digits. Here's the official line:

Frequency data shall be defined in units which are fractions of a
semitone. The frequency range starts at MIDI note 0, C = 8.1758 Hz,
and extends above MIDI note 127, G = 12543.875 Hz. The first byte of
the frequency data word specifies the nearest equal-tempered semitone
below the frequency. The next two bytes (14 bits) specify the fraction
of 100 cents above the semitone at which the frequency lies. Effective
resolution = 100 cents / 2^14 = .0061 cents.

One of these values ( 7F 7F 7F ) is reserved to indicate not frequency
data but a "no change" condition. When an instrument receives these
bytes as frequency data, it should make no change to its stored
frequency data for that MIDI key number. This is to prevent
instruments which do not use the full range of 128 MIDI key numbers
from sending erroneous tuning data to instrument which do use the full
range. The three-byte frequency representation may be interpreted as
follows:

0xxxxxxx 0abcdefg 0hijklmn
xxxxxxx = semitone
abcdefghijklmn = fraction of semitone, in .0061-cent units
Examples of frequency data:

00 00 00 = 8.1758 Hz (C - normal tuning of MIDI key no. 0)
<<00 00 01 = 8.2104 Hz>> (This is an error)
01 00 00 = 8.6620 Hz
0C 00 00 = 16.3516 Hz
3C 00 00 = 261.6256 Hz (middle C)
3D 00 00 = 277.1827 Hz (C# - normal tuning of MIDI key no. 61)
44 7F 7F = 439.9984 Hz
45 00 00 = 440.0000 Hz (A-440)
45 00 01 = 440.0016 Hz
78 00 00 = 8372.0190 Hz (C - normal tuning of MIDI key no. 120)
78 00 01 = 8372.0630 Hz
7F 00 00 = 12543.8800 Hz (G - normal tuning of MIDI key no. 127)
7F 00 01 = 12543.9200 Hz
7F 7F 7E = 13289.7300 Hz (top of range)
7F 7F 7F = no change (reserved)

These people seem a little sloppy, leaving numerical errors on their
web page, but presumably they know their own tuning standard, which
clearly states, giving a little deciphering, that they are using
the 196608-et, with each step of size 100/2^14 = .006103515625 cents
exactly.

You do not need web access to participate. You may subscribe through
email. Send an empty email to one of these addresses:
tuning-subscribe@yahoogroups.com - join the tuning group.
tuning-unsubscribe@yahoogroups.com - unsubscribe from the tuning group.
tuning-nomail@yahoogroups.com - put your email message delivery on hold
for the tuning group.
tuning-digest@yahoogroups.com - change your subscription to daily digest
mode.
tuning-normal@yahoogroups.com - change your subscription to individual
emails.
tuning-help@yahoogroups.com - receive general help information.

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

🔗monz <monz@attglobal.net>

7/6/2003 7:39:13 AM

> From: "monz" <monz@attglobal.net>
> To: <tuning@yahoogroups.com>
> Sent: Sunday, July 06, 2003 6:49 AM
> Subject: Re: [tuning] Fw: [tuning-math] Re: Greekish names for tuning
units.
>
>
> the 14-bit unit (tetradekamu) need not be the
> only one of concern: several of the others (tho
> not all) are in use to various degrees by different
> software and hardware manufacturers, in particular
> the 12-bit dodekamu (Cakewalk and other software
> sequencers), 8-bit oktamu (Quicktime), and
> 7-bit heptamu (many Ensoniq and other synths).

oops! ... the Ensoniq keyboards use 6-bit hexamus,
not heptamus.

-monz

🔗Gene Ward Smith <gwsmith@svpal.org>

7/6/2003 12:42:42 PM

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

> i explain the whole MIDI tuning deal here:
>
> http://sonic-arts.org/monzo/miditune/miditune.htm

I think you've made it more complicated than neccessary. It's not
really a bizarre combination of octal and hexadecimal, it's simply
base 128. I suggest you add base 128 to your list of number bases and
explain in in those terms. Also, why bother with an approximation to
100/2^14 when you can give the exact figure, and you've already used
a lot of digits anyway?