Interval measures

New webpage: http://www.xs4all.nl/~huygensf/doc/measures.html
Any comments?
The scale archive has been updated too. I haven't been able to
read the list very carefully lately, so people who have
contributed scales please check for any missing.

Manuel

--- In tuning@y..., <manuel.op.de.coul@e...> wrote:

/tuning/topicId_23114.html#23114

>
> New webpage: http://www.xs4all.nl/~huygensf/doc/measures.html
> Any comments?

Excellent, Manuel!

Specific comments:

diesis:

"Diesis" also ought to mention Marchetto, who was probably
the earliest person to use it as a standard unit of interval
measurement. Exactly what he meant by it is open to question,
but he did use the term, dividing the "whole tone" into "5 dieses".
Perhaps you could include a link to my Marchetto page.
http://www.ixpres.com/interval/monzo/marchet/marchet.htm

Also, at the end of the "diesis" entry, "a convenient measure
in which to express 7-limit just intervals" would be better
English.

méride:

In the "méride" entry, "because he favoured 43-tone equal
temperament for the small intervals are well represented in it"
is not really incorrect but is a bit awkward. A comma after
"temperament" would improve it, or perhaps substitute "because"
for "for".

Which small intervals do you mean, anyway? That's not clear.

moria:

You should make a note about the controversy surrounding
this measurment, mainly because it is very unclear as to
exactly what Aristoxenos's measurements were. Perhaps
include a link to my webpage:
http://www.ixpres.com/interval/monzo/aristoxenus/318tet.htm

Also note that while the smallest measurement explicitly stated
by both Aristoxenos and his redactor Cleonides was "1/12-tone":

"apo de tes barytates chromatikes epi ten hemiolion,
dodekatemorion tonou."

"from the lowest chromatic to the hemiolic is a
twelfth part of a tone.",

(Aristoxenos is speaking of the _lichanos_ here), Aristoxenos's
genera require the recognition of "1/24-tone" between the
_parhypate_ of the hemiolic chromatic genos and and that of
the relaxed chromatic, implying 144-EDO.

savart:

Savarts were later "rationalized" to 2^(1/300). So it may
mean either 2^(1/300) or 2^(1/301), depending on who used it
and when.

(Also note that most of these terms are also in my Dictionary.
Perhaps links could be included.)

MIDI Tuning Standard unit:

I don't have any comments about your definition here, just
a question. Is the division I'm most familiar with, 2^12
(= 4096) units per semitone, any kind of standard at all?
It's the only one I've come across in working with MIDI.

In fact, except for the link to the MIDI spec which you
provided, I've *never* seen reference made to into 2^14
(= 16384) units per semitone. .....?

-monz
http://www.monz.org
"All roads lead to n^0"

--- In tuning@y..., <manuel.op.de.coul@e...> wrote:
>
> New webpage: http://www.xs4all.nl/~huygensf/doc/measures.html
> Any comments?
> The scale archive has been updated too. I haven't been able to
> read the list very carefully lately, so people who have
> contributed scales please check for any missing.
>
> Manuel

My understanding is that this is incorrect:

Türk sent (Turkish cent): 1/10600 part of an octave

I've always seen it as 1/1060, not 1/1060.

Also you're missing the TU (Tuning Unit) . . . it makes use of the
approximation syntonic comma = 11, Pythagorean comma = 12.

--- In tuning@y..., "monz" <joemonz@y...> wrote:

/tuning/topicId_23114.html#23126

> MIDI Tuning Standard unit:
>
> I don't have any comments about your definition here, just
> a question. Is the division I'm most familiar with, 2^12
> (= 4096) units per semitone, any kind of standard at all?
> It's the only one I've come across in working with MIDI.
>
> In fact, except for the link to the MIDI spec which you
> provided, I've *never* seen reference made to into 2^14
> (= 16384) units per semitone. .....?
>

I thought somebody said, was it John DeLaubenfels (??) that the MIDI
unit was not a set division, but could be altered somewhat, so it is
not a permanent measure... Did I get that wrong (??)

________ ________ ________
Joseph Pehrson

--- In tuning@y..., jpehrson@r... wrote:

/tuning/topicId_23114.html#23368

> I thought somebody said, was it John DeLaubenfels (??)
> that the MIDI unit was not a set division, but could be
> altered somewhat, so it is not a permanent measure...
> Did I get that wrong (??)

Hi Joe,

I had originally coined the term "midipu" (= MIDI Pitch-bend
Unit) and defined it as 1/4096 = 1/(2^12) of a Semitone.
This was based on my use of pitch-bend in Cakewalk.

Manuel corrected me and posted a link to the official
MIDI tuning specification webpage, wherein he stated
correctly that the finest tuning resolution available
in MIDI is 1/16384 = 1/(2^14) of a Semitone, and that the
figure in my definition was merely a less-finely-resolved
choice that Cakewalk had made. IIRC, John deL. chimed
in in agreement.

(I have since renamed that measurement a "cawapu" =
CAkeWAlk Pitch-bend Unit, and changed my definition of
midipu to agree with Manuel's).

So there is much variability in how different manufacturers
choose to implement the MIDI tuning spec, but the spec itself
offers 1/(2^14) Semitone as the limit of resolution.

Now, here's my long essay on how it all works....

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

GENTLE INTRODUCTION TO THE MIDI TUNING SPECIFICATION

by Joe Monzo

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

Much of this is going to be elementary for anyone who
knows anything about how computer work internally. But
following my explanation should shed some light on how
MIDI tuning and pitch-bend works.

I'm going to explain four numbering systems that all
have a bearing on learning how to use the MIDI tuning
specification:

1. decimal base_10
2. binary base_2
3. hexadecimal base_16
4. octal base_8

Think in terms of a prime-factor vector, which you've
seen me (and Graham Breed) use here many times before.
This use of a prime-factor vector was the confusing
aspect of my HEWM notation which you cited from my
paper a couple of months back, where I omit the primes
themselves and just string the exponents out in a series.

Understanding bits and bytes is similar to this.

The difference is that instead of representing exponents
of prime-factors, the numbers represent values of the
base-number raised to successive exponents.

Different numbering systems
---------------------------

For example, let's start with the system you're most
familiar with: decimal, also called base_10.
Of course I realize everyone understands this, but
it's necessary to spell out the procedure.

There are 10 decimal digits: 0 1 2 3 4 5 6 7 8 9.
These can be thought of as indicating the value of a
number of individual "units".

When we've used up all 10 digits and must continue
counting, how do we do it?

We imagine that these numbers may appear in a "place"
which has a specific meaning: that each place refers
to an exponent of the base number, and any digit in that
place indicates the value of that exponent.

So to get to the number "ten", simply form a new place
to the left of the original one and make that place
represent not units but "tens". In math, the difference
is indicated by: unit = 10^0, ten = 10^1. So placing
a "1" in the "tens" place indicates 1 "ten", or simply 10.
The zero in the units place shows that the total value
is only 10 and not more than 10.

Then we cycle thru the units place again until we reach
19, and then go back to zero in the units and bump the
tens up to 2, with the result of 20. Etc., etc.
The next place to the left is 100s (= 10^2), the next
to the left of that 1000s (= 10^3), etc.

So in other words the number 111, for example, really means:

(10^2)+(10^1)+(10^0)

= 100 + 10 + 1

= 111.

Now on to binary, also called base_2.

There are only 2 binary digits: 0 and 1. The reason
why this is so effective for use in computers is because
electronic switches can relay data by means of being in
one of either of two states: on or off.

The word "bit" is a contraction of the two words
"b-inary dig-it". A "byte" is an 8-digit binary string.

So how do we get any bigger numbers than 2 in binary?
Easy... the same way as in the decimal system.

Each place to the left will be a higher exponent of 2.

So the right-most place is 2^0 = 1, then next to the left
is 2^1 = 2, the next is 2^2 = 4, the next is 2^3 = 8, etc.

So we cycle thru the whole set by placing first a zero,
then a one, in each successive place:

binary decimal

0 = 0
1 = 1
10 = 2
11 = 3
100 = 4
101 = 5
110 = 6
111 = 7
1000 = 8

etc.

So, for example, the number 7 [decimal] is represented
in binary as with "1"s filling the first three places:

(2^2)+(2^1)+(2^0)

= 4 + 2 + 1

= 7

The next number, 8 [decimal], divides evenly into
the third power of 2, so it has a "1" filling the
2^3 place and zeros in all the others.

The next number system I'll discuss is hexadecimal,
or hex for short, also called base_16.

Long strings of 1s and 0s are difficult to comprehend
visually, so hex is used by programmers as a convenient
shorthand for binary. Its combination of numbers and
letters is much easier for humans to parse.

In this system, each place can hold numbers which
represent 0 thru 15. But we need to keep our "digits"
to, obviously, a single digit, so we invoke the first
few letters of the alphabet after we pass 9.

Let's continue counting from the table above, this
time with the results in hex rather than decimal (you
only see a difference after 9). I'll give the decimal
value at the end, just so you can see what it is:

binary hex decimal

1001 = 9
1010 = A = 10
1011 = B = 11
1100 = C = 12
1101 = D = 13
1110 = E = 14
1111 = F = 15

Because 1 hex digit can represent exactly 4 binary digits,
this is sometimes found to be a useful grouping, and is
called a "nibble" (I've also seen it spelled "nybble").
A nibble is exactly half a byte... get it?

I'm mentioning nibbles here because they play a role
in understanding how the MIDI tuning spec uses the data
contained in each byte of a signal. I'll use nibble-size
binary groupings below to illustrate the hex numbers that
we'll come across.

Also note that it's easy to specify binary strings
of 1s in decimal format by bumping up to the next
higher power of 2 and using "-1". For example,
our last number in the above table, 1111 [binary]
= 10000 [binary] minus 1, or in decimal, (2^4)-1
= 16 - 1 = 15, which = F in hex.

After F [hex], which = 15 [decimal], we get to
16 [decimal] by using the same procedure as before:
bump up to the next higher exponent of 16 and start
over again. So a "1" in the next higher place means
16^1, and in the next higher place after that, 16^2, etc.

So the highest 2-digit number in hex is FF [hex],
which equals

(15 * (16^1)) + (15 * (16^0))

= (15 * 16) + (15 * 1)

= 240 + 15

= 255

The next higher number would be 256 [decimal],
which divides evenly as the second power of 16,
so we put a "1" in the third place followed by
two zeros: 100 [hex] = 256 [decimal]. So,
in hex, FF + 1 = 100.

There's an intermediate numbering system called octal,
which is (you guessed it) base_8. This system is a
bit easier to understand because it works just like
decimal but only has digits 0 thru 7. After 7 comes
10 [octal] = 8 [decimal].

In fact it's somewhat akin to our usual diatonic
musical numbering system which uses A B C D E F G,
then starts again at A when we reach the next "octave".

Octal is not much used these days, hex being preferred.
But because of the structure of the MIDI tuning data
protocol, octal plays an important role in MIDI tuning
calculations.

Now, with that out of the way, on to the specifics
of the MIDI tuning data format.

From the official MIDI website
<http://www.midi.org/about-midi/tuning.htm>:

> Frequency data shall be sent via system exclusive
> messages. Because system exclusive data bytes have
> their high bit set low, containing 7 bits of data,
> a 3-byte (21-bit) frequency data word is used for
> specifying a frequency with the suggested resolution.

In other words, the left-most bit or place, in each of
the three 8-digit binary strings called a "byte" which
belong to a tuning command, is set to 0, which in this
case is simply a flag to let the hardware know that
these 3 bytes of data are a SysEx type of message.

This is extremely important, because it means that the
rules of enumeration which I elaborated above are not
quite followed. There's a different system in use here
that's called an "offset".

More from the midi website:

> 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 / 214 = .0061 cents.

There's a serious typo error on the webpage here, in the
denominator of that fraction. That effective resolution
should be 100 cents / 2^14 = ~0.006103516 cent.

Thus, the greatest possible MIDI tuning resolution
is equivalent to 1200 / (0.006103516) = 196608-EDO,
or 2^14 = 16384 midipus per Semitone.

Let's begin by illustrating the nature of the MIDI data.
I'll use variables s and m, to stand for Semitone bit
and midipu bit, respectively:

0sssssss 0mmmmmmm 0mmmmmmm

So in other words, the highest value that any of these
bytes can have is 1111111 [binary] = (2^8)-1 [decimal],
which equals 127. This is the same as saying:

(2^6)+(2^5)+(2^4)+(2^3)+(2^2)+(2^1)+(2^0)

= 64 + 32 + 16 + 8 + 4 + 2 + 1

= 127.

127 [decimal] = 7F [hex], because the first "nibble"
is 0100 [binary] = 7 [hex], and the second "nibble"
is 1111 [binary] = F [hex]. So all the values in
the three MIDI data bytes must be between 0 and 127
[decimal], which is the same as between 0 and 7F [hex].

The Semitone component
------------------------

This is why there are 128 possible different MIDI notes,
numbered from C0 to G10; or, to put it another way
which relates to the illustration above, 128 different
semitone divisions of the total pitch-space.
In Semitones, this is:

10 "octaves" + the highest "octave" of C + a "5th"

= (12 * 10) + 1 + 7

= 128 total MIDI-notes.

Let's examine some specific MIDI-note numbers to
see how it works.

First let's try the familiar "octave". This is
the 12th note above the starting note. Recapping
the hex table I gave above, we see that:

hex decimal

9 = 9
A = 10
B = 11
C = 12

So in hex the 12th note would be the digit "C":

0C [hex]

= (0 * (16^1)) + (12 * (16^0)) [decimal]

= (0 * 16) + (12 * 1)

= 0 + 12

= 12 [decimal], or an "octave"

= MIDI-note C1.

Let's try the highest hex digit, F.
Remember, F [hex] = 15 [decimal]:

0F [hex]

= (0 * (16^1)) + (15 * (16^0)) [decimal]

= (0 * 16) + (15 * 1)

= 0 + 15

= 15 [decimal]

= (15 / 12) = 1 & 3/12 "octaves" above C0

= an "octave" + a "minor 3rd" above C0

= MIDI-note Eb1/D#1.

And to find out highest MIDI-note:

7F [hex]

= (7 * (16^1)) + (15 * (16^0)) [decimal]

= (7 * 16) + (15 * 1)

= 112 + 15

= 127 [decimal]

= (127 / 12) = 10 & 7/12 "octaves" above C0

= 10 "octaves" + a "perfect 5th" above C0

= MIDI-note G10.

Now let's reverse the procedure, so that for
any given MIDI-note we find the hex value.

Let's find "middle-C":

= MIDI-note C5.

= 5 "octaves" above C0

= 5 "octaves" * 12 Semitones

= 60 [decimal] (MIDI-note number 60)

(60 / 16 = 3 & 12/16, therefore...)

60 [decimal]

= 48 + 12

= (3 * 16) + (12 * 1)

= (3 * (16^1)) + (12 * (16^0)) [decimal]

= 3C [hex]

Since A-440 Hz is the MIDI tuning reference,
let's find that:

= MIDI-note A5.

= 5 "octaves" + a "major 6th" above C0

= 5 & 9/12 "octaves" above C0

= ((5 * 12) + 9) Semitones

= (60 + 9) Semitones

= 69 [decimal] (MIDI-note number 69)

(69 / 16 = 4 & 5/16, therefore...)

69 [decimal]

= (4 * 16) + 5

= 64 + 5

= (4 * 16) + (5 * 1)

= (4 * (16^1)) + (5 * (16^0)) [decimal]

= 45 [hex]

I chose these MIDI-notes deliberately because
they appear in the table on the MIDI spec website.
This explanation should make it easier to understand
that table.

The pitch-bend component
------------------------

That's easy enough for the semitone component of the
tuning spec, because it only occupies one byte.

But for the fraction-of-a-semitone component
(or pitch-bend component), which occupies *two*
bytes, the math is a bit more complicated. You
can't simply keep bumping up to the next higher
exponent of your base. That zero in what is called
the most significant bit throws the calculation
off by one exponent.

(It's called the "most significant bit" because it
has the highest *potential* value in its byte, even
tho in the MIDI spec it is actually equal to zero.)

Here's the solution.

127 [decimal] = 7F [hex] is the highest value we can
have in any of the three tuning data bytes. So if
our first data byte (the one to the right) has a
value of 7F [hex] = 127 [decimal], we can't simply use
the regular 8F [hex] to reach 128 [decimal] .

We have to skip over the predetermined zero in the
most significant bit of this byte, and put a "1"
into the next available place, which would be the
least significant bit of the next higher byte.

In binary notation, we may designate the mandatory
zero in the highest bit with an "x", to illustrate
that it cannot be used in our calculation.

This ends up giving us a rather bizarre combination of
octal and hex in our calculations, and has made MIDI
tuning math more complicated than it probably needed to
be. I will refer to this as "octal-hex" in my labels.

We will also find that it is easier to understand the
octal-hex combination if we divide the bytes into
two nibbles for the purposes of binary notation, and
if we use zeros as place-holders in the unused places
of the octal-hex numbers and divide them into bytes.

Thus, in effect, the two pitch-bend data bytes are
divided into 4 nibbles which are counted in the pattern:
octal - hex - octal - hex (from left to right).

So if we start now at:

127 [decimal]

= 00 7F [octal-hex]

= x000 0000 x111 1111 [binary],

this gives a tuning inflection of ~0.775146484 cent.

The next number is:

128 [decimal]

= 01 00 [octal-hex]

= x000 0001 x000 0000 [binary].

This gives a tuning inflection of 0.78125 cent.

So we can see that instead of representing 256 [decimal]
as in a regular hex calculation, 01 00 [octal-hex] will now
represent 128 instead.

So now we may cycle thru all the possible combinations
of digits in the lower (right-most) byte until we
fill all the places with their highest digit (which
is "1" in binary), which would give us:

x000 0001 x111 1111 [binary]

= 01 7F [octal-hex]

= 128 + 127 [decimal]

= 255 [decimal].

This gives a tuning inflection of ~1.556396484 cents.

The next number is:

256 [decimal]

= 02 00 [octal-hex]

= x000 0010 x000 0000 [binary]

This gives a tuning inflection of 1.5625 cents.

So this rather complicated calculation is achieved
by treating the left byte the same way as the right
one, then multiplying it by 128, then adding both
bytes together.

Alternatively, perhaps it is easier to think of
each hex digit as a certain exponent of 2 which
follows an alternating irregular pattern:

4 3 4 ... pattern of exponent increase
/ \ / \ / \
= 2^11 2^7 2^4 2^0 ... exponent of 2

= 2048 128 16 1 ... decimal value

Since this interrupted pattern (i.e., the mandatory
zero byte that doesn't count in the calculation) is a
non-standard kind of math, let's cycle thru all the
remaining pairs of numbers where the next "place"
changes, to be absolutely clear on how it works.

= x000 0010 x111 1111 [binary]

= 02 7F [octal-hex]

= 383 [decimal]

Tuning inflection: ~2.337646484 cents.

= x000 0011 x000 0000 [binary]

= 03 00 [octal-hex]

= 384 [decimal]

Tuning inflection: 2.34375 cents.

= x000 0011 x111 1111 [binary]

= 03 7F [octal-hex]

= 511 [decimal]

Tuning inflection: ~3.118896484 cents.

= x000 0100 x000 0000 [binary]

= 04 00 [octal-hex]

= 512 [decimal]

Tuning inflection: 3.125 cents.

= x000 0111 x111 1111 [binary]

= 07 7F [octal-hex]

= 1023 [decimal]

Tuning inflection: ~6.243896484 cents.

= x000 1000 x000 0000 [binary]

= 08 00 [octal-hex]

= 1024 [decimal]

Tuning inflection: 6.25 cents.

= x000 1111 x111 1111 [binary]

= 0F 7F [octal-hex]

= 2047 [decimal]

Tuning inflection: ~12.49389648 cents.

= x001 0100 x000 0000 [binary]

= 10 00 [octal-hex]

= 2048 [decimal]

Tuning inflection: 12.5 cents.

= x001 1111 x111 1111 [binary]

= 1F 7F [octal-hex]

= 4095 [decimal]

Tuning inflection: ~24.99389648 cents.

= x010 0000 x000 0000 [binary]

= 20 00 [octal-hex]

= 4096 [decimal]

Tuning inflection: 25 cents.

= x011 1111 x111 1111 [binary]

= 3F 7F [octal-hex]

= 8191 [decimal]

Tuning inflection: ~49.99389648 cents.

= x100 0000 x000 0000 [binary]

= 40 00 [octal-hex]

= 8192 [decimal]

Tuning inflection: 50 cents.

= x111 1111 x111 1111 [binary]

= 7F 7F [octal-hex]

= 16383 [decimal]

Tuning inflection: ~99.99389648 cents.

Whew! Still with me? We made it thru the hardest
part.

Since 7F 7F [octal-hex] = 16383 [decimal] is the
highest possible value, there are a total of
16384 = 2^14 possible divisions of the Semitone
in the MIDI tuning spec. This is how I found
the error in the fraction on the MIDI website.

Most instruments and software do not take full
advantage of this super-fine resolution.
As the MIDI spec says:

> An instrument which does not support the full
> suggested resolution may discard any unneeded
> lower bits on reception, but it is preferred
> where possible that full resolution be stored
> internally, for possible transmission to other
> instruments which can use the increased resolution.

Cakewalk [TM] 2.0, the MIDI sequencer I use, gives
a tuning resolution of 4096 = 2^12 cawapus (a new
term I just coined) per Semitone. Thus it ignores
the first two bits available in the spec, and
therefore gives a range of possible values from
0 to 4095 [decimal] = 00 00 to 1F 7F [hex]. In
other words, the first nibble can only be a 0 or 1.

Here are some other more accurate numbers to
replace those given on the MIDI website (one
needs to be especially careful when rounding
off very low frequencies):

Frequency of
lowest MIDI-note = 440 Hz / (ratio of A5:C0)

= 440 / (2^((69-0)/12)) Hz

= ~8.175798916 Hz

Frequency of
highest MIDI-note = (ratio of A5:G10) * 440 Hz

= (2^((127-69)/12)) * 440 Hz

= ~12543.85395

-monz
http://www.monz.org
"All roads lead to n^0"

--- In tuning@y..., "monz" <joemonz@y...> wrote:

/tuning/topicId_23114.html#23415

> 127 [decimal] = 7F [hex], because the first "nibble"
> is 0100 [binary] = 7 [hex], and the second "nibble"
> is 1111 [binary] = F [hex]. So all the values in
> the three MIDI data bytes must be between 0 and 127
> [decimal], which is the same as between 0 and 7F [hex].

Oops! My bad!

That should say:

... the first "nibble" is 0111 [binary] = 7 [hex]

-monz
http://www.monz.org
"All roads lead to n^0"

Paul wrote:
>Türk sent (Turkish cent): 1/10600 part of an octave
>I've always seen it as 1/1060, not 1/1060.

You're right, a mistake in my notes.

>Also you're missing the TU (Tuning Unit) . . . it makes use of the
>approximation syntonic comma = 11, Pythagorean comma = 12.

Would that be a step of 612-tET then? It looks vaguely familiar.
Whose idea was it? Yours? It's not the same as a Grad?

Thanks to Joe too for his remarks.

Manuel

[Monz wrote:]
>I had originally coined the term "midipu" (= MIDI Pitch-bend
>Unit) and defined it as 1/4096 = 1/(2^12) of a Semitone.
>This was based on my use of pitch-bend in Cakewalk.

>Manuel corrected me and posted a link to the official
>MIDI tuning specification webpage, wherein he stated
>correctly that the finest tuning resolution available
>in MIDI is 1/16384 = 1/(2^14) of a Semitone, and that the
>figure in my definition was merely a less-finely-resolved
>choice that Cakewalk had made. IIRC, John deL. chimed
>in in agreement.

Well, I'm quibbling here, but Manuel's post (22245) originally claimed
that there was no standard. Robert Walker (22255) and I (22254) said
there was; his is a more complete description than mine.

More importantly, it is _not_ true that the finest tuning resolution is
1/(2^14) semitone. The bend range can be set all the way down to zero
(no deviation from 12-tET, or "infinite resolution"). I am able to
verify this on both my GM sound modules (a Yamaha DS-XG soundcard and
a Roland VSC "Virtual Sound Canvas" program). The MIDI spec also
states that the bend range can be further honed down to the nearest
cent, using the data entry fine slider (Bx 26 xx), but neither of my
modules seems to respond to this message: when I try to set an overall
range of +/- 50 cents, I just get zero range. BTW, that range, if it
could be achieved, would make a midipu 1/16384 of a semitone, so the
lowest nontrivial range achievable on (at least my) GM modules would be
+/- 1 semitone, or 1/8192 = 1/(2^13) semitone per midipu.

JdL

I was actually only speaking about the MIDI specification,
not about any implementation or interpretation of it.
Pitch bending and tuning are two different things. I don't
have a copy of the MIDI spec at hand, but I'm almost sure
there is no requirement in there that pitch bend messages
should be usable for (accurate) channel tuning.
The MIDI Tuning Spec is currently only implemented by Emu,
Ensoniq and Turtle Beach so it's not very surprising that
Joe had never heard of it.

John wrote:
>More importantly, it is _not_ true that the finest tuning resolution is
>1/(2^14) semitone.

This is the resolution of the MTS, not the pitch bend
resolution. Furthermore it's the resolution for _specifying_
a pitch, there is no requirement in the MTS that says that
an implementation actually should respond with this
accuracy. Which I think is also true for pitch bend messages,
instruments can respond in almost any way they want without
violating the standard.

Manuel

[Manual Op de Coul wrote:]
>I was actually only speaking about the MIDI specification,
>not about any implementation or interpretation of it.
>Pitch bending and tuning are two different things. I don't
>have a copy of the MIDI spec at hand, but I'm almost sure
>there is no requirement in there that pitch bend messages
>should be usable for (accurate) channel tuning.
>The MIDI Tuning Spec is currently only implemented by Emu,
>Ensoniq and Turtle Beach so it's not very surprising that
>Joe had never heard of it.

[I wrote:]
>>More importantly, it is _not_ true that the finest tuning resolution
>>is 1/(2^14) semitone.

>This is the resolution of the MTS, not the pitch bend
>resolution. Furthermore it's the resolution for _specifying_
>a pitch, there is no requirement in the MTS that says that
>an implementation actually should respond with this
>accuracy. Which I think is also true for pitch bend messages,
>instruments can respond in almost any way they want without
>violating the standard.

Thanks for that clarification, Manuel! I obviously missed that before.

JdL

In-Reply-To: <5.0.2.1.1.20010521093752.04824ec0@earthlink.net>
John A. deLaubenfels wrote:

> More importantly, it is _not_ true that the finest tuning resolution is
> 1/(2^14) semitone. The bend range can be set all the way down to zero
> (no deviation from 12-tET, or "infinite resolution"). I am able to
> verify this on both my GM sound modules (a Yamaha DS-XG soundcard and
> a Roland VSC "Virtual Sound Canvas" program). The MIDI spec also
> states that the bend range can be further honed down to the nearest
> cent, using the data entry fine slider (Bx 26 xx), but neither of my
> modules seems to respond to this message: when I try to set an overall
> range of +/- 50 cents, I just get zero range. BTW, that range, if it
> could be achieved, would make a midipu 1/16384 of a semitone, so the
> lowest nontrivial range achievable on (at least my) GM modules would be
> +/- 1 semitone, or 1/8192 = 1/(2^13) semitone per midipu.

That's interesting -- so they respond to the coarse tuning (set pitch bend
range in semitones) but not fine tuning (cents)?

And isn't there some confussion between pitch bends and the Midi Tuning
Standard here. The 1/4096 midipu is for the former (at default +/-2
semitone resolution), the 1/2^14 for the latter.

Graham

--- In tuning@y..., "monz" <joemonz@y...> wrote:

/tuning/topicId_23114.html#23415

> <_A Gentle Introduction to the MIDI Tuning Spec_>

To which came the following replies (in part):
/tuning/topicId_23114.html#23430
/tuning/topicId_23114.html#23432
/tuning/topicId_23114.html#23434

I was confused when Manuel first brought this up.

Then I thought I understood it after writing this.

Now I'm totally confused again.

I've made a webpage of the _Gentle Introduction_, so
please tell me if there is anything in it that really is
wrong and needs to be corrected.

I don't understand the differences here between pitch-bend
and MTS. The MIDI Spec website simply shows the data
format for specifying a pitch, and it looked to me like
it could be referring to either method. Please clarify.

-monz
http://www.monz.org
"All roads lead to n^0"

In-Reply-To: <9ebieo+i7u1@eGroups.com>
monz wrote:

> I don't understand the differences here between pitch-bend
> and MTS. The MIDI Spec website simply shows the data
> format for specifying a pitch, and it looked to me like
> it could be referring to either method. Please clarify.

What you explained is for the MTS, a standard way of specifying tuning
tables, and looks correct to me.

Graham

--- In tuning@y..., <manuel.op.de.coul@e...> wrote:
>
> Paul wrote:
> >Türk sent (Turkish cent): 1/10600 part of an octave
> >I've always seen it as 1/1060, not 1/1060.
>
> You're right, a mistake in my notes.
>
> >Also you're missing the TU (Tuning Unit) . . . it makes use of the
> >approximation syntonic comma = 11, Pythagorean comma = 12.
>
> Would that be a step of 612-tET then?

No, I believe it's smaller . . . it might have been 12*612, I don't
know.

> It looks vaguely familiar.
> Whose idea was it? Yours?

No, I saw it on a website somewhere. It looked very practical,
probably used by tuners somewhere. TU was the name I believe.

On 5/21/01 12:00 PM, "graham@microtonal.co.uk" <graham@microtonal.co.uk>
wrote:

>> a Roland VSC "Virtual Sound Canvas" program). The MIDI spec also
>> states that the bend range can be further honed down to the nearest
>> cent, using the data entry fine slider (Bx 26 xx), but neither of my
>> modules seems to respond to this message: when I try to set an overall
>> range of +/- 50 cents, I just get zero range. BTW, that range, if it
>> could be achieved, would make a midipu 1/16384 of a semitone, so the
>> lowest nontrivial range achievable on (at least my) GM modules would be
>> +/- 1 semitone, or 1/8192 = 1/(2^13) semitone per midipu.
>
> That's interesting -- so they respond to the coarse tuning (set pitch bend
> range in semitones) but not fine tuning (cents)?

I don't remember the command,
it's one of the Registered Parameter Numbers I think but I've never used it.
It's one of those Most Significant Byte/Least Significant Byte combinations.
Midi controller 99 or 100, then 6, etc... I can't recall.

I think they say cents because it's close to a cent,
But having seen the slider on a piece of midi software,
I'm pretty sure the fine tuning is in 1/128 of a semitone, not 1/100.
The pitch bend range is from 1 to 127 semitones,
and the fine tuning is from 1 to 127...

I'd heard 13-bit pitch bend keyboards are pretty rare and expensive.
Even though some can read the data, you have to check out the specs for it.
A lot of them are only 8-bit, having only 256 bends per semitone.
You can test it by recording a pitch wheel into a midi sequencer.
Assuming you have the pitch bend range sent to a default of 2,
if you notice all the pitch bends are in multiples of 32, that's 8-bit.

--- In tuning@y..., paul@s... wrote:

/tuning/topicId_23114.html#23449

> > > Also you're missing the TU (Tuning Unit) . . . it makes
> > > use of the approximation syntonic comma = 11, Pythagorean
> > > comma = 12.
> >
> > Would that be a step of 612-tET then?
>
> No, I believe it's smaller . . . it might have been 12*612,
> I don't know.
>
> > It looks vaguely familiar.
> > Whose idea was it? Yours?
>
> No, I saw it on a website somewhere. It looked very practical,
> probably used by tuners somewhere. TU was the name I believe.

http://www-personal.umich.edu/~bpl/temper.html

> TU notation, developed by organ builder John Brombaugh, is
> a system f describing very small intervals as integer values.
> It is a logarithmic system similar to that of "cents," but
> designed to be easier to understand and use than cents
> notation, when working with divisions of the commas.
>
> A TU is defined as 1/720th of the interval of a ditonic
> (Pythagorean) comma. That is, -720 TU must be distributed
> among the twelve fifths in a "circle of fifths" to remove
> the excess over seven octaves. (The ditonic comma is
> (3/2)^12 / 2^7; the logarithm of that amount is then for
> convenience called 720 Tuning Units.)
>
> With this system, the other important comma (syntonic comma)
> works out to be almost exactly 660 TU, and the difference
> between the two commas (the "schisma") is therefore 60.
> All three of the numbers 720, 660, and 60 are easily divisible
> by 1, 2, 3, 4, 5, 6, and 12, the divisors used in describing
> most temperaments. Therefore, most temperaments can be
> described in TU's using only integer values, without use
> of a calculator.

-monz
http://www.monz.org
"All roads lead to n^0"

Thanks for the TU link, the page is improved now:
http://www.xs4all.nl/~huygensf/doc/measures.html

Manuel

Joe,

>I don't understand the differences here between pitch-bend
>and MTS. The MIDI Spec website simply shows the data
>format for specifying a pitch, and it looked to me like
>it could be referring to either method. Please clarify.

No no, the MTS is an annex to the MIDI spec and has nothing
to do with pitch bend messages. The message code and format
is different. You should remove "bend" from your explanation
of MTS. Take "miditu" instead of "midipu" if you really must
use an acronym.
The most important distinction between the messages is that
the MTS uses absolute pitch values and pitch bend relative ones.
Pitch bend specifies an increment or decrement from the key's
tuning table pitch and is also relative to the range set with
the RPN earlier mentioned.
You have some more digging to do, but all can be found on the
Internet. Study the pitch bend MIDI codes. Then if you
understand everything, you could add explanation of the Yamaha XG
and Roland GS tuning codes too, and make a nicely comprehensive
webpage that will be useful to programmers. XG and GS resolution
is 1 cent.

Manuel

--- In tuning@y..., <manuel.op.de.coul@e...> wrote:

/tuning/topicId_23114.html#23540

> No no, the MTS is an annex to the MIDI spec and has nothing
> to do with pitch bend messages.

Ahhh.... now *that* explains the situation to me!

> The message code and format is different. You should remove
> "bend" from your explanation of MTS. Take "miditu" instead
> of "midipu" if you really must use an acronym.

Thanks for those suggestions, Manuel. Will do.
(I do think acronyms make it easier to discuss, BTW.)

> The most important distinction between the messages is that
> the MTS uses absolute pitch values and pitch bend relative ones.
> Pitch bend specifies an increment or decrement from the key's
> tuning table pitch and is also relative to the range set with
> the RPN earlier mentioned.

Thanks for this, too. The fog is beginning to clear...

> You have some more digging to do, but all can be found on the
> Internet. Study the pitch bend MIDI codes.

Yes, this is what I'm most interested in personally, because
it has very direct application to the current working version
of JustMusic.

> Then if you understand everything, you could add explanation
> of the Yamaha XG and Roland GS tuning codes too, and make a
> nicely comprehensive webpage that will be useful to programmers.
> XG and GS resolution is 1 cent.
>
> Manuel

That was my intent in creating that webpage, so all of your
suggestions are extremely useful. Thanks again.

Do you have any more URL links you can pass along?
If not, I'll get out the shovel and get started...

BTW... the link you just posted for your improved "interval
measures" page just gave me a blank screen. Tried it several
times.

-monz
http://www.monz.org
"All roads lead to n^0"

>Do you have any more URL links you can pass along?
>If not, I'll get out the shovel and get started...
http://www.algonet.se/~larsnyby/tools/xg_spec.pdf
http://www.cybertron.com/~brtubb

>BTW... the link you just posted for your improved "interval
>measures" page just gave me a blank screen. Tried it several
>times.
It's fixed now.

Manuel

--- In tuning@y..., "monz" <joemonz@y...> wrote:
>
> /tuning/topicId_23114.html#23449

Great detective work, Monz!

--- In tuning@y..., <manuel.op.de.coul@e...> wrote:

/tuning/topicId_23114.html#23548

> http://www.cybertron.com/~brtubb

Thanks, Manuel! But... this link didn't take me anywhere
significant. Please check again and repost. Thanks.

Also, I opened the Yamaha .PDF file and did a quick search
for "tuning" and "bend", and got no results. Didn't see
anything about it in the Contents either. Please direct.

-monz
http://www.monz.org
"All roads lead to n^0"

-monz

Joe wrote:

>But... this link didn't take me anywhere
>significant. Please check again and repost. Thanks.

Not my fault, maybe server down?

>Also, I opened the Yamaha .PDF file and did a quick search
>for "tuning" and "bend", and got no results. Didn't see
>anything about it in the Contents either. Please direct.

Please continue reading.

Manuel