Closed padenot closed 11 hours 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.
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 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.
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
toyoshim, you're right. I've added F9 to the last bullet. F7 is also an invalid status byte.
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.
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.
@cwilso can we have a clear definition that's based on @bome 's suggestion I did +1?
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.
Concur.
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 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.
agreed that we need the definition in the spec. Let's keep this open to get a draft for non-normative explanation.
In
send
: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".