MMA official documentation about MTS (2)

While we are on topic (regarding the previously mentioned MMA
documentation page available at
http://www.midi.org/about-midi/tuning.shtml ), and besides the
obvious "100 cents / 214" typo found on the same page (that
should be read as "100 cents / 2 raised to the power of 14", i.e.
16384), I am also wondering if the bulk tuning dump checksum
formula is correct or not. E-MU reported an identical formula on
their Proteus sysex manuals, but I don't understand how can the
checksum be really safe in this case if it is limited to only 388
bytes; shouldn't it be computed on at least 384 (tuning data) +
16 (tuning name) bytes instead? And what about that "nn"
parameter?

Cheers,
Vic

The formula on the webpage is the standard. E-mu got it wrong
in the Proteus hardware. So that thing rejects good tuning dumps
for a wrong checksum. That's the reason for the extra
synth type 113 in Scala, otherwise it's a normal MTS dump.

Manuel

hi Vic,

my webpage about the MIDI tuning spec also
corrects these errors you mention.

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

(my analysis of the highest and lowest frequencies
is just past half-way down the page.)

however, i've been informed recently that i put
an error there too: the pitch-bend command covers
a total range of plus and minus one semitone,
for a total of 200 cents, not 100 as i state in
my webpage. i still have to fix it.

-monz

----- Original Message -----
From: "victorcerullo" <moog@libero.it>
To: <tuning@yahoogroups.com>
Sent: Friday, June 27, 2003 7:58 AM
Subject: [tuning] MMA official documentation about MTS (2)

> While we are on topic (regarding the previously mentioned MMA
> documentation page available at
> http://www.midi.org/about-midi/tuning.shtml ), and besides the
> obvious "100 cents / 214" typo found on the same page (that
> should be read as "100 cents / 2 raised to the power of 14", i.e.
> 16384), I am also wondering if the bulk tuning dump checksum
> formula is correct or not. E-MU reported an identical formula on
> their Proteus sysex manuals, but I don't understand how can the
> checksum be really safe in this case if it is limited to only 388
> bytes; shouldn't it be computed on at least 384 (tuning data) +
> 16 (tuning name) bytes instead? And what about that "nn"
> parameter?
>
> Cheers,
> Vic

Thanks again for the info, Manuel. I will delve more into the
Proteus problem in the next few days. Anyway, I am still
convinced that the MMA checksum formula shown on that page
is a little ho-hum, be it a standard or not, especially because of
the insufficient number of bytes they considered. It looks like a
decision taken in a hurry.

Cheers,
VC

>The formula on the webpage is the standard.
>E-mu got it wrong in the Proteus hardware.
>So that thing rejects good tuning dumps
> for a wrong checksum. That's the reason for
>the extra synth type 113 in Scala, otherwise
>it's a normal MTS dump.
>
> Manuel

You did a great work there Monz, thanks a lot for the link.

Cheers,
Vic

> my webpage about the MIDI tuning spec also
> corrects these errors you mention.
>
> http://sonic-arts.org/monzo/miditune/miditune.htm

I spent some extra time last night on the checksum problem.
The formula reported in the online MMA specifications about the
"old" bulk tuning dump reply message is not precise and it
creates more confusion than clarity. I really think this lack of
clarity is one of the main reasons of the failure of MTS in
becoming a real standard over the past ten years. Of course it's
easy to receive an MTS bulk tuning dump when the checksum is
totally ignored, like in the case of many E-mu products, but it's
not easy to generate and send it when you don't know how the
checksum must be precisely calculated (and those E-mu
products, for instance, only transmit microtuning data using their
own native tuning format). The checksum formula reported on
the MMA page http://www.midi.org/about-midi/tuning.shtml is:

chksum cchecksum (XOR of 7E <device ID> nn tt <388 bytes>)

The meaning of "nn" in this expression is not clear and there is
no reference at all to this parameter in that document. So, what
did they actually mean with "388" bytes? This expression can be
interpreted in many different ways, and besides the fact that it's
not clear why the MMA did not consider the additional 16 bytes of
the tuning name in the checksum calculation, they added a little
more confusion with the tuning enhancements document found
at the following address:

http://www.midi.org/about-midi/tuning_extens.shtml

which is much clearer in terms of the checksum algorithm but
that shows a significantly different approach with respect to the
previous document because in this case all the bytes between
F0 and the checksum are relevant for the checksum itself (safer).
I really wonder why the MMA never corrected their "old" document
after releasing the new key-based tuning dump specifications.

Cheers,
VC

> The formula on the webpage is the standard.
>E-mu got it wrong in the Proteus hardware.
>So that thing rejects good tuning dumps
> for a wrong checksum. That's the reason for the extra
> synth type 113 in Scala, otherwise it's a normal MTS dump.
> Manuel

Victor, I agree that the description is very vague.

>chksum cchecksum (XOR of 7E <device ID> nn tt <388
bytes>)

>The meaning of "nn" in this expression is not clear and there is
>no reference at all to this parameter in that document. So, what
>did they actually mean with "388" bytes?

The "nn" is the "01" preceding "tt".

The 388 bytes are the total number of bytes the checksum is
calculated upon, so 7E <device ID> 01 tt is four plus the 384
(3 * 128) tuning bytes.

>This expression can be
>interpreted in many different ways, and besides the fact that it's
>not clear why the MMA did not consider the additional 16 bytes of
>the tuning name in the checksum calculation

That makes sense, the tuning name is irrelevant so you don't want
to throw away a dump just because the name was transferred incorrectly.

Manuel

--- In tuning@yahoogroups.com, "Manuel Op de Coul"
<manuel.op.de.coul@e...> wrote:

> That makes sense, the tuning name is irrelevant so you don't want
> to throw away a dump just because the name was transferred
incorrectly.

It's relevant if you are trying to make sense of MTS and are
attempting to interpret it as tuning data of some kind. :)

> The "nn" is the "01" preceding "tt".
> The 388 bytes are the total number of bytes the checksum is
> calculated upon, so 7E <device ID> 01 tt is four plus the 384
> (3 * 128) tuning bytes.

Yes, I tried with that combination of bytes and I noticed that the
MTS files produced by Scala actually use nn = subID#2 = 01 for
the checksum. What's really surprising is that they called it "nn"
in a somewhat "official" online document; then, why not taking
care of the first sub-ID byte, i.e. that ''08" byte? This is so weird
and confusing that the MMA should have released a correction
document at least...

> That makes sense, the tuning name is irrelevant
>so you don't want to throw away a dump just because
>the name was transferred incorrectly.

I think all transfer data should be considered relevant in terms of
the checksum calculation, if we really want to calculate a
checksum of course, and this for various reasons (including the
reliability of the MIDI connections). Anyway, in the new MMA
specifications regarding their MTS enhancements, the
checksum calculation for the key-based 128-note tuning dump
includes the tuning name bytes.

Regards,
Victor Cerullo