Define a "valid Midi message"

padenot commented 8 years ago

In send:

If data is not a valid sequence or does not contain a valid MIDI message, throw a TypeError exception.

There should be some definition or at least some pointer to a normative reference that defines what a "valid sequence" or a "valid MIDI message" is. It seems quite important for compatibility that all UAs accept exactly the same messages or byte sequences.

For example this document warns exactly about this issue and points to the "official MIDI Specifications".

agoode commented 8 years ago

When that text was written, the official specifications were unavailable in a usable form. Fortunately, this has changed!

The spec should point to https://www.midi.org/specifications/item/the-midi-1-0-specification or https://www.midi.org/specifications as the normative reference.

bome commented 8 years ago

IMHO, validation should not go too far. For example, one could argue that certain controller numbers are not defined in the MIDI 1.0 spec and therefore not a valid MIDI message.

And do we want to prevent attempts to send messages starting with F4 (hex)? Right now, it's not defined, but technically, such messages can be sent via MIDI (though not via all physical MIDI transports), so is 'F4 30 4F" a valid MIDI message?

I'd say, the text should outline the criteria so that the implementation can easily verify it:

the first byte (status) has high bit set, any following bytes have not (except sys ex)
for high nibble of status (hex): if 8, 9, A, B, E: total message length must be 3. For D and E: total message length must be 2.
for status F1 or F3: total length 2 bytes
for status F2: total length 3 bytes
for status F6, F8, FA, FB, FC, FE, FF: total length 1 byte (status only)
for status F0: sys ex with any length, but last byte must be F7
for status F4, F5, F7, F9, and FD: message is not valid

The only thing that cannot be sent using this scheme is partial sys ex messages (e.g. for "streamed" sys ex). Not sure we want to allow that, but it could be handy, and the spec allows interrupting a sys ex message with a short message.

toyoshim commented 8 years ago

Should the F7 in the last item be replaced with F9?

FYI, Chrome currently forbids using such reserved status F4, F5, F9, and FD. Such input will raise TypeError with 'Reserved status is not allowed at index ().' message.

bome commented 8 years ago

toyoshim, you're right. I've added F9 to the last bullet. F7 is also an invalid status byte.

toyoshim commented 8 years ago

bome, thank you for updating your post.

By the way, I noticed that the spec already say

The terms MIDI, MIDI device, MIDI input port, MIDI output port, MIDI interface, MIDI message, MIDI System Real-Time message and system exclusive are defined in [MIDI].

and

[MIDI] Musical Instrument Digital Interface (MIDI) November 2001. MIDI Manufacturers Association. Complete MIDI 1.0 Detailed Specification ISBN 0-9728831-0-X URL: http://www.midi.org/techspecs/index.php

at http://webaudio.github.io/web-midi-api/#terminology and http://webaudio.github.io/web-midi-api/#normative-references.

It says MIDI message is defined in [MIDI], and we already have a reference for the MIDI spec. So the minimum fix should be just adding '[MIDI] reference there.

But, I also agreed that having clear definitions as bome suggested is handy and clear for users and developers. Probably spec writing specialists can make a good decision here.

padenot commented 8 years ago

By the way, this is not a theoretical problem. I'm currently reviewing the Web Midi implementation for Firefox, and the semantics of "valid midi message" and what is acceptable for send has been interpreted differently already. What Chromium does looks sensible, but it should be specified so all UAs have similar behaviour.

toyoshim commented 8 years ago

@cwilso can we have a clear definition that's based on @bome 's suggestion I did +1?

cwilso commented 8 years ago

Yes. We need to be clear about which of these is the definitive definition, though - the explanation I'll put in the spec, based on @bome's proposal, or the MIDI spec itself? One of these will need to be informative, in case they conflict. I'd recommend saying the text in the Web MIDI spec is informative, rather than the MIDI spec.

cwilso commented 7 years ago

Concur.

jmeile commented 4 years ago

I know this is an old post, but bome post regarding valid MIDI statuses, must be corrected. He did a mistake on the second line. So, here the whole definition again:

the first byte (status) has high bit set, any following bytes have not (except sys ex)
for high nibble of status (hex): if 8, 9, A, B, E: total message length must be 3. For C and D: total message length must be 2.
for status F1 or F3: total length 2 bytes
for status F2: total length 3 bytes
for status F6, F8, FA, FB, FC, FE, FF: total length 1 byte (status only)
for status F0: sys ex with any length, but last byte must be F7
for status F4, F5, F7, F9, and FD: message is not valid

The mistake was on the bold text: he included E to have a length of 2, but it was already under the length of 3, which is were it belongs to. Also, he excluded D, which is a length 2 message.

toyoshim commented 3 years ago

agreed that we need the definition in the spec. Let's keep this open to get a draft for non-normative explanation.

WebAudio / web-midi-api

Define a "valid Midi message" #164