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