Fwd: [tuning-math] Mu explained

Hi everybody,

I have been trying to upload a webpage explaining MIDI pitch bend, but the
server won't let me do it, so I'm sending it in text version here. I'll send the
web address as soon as I can upload the page.

Aaron
--------

MIDI PITCH BEND

There is some confusion surrounding MIDI pitch bend units and how pitch bend
units translate into equal divisions of an octave. The following is given in
order to clear up this confusion.

What is the industry standard for pitch bend?

There really is no industry standard for pitch bend. MIDI Tuning Standard
(MTS) specifies 14 bit precision for pitch bend messages, which are to be sent in
two bytes having 7 data bits and one data flag bit; however, the majority of
manufacturers have not implemented 14 bit protocol in their MIDI equipment.
Although some companies use fewer than 7 bits and some use a slightly greater
number, the majority of units send pitch bend data in one byte having 7 data
bits, so this is a good number to use as the industry default value.

How does pitch bend operate?

MIDI defaults to 12 tone equal temperament for MIDI notes. The default pitch
bend range is +/- a WHOLESTEP from a given MIDI note. The smallest rage that
can be set by the user is +/- a HALFSTEP. The smaller the subdivisions the
better, so we are discussing pitch bend where the range has been set to +/- a
halfstep. Keep in mind that this +/- range SPANS A WHOLESTEP. As you will see
below, this last statement is basically true but not entirely accurate.
The industry standard MIDI pitch bend gives 7 bits, so we have 128 values
0-127 for pitch bend for each MIDI note. A total absence of pitch bend for a
given MIDI note is the data value 64. This is similar to the center detent balance
or fader potentiometer on a home or car stereo, where the center is the
default position. Take a look at the joystick or pitch wheel on your synth and
notice that it springs back to the center. The center data value is 64, and at 64
there is no pitch bend. Greater than 64 is bending upwards, and less than 64
is bending downwards. This is how a range above and below a MIDI note is
covered using only positive data values.

65-127 = bend up from the MIDI note
64 = MIDI note with no bend
0-63 = bend down from the MIDI note

At data 64 there is no pitch bend.

Now, something that is vexing is that given 128 values there is no ‘center’;
the center is 63.5, not 64.

So why are there 64 values (0-63) below the MIDI note and 63 values (65-127)
above the MIDI note? We are told that at the extremes we end up at exactly a
halfstep below or above, respectively:

127 = halfstep above the MIDI note
64 = MIDI note with no bend
0 = halfstep below the MIDI note

THIS IS FALSE!

A bend of 0 reaches the halfstep below; however, A BEND VALUE OF 127 DOES NOT
REACH THE HALFSTEP ABOVE THE MIDI NOTE; it is one unit below it. If this does
not make sense, imagine stepping up a twelve tone equal tempered scale on a
piano. When you reach the 12th key, you have not completed an octave; you are
one step below an octave. If you started counting with ZERO, that last step
would be ELEVEN. The same thing is happening here. We start counting with ZERO,
and reach our last step at 127, but this does not reach our destination, it is
one unit below our destination. To reiterate,

A BEND VALUE OF 127 REACHES ONE UNIT UNDER THE HALFSTEP ABOVE THE MIDI NOTE

127 = one unit under the halfstep above the MIDI note
64 = MIDI note with no bend
0 = halfstep below the MIDI note

THIS IS CORRECT!

If you do not believe me, you can find out for yourself by performing the
following experiment. Set up your synth with pitch bend range of +/- halfstep.
Use sine tones (or whatever is closest that has no chorus or 'detune' effect) on
channels 1-3 and send the following MIDI data:

channel 1: MIDI note on 59, bend 127 (full bend upwards)
channel 2: MIDI note on 60, bend 64 (NO BEND)
channel 3: MIDI note on 61, bend 0 (full bend downwards)

THE RESULTING PITCHES ARE NOT IN UNISON.

Now turn off note 59 and you will be hearing the following unison:

channel 2: MIDI note 60, bend 64 (NO BEND)
channel 3: MIDI note 61, bend 0 (full bend downwards)

THESE PITCHES ARE IN UNISON.

The offender is:

channel 1: MIDI note 59, bend 127 (full bend upwards)

THIS DOES NOT REACH THE HALFSTEP ABOVE.

Turn off channel 3 and listen to these two pitches alone:

channel 1: MIDI note on 59, bend 127 (full bend upwards)
channel 2: MIDI note on 60, bend 64 (NO BEND)

THESE PITCHES ARE NOT IN UNISON.

What does MIDI note 59 with bend 127 result in? It is slightly flat of the
halfstep above. Turn of all notes and then try this:

channel 1: MIDI note 59, bend 127 (full bend upwards)
channel 1: MIDI note 60, bend 63 (bent one unit down)

THESE PITCHES ARE IN UNISON.

To summarize:

The range of 7 bit pitch bend is 0-127
Absence of pitch bend is data 64
Bend data 0 reaches an equal tempered halfstep below
Bend data 127 is one midi unit below an equal tempered halfstep above

THE FULL RANGE 0-127 SPANS JUST UNDER A WHOLE STEP
THIS IS AN EQUAL DIVISION OF 128 UNITS PER WHOLESTEP.

There are 6 equal tempered wholesteps in an octave, resulting in:

6 x 128 = 768 ED2

So, once and for all,
7 BITS DOES NOT RESULT IN 1536 DIVISIONS PER OCTAVE
7 BITS RESULTS IN 768 DIVISIONS PER OCTAVE

What about the MIDI Tuning Standard?

Although the MTS is not in use by most manufacturers, some do support it, and
we will see more units supporting it in the future. 14 bits may be seen as 7
bit units expanded by 128 values per unit. The 768 unit behavior - the way
they divide up a WHOLESTEP - is still in force as the MSB (Most Significant
_Byte) in a 2 byte message. The MTS at 14 bits gives:

MTS = 768 x 128 = 98304 ED2

So, once and for all,

THE MTS DOES NOT RESULT IN 196608 DIVISIONS PER OCTAVE
THE MTS RESULTS IN 98304 DIVISIONS PER OCTAVE.

What about names for MIDI tuning units?

Joe Monzo previously suggested the name 'midipu' for the 14-bit MTS. In July
2003, I suggested the general name 'Mu' for 'MIDI unit', and suggested that
Greek prefixes be used to specify the number of bits resulting in the unit.
Prefixes were offered and agreed upon by Joe Monzo, myself, Gene Ward Smith and
John Chalmers. Some personal preferences of mine are shown here. 'Mu' is written
with a capitol M because MIDI is an acronym which should always be
capitolized. Since 14 bit MTS technically results in the 'standard' MIDI pitch bend
unit, I do not give 14 bit units a prefix. Since a 1 bit system only allows
bending a full halfstep down and does not allow bending upwards, I consider it
useless. The results of the Mu naming system are given below for 2 to 14 bits:

2 - duoMu
3 - triaMu
4 - tetraMu
5 - pentaMu
6 - hexaMu
7 - heptaMu
8 - octaMu
9 - enneaMu
10 - decaMu
11 - endecaMu
12 - dodecaMu
13 - tridecaMu
14 - Mu

HeptaMu and Mu are shown in red as the industry standard and the MIDI Tuning
Standard, respectively.

What equal divisions of the octave result from various MIDI tuning units?

The proper number of divisions per octave is given in each case by the
formula:

6 x 2n

where n is the number of bits.

The results are:

bits - name = ED2
2 - duoMu = 24
3 - triaMu = 48
4 - tetraMu = 96
5 - pentaMu = 192
6 - hexaMu = 384
7 - heptaMu = 768
8 - octaMu = 1536
9 - enneaMu = 3072
10 - decaMu = 6144
11 - endecaMu = 12288
12 - dodecaMu = 24576
13 - tridecaMu = 49152
14 - Mu = 98304

For example, consider the simplest unit, the duoMu. We have 4 values in a 2
bit system:

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

The default data value for NO BEND will be 2. So we have:

3 = bend MIDI note up
2 = MIDI note with NO BEND
0-1 = bend MIDI note down

The division looks asymmetrical because data 3 does not bend all the way up
to the halfstep above. In this case it bends up a quarterstep. The bend results
are shown below:

3 = quarterstep above the MIDI note
2 = MIDI note with NO BEND
1 = quarterstep below the MIDI note
0 = halfstep below the MIDI note

Thus, the duoMu results in 24 equal divisions per octave. All other Mus may
be illustrated in the same fashion.

What about signed values?

Some manufacturers prefer to use a protocol employing signed values. This
means that one bit is used to signify that the data bits represent either a
positive or negative value. The resulting division of the octave will not be the
same as the values given above. An example of such a protocol is found in
Cakewalk software. I don't use Cakewalk software, but the specifics on this can be
found here.

07/06/2003, Aaron Hunt

back to ideas

hi Aaron,

thanks for the nice clear explanation.
a few comments ...

> From: <Pitchcolor@aol.com>
> To: <tuning@yahoogroups.com>
> Sent: Sunday, July 06, 2003 3:48 PM
> Subject: [tuning] Fwd: [tuning-math] Mu explained
>
>

> A BEND VALUE OF 127 REACHES ONE UNIT
> UNDER THE HALFSTEP ABOVE THE MIDI NOTE
>
> 127 = one unit under the halfstep above the MIDI note
> 64 = MIDI note with no bend
> 0 = halfstep below the MIDI note
>
> THIS IS CORRECT!

i don't believe i've ever seen this in the documentation.
boy, the official MIDI docs really bite.

> So, once and for all,
>
> THE MTS DOES NOT RESULT IN 196608
> DIVISIONS PER OCTAVE THE MTS RESULTS
> IN 98304 DIVISIONS PER OCTAVE.

OK, i get it. but now i understand what happened ...
(more below...)

> What about names for MIDI tuning units?
>
> Joe Monzo previously suggested the name 'midipu' for
> the 14-bit MTS. In July 2003, I suggested the general name
> 'Mu' for 'MIDI unit', and suggested that Greek prefixes be
> used to specify the number of bits resulting in the unit.
> <etc., snip>

i put up those webpages in one big rush of activity.
i can see that there is going to have to be some
serious editing ... i'm just going to take this paragraph
and use it for the opening of my webpages, if it's
OK with you.

i think i'd like to include your names, too.
in fact, can i quote liberally from this in
my definitions?

> For example, consider the simplest unit,
> the duoMu. We have 4 values in a 2 bit system:
>
>
> 11 = 3
> 10 = 2
> 01 = 1
> 00 = 0
>
> The default data value for NO BEND will be 2. So we have:
>
>
> 3 = bend MIDI note up
> 2 = MIDI note with NO BEND
> 0-1 = bend MIDI note down
>
> The division looks asymmetrical because data
> 3 does not bend all the way up to the halfstep above.
> In this case it bends up a quarterstep. The bend
> results are shown below:
>
> 3 = quarterstep above the MIDI note
> 2 = MIDI note with NO BEND
> 1 = quarterstep below the MIDI note
> 0 = halfstep below the MIDI note
>
>
> Thus, the duoMu results in 24 equal divisions
> per octave. All other Mus may be illustrated in
> the same fashion.

ah, now you're really cookin'! :)

*this* is what i've been waiting for, because now
i can go thru the process and construct all of the
different resolution specs myself, and get a really
good understanding of how the whole system works.

that business about losing a unit of data at the
top is what really threw me off.

> What about signed values?
>
> Some manufacturers prefer to use a protocol
> employing signed values. This means that one
> bit is used to signify that the data bits represent
> either a positive or negative value. The resulting
> division of the octave will not be the same as the
> values given above. An example of such a protocol
> is found in Cakewalk software. I don't use Cakewalk
> software, but the specifics on this can be found here.

ACHHH!!!!! no wonder i've been having such a problem
with this! i suspected that certain manufacturers using
or not using a bit to indicate sign was messing up my
understanding of how this works, and i was right.

too bad that you're only familiar with the unsigned
protocol, whereas i'm more familiar with the signed.

where's the "here" to which you refer? i'd like to
read up more on Cakewalk's implementation of
MIDI tuning.

-monz

hi again Aaron,

> From: "monz" <monz@attglobal.net>
> To: <tuning@yahoogroups.com>
> Sent: Sunday, July 06, 2003 5:09 PM
> Subject: Re: [tuning] Fwd: [tuning-math] Mu explained
>
>
> where's the "here" to which you refer? i'd like to
> read up more on Cakewalk's implementation of
> MIDI tuning.

imagine how funny it was when i went to the webpage
and the link took me to my own description of it!

seriously, does anyone know of documentation
on the "signed" protocol?

-monz

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

> > THE MTS DOES NOT RESULT IN 196608
> > DIVISIONS PER OCTAVE THE MTS RESULTS
> > IN 98304 DIVISIONS PER OCTAVE.
>
>
> OK, i get it. but now i understand what happened ...
> (more below...)

Please don't put up Aaron's misinformation re MTS on your page. I
think you should both look carefully at what MTS actually says before
putting up anything about it on a web page.

hi Gene,

> From: "Gene Ward Smith" <gwsmith@svpal.org>
> To: <tuning@yahoogroups.com>
> Sent: Sunday, July 06, 2003 6:36 PM
> Subject: [tuning] Re: Fwd: [tuning-math] Mu explained
>
>
> --- In tuning@yahoogroups.com, "monz" <monz@a...> wrote:
>
> > > THE MTS DOES NOT RESULT IN 196608
> > > DIVISIONS PER OCTAVE THE MTS RESULTS
> > > IN 98304 DIVISIONS PER OCTAVE.
> >
> >
> > OK, i get it. but now i understand what happened ...
> > (more below...)
>
> Please don't put up Aaron's misinformation re MTS
> on your page. I think you should both look carefully
> at what MTS actually says before putting up anything
> about it on a web page.

i now recognize that the problem i've had in
understanding Aaron's statements about MIDI tuning
are that he's used to using the non-signed protocol,
whereas i'm used to the signed version as in Cakewalk,
which apparently is the same one you know.

back in the late 1980s when i used "Texture",
IIRC it also used the system Aaron described,
where a value of 64 means the plain MIDI-note,
0 means a semitone lower, and 127 means a semitone
minus one tuning unit higher. so at least i'm
a little familiar with it.

can anyone else provide more insight into this?
please, others, speak up! i've put this stuff
into the Dictionary now but it's still not
*entirely* accurate!

why has MIDI tuning been implemented in so
many different ways? the whole point in creating
MIDI was to establish a *standard* way of doing things.
argh ....

-monz

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

> i now recognize that the problem i've had in
> understanding Aaron's statements about MIDI tuning
> are that he's used to using the non-signed protocol,
> whereas i'm used to the signed version as in Cakewalk,
> which apparently is the same one you know.

What signed protocol? I'm simply communicating what the MTS standard
says, and signed protocol or no signed protocol, it is exactly
the 12*128^2 = 196608-et and nothing else. I presume they know what
their own tuning standard is, and I'm not quite sure the idea that
they are mistaken and the standard is really something else even
makes sense. If they defined it that way, they are stuck with it,
aren't they?

No doubt some confusion over signed versus unsigned ints can be
lurking in the underbrush, but that matters not.

> back in the late 1980s when i used "Texture",
> IIRC it also used the system Aaron described,
> where a value of 64 means the plain MIDI-note,
> 0 means a semitone lower, and 127 means a semitone
> minus one tuning unit higher. so at least i'm
> a little familiar with it.

That sounds like a pitch bend to me; we were talking about the MTS
standard, which is not a pitch bend. The default system that Scala
and Audio Compositor and seemingly a number of other programs use
for pitch bends is 8192 for the middle of the pitch bend, and the
range 0-16383 to give +- a tone (200 cents.) This gives 40.96 * 12 =
49152 to the octave, your former cawapu.

> why has MIDI tuning been implemented in so
> many different ways?

Because there is pitch bend, which can be implemented in many
different ways, and for which you can change the default setup for
some programs such as Audio Compositor, and MTS, which is something
different. It is *not* pitch bend, it is MTS.

--- In tuning@yahoogroups.com, "Gene Ward Smith" <gwsmith@s...> wrote:

> That sounds like a pitch bend to me; we were talking about the MTS
> standard, which is not a pitch bend. The default system that Scala
> and Audio Compositor and seemingly a number of other programs use
> for pitch bends is 8192 for the middle of the pitch bend, and the
> range 0-16383 to give +- a tone (200 cents.) This gives 40.96 * 12
=
> 49152 to the octave, your former cawapu.

Before I get stoned by handheld calculators, let me hurry to say that
this should be either 4096 * 12 or 40.96 * 1200, your choice.

Joe wrote:
>why has MIDI tuning been implemented in so
>many different ways? the whole point in creating
>MIDI was to establish a *standard* way of doing things.
>argh ....

Well you know what they say about standards. The more
there are to choose from, the likelier it is that some
of them will be used.

Manuel

the main reason why there's been so much
confusion about this is this:

when MIDI tuning is implement so that the
plain 12edo MIDI-note is indicated by the
*center* value in the tuning range, as it usually
is (and as you described it), then the most
significant bit is being used simply to represent
that MIDI-note and indicate by a 0 or 1 whether
the other bits indicate a microtuning below or
above that note, respectively.

so, in essence, whatever number of bits
resolution is used in total, there is actually
one less bit available for microtuning.

so if the total resolution is 7 bits, one (which
falls half a unit above the center of the range)
indicates the MIDI-note, and the other 6 give
the fine-tuning.

illustration:

the "x" represents the status flag at the
beginning of the byte, and is not recognized
as part of the tuning resolution.

x 64 32 16 8 4 2 1 -- decimal value
x 1 0 0 0 0 0 0 -- bits

= 64 decimal = the plain MIDI-note,
0 cents deviation from 12edo.

x 64 32 16 8 4 2 1 -- decimal value
x 1 0 0 0 0 0 1 -- bits

= 65 decimal = one unit (1.5625 cents)
above the 12edo MIDI-note.

x 64 32 16 8 4 2 1 -- decimal value
x 0 1 1 1 1 1 1 -- bits

= 63 decimal = one unit (1.5625 cents)
below the 12edo MIDI-note.

this illustration makes it plain to see that
the left-most bit only indicates whether
the fine-tuning data is above or below
the plain MIDI-note.

there are only 6 bits being used for the
microtuning, which is why you kept saying
that my EDO values had to be cut in half.
the loss of one bit means to divide the
total range by 2.

but one point should be emphasized: MIDI
tuning data is always *described* as
units-per-semitone, regardless of the
actual range used. that's how i've rendered
my definitions.

-monz

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

> when MIDI tuning is implement so that the
> plain 12edo MIDI-note is indicated by the
> *center* value in the tuning range, as it usually
> is (and as you described it), then the most
> significant bit is being used simply to represent
> that MIDI-note and indicate by a 0 or 1 whether
> the other bits indicate a microtuning below or
> above that note, respectively.

This is *not* how the MTS works, however. Let's please get that part
right!