Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a "valid Midi message" #164

Open
padenot opened this issue May 27, 2016 · 11 comments
Open

Define a "valid Midi message" #164

padenot opened this issue May 27, 2016 · 11 comments
Assignees
Labels
class: substantive https://www.w3.org/2023/Process-20230612/#correction-classes status: ready for editing Enough information should be available to implement this change in the spec
Milestone

Comments

@padenot
Copy link
Member

padenot commented May 27, 2016

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
Copy link

agoode commented May 27, 2016

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
Copy link

bome commented May 28, 2016

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
Copy link
Contributor

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
Copy link

bome commented May 30, 2016

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

@toyoshim
Copy link
Contributor

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
Copy link
Member Author

padenot commented May 30, 2016

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
Copy link
Contributor

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

@cwilso
Copy link
Contributor

cwilso commented Jun 9, 2016

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 cwilso self-assigned this Jun 9, 2016
@cwilso cwilso added the status: needs WG review Needs to be discussed with the Audio Working Group before proceeding label Jun 9, 2016
@cwilso cwilso added this to the V1 milestone Jun 9, 2016
@cwilso cwilso added the status: ready for editing Enough information should be available to implement this change in the spec label Sep 23, 2016
@cwilso
Copy link
Contributor

cwilso commented Sep 23, 2016

Concur.

@cwilso cwilso removed the status: needs WG review Needs to be discussed with the Audio Working Group before proceeding label Sep 23, 2016
@jmeile
Copy link

jmeile commented Mar 14, 2020

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
class: substantive https://www.w3.org/2023/Process-20230612/#correction-classes status: ready for editing Enough information should be available to implement this change in the spec
Projects
None yet
Development

No branches or pull requests

7 participants