hexaMu vs. heptaMu

Here is the issue as I see it: does the number of bits specified
by the unit name reflect the proper subdivision of the halfstep as
well as the MIDI data format? My feeling is that it needs to do
both. How do we accomplish this? Here's my answer:

The data format in the MIDI spec says 7 data bits. This is the
conventional or standard way to interpret the data, and this is
why I have been arguing for the prefix hepta rather than going
with monz's hexa, etc. When you say hexaMu, you mean 6 bits
per halfstep, which is correct; however, we are still talking about
a byte which has 7 data bits, which has seemed to me reason
enough to call it heptaMu. So which fact should the unit name
reflect?

As monz said, MIDI specs state tuning matters in terms of a
helfstep, so it makes sense to do the same here; however, this
requires a reinterpretation of the data. A logical reinterpretation
would resolve our disagreement over hexa versus hepta. The
change makes sense to me, and this is how I think it should be
stated:

'Center detent' data such as the data I have on my pitch bend
page can also be seen as a form of _signed data. The 7 data
bits can just as well be seen as 6 data bits with a least
significant sign bit. 0 = below, 1 = above. Thus the 7 data bits
become 6 data bits with a _sign _bit. I hope this is not
something somene already pointed out and I just missed it. At
any rate, an update to my webpage would contain all of this info
in logical order, so that the data format is clear from both the
conventional interpretation and this modified interpretation. This
also means that the remark about signed data at the bottom of
the page will become part of a larger description of signed data
types. HeptaMu becomes hexaMu, end of story.

What do you think?

Aaron

P.S. here's the page again, (NOT updated yet):
http://members.aol.com/pitchcolor/ideas/pitchbend.html

hi Aaron,

> From: "pitchcolor" <pitchcolor@aol.com>
> To: <tuning-math@yahoogroups.com>
> Sent: Wednesday, July 09, 2003 1:50 PM
> Subject: [tuning-math] hexaMu vs. heptaMu
>
>
> Here is the issue as I see it: does the number of bits specified
> by the unit name reflect the proper subdivision of the halfstep as
> well as the MIDI data format? My feeling is that it needs to do
> both. How do we accomplish this? Here's my answer:
>
>
> <snip>
>
> 'Center detent' data such as the data I have on my pitch bend
> page can also be seen as a form of _signed data. The 7 data
> bits can just as well be seen as 6 data bits with a least
> significant sign bit.

no, actually, it's the *most* significant bit which
acts as the sign flag.

as i explained here on Monday
/tuning/topicId_45325.html#45352

>> 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.

> 0 = below, 1 = above. Thus the 7 data bits
> become 6 data bits with a _sign _bit. I hope this is not
> something somene already pointed out and I just missed it.

i already revised my hexamu page a couple of days
ago to say this.

http://sonic-arts.org/dict/hexamu.htm

it's in the second paragraph quoted here:

>> "However, as of 2003, almost all MIDI hardware, including
>> both keyboards and other "regular" musical instruments
>> and most computer soundcards, ignores the less significant
>> byte of the two MIDI pitch-bend data bytes, thus limiting
>> tuning resolution to only 7 bits.
>>
>> Because the pitch-bend protocol uses the most significant
>> of these bits only to designate the frequency of the 12edo
>> MIDI-note which lies as close as possible to the center
>> of the pitch-bend range (namely, 1/2-unit above the exact
>> center), in effect making this bit merely a flag which
>> indicates the sign showing the direction of the pitch-bend,
>> and because the smallest total pitch-bend range from this
>> center is +/- 100 cents, the effective maximum resolution
>> for all of this hardware is 6 bits per Semitone.

-monz

Hi monz,

> > The 7 data
> > bits can just as well be seen as 6 data bits with a least
> > significant sign bit.
>
>
> no, actually, it's the *most* significant bit which
> acts as the sign flag.

In any case, the interpretation is unorthodox. Usually a sign bit
indicates that the 2s complement will be taken from the data
bits, and that isn't what goes on here. This unusual 'sign' bit isn't
really a sign bit. Let's call it a 'flag'. It means specifically:

0 = n - 1
1 = n

where n is the given MIDI note number

The 6 data bits then indicate 64 versions of a MIDI note, either
focused on n-1 or n according to the flag.

Now, this interpretation may cause some minor confusion in the
relation of a MIDI note with a sample. No matter what the flag is,
the sample is still taken from n. When the flag is 0, the sample is
still taken from n, not from n-1.
...
> i already revised my hexamu page a couple of days
> ago to say this.

Great! I sometimes can't keep up because I don't have web
access from home - just email. I will be updating my page soon.
Glad to see the work on 768 taking shape - this is useful info for
all pitch bending MIDI users.

Aaron

hi Aaron,

> From: "pitchcolor" <pitchcolor@aol.com>
> To: <tuning-math@yahoogroups.com>
> Sent: Thursday, July 10, 2003 11:31 AM
> Subject: [tuning-math] Re: hexaMu vs. heptaMu
>
>
> Hi monz,
>
> > > The 7 data
> > > bits can just as well be seen as 6 data bits
> > > with a least significant sign bit.
> >
> >
> > no, actually, it's the *most* significant bit which
> > acts as the sign flag.
>
> In any case, the interpretation is unorthodox.
> Usually a sign bit indicates that the 2s complement
> will be taken from the data bits, and that isn't
> what goes on here. This unusual 'sign' bit isn't
> really a sign bit. Let's call it a 'flag'. It
> means specifically:
>
> 0 = n - 1
> 1 = n
>
> where n is the given MIDI note number
>
> The 6 data bits then indicate 64 versions of a MIDI note, either
> focused on n-1 or n according to the flag.
>
> Now, this interpretation may cause some minor
> confusion in the relation of a MIDI note with
> a sample. No matter what the flag is, the sample
> is still taken from n. When the flag is 0, the
> sample is still taken from n, not from n-1.

i agree with what you say, and in fact that bit
doesn't *really* indicate sign, since the values
which are less than "n" (the 12edo MIDI-note)
are not measured downward from n (i.e., using
negative numbers), but rather as you say, upward
from "n-1".

but in practice it might still be easier to
think of it as a sign bit, and in fact, in the
dodekamu implementation in Cakewalk and numerous
other software sequencers, it does actually work
that way. the user actually has a choice to render
a note with pitch-bend either by using negative
values for the pitch-bend data or by keeping track
of the MIDI-notes by assigning them mentally to
8192 dodekamus above the MIDI-note specified as "0".

i've seen it done both ways, but of course the
method using negative numbers works better because
the score shows the MIDI-note that's closest to
the target microtonal note, which is what one
expects to see.

-monz