`protocol version 0xF9` is a system realtime message about protocol HOT 9 OPEN

I'm sure Firmata has strayed from the midi format over the years as no one has been enforcing it.

Regarding version report, you don't need to support it since SysEx REPORT_FIRMWARE (0x79) command can be used instead. I think version report only exists now for backwards compatibility (but I could be wrong). I wasn't involved with Firmata when the initial decisions were made.

from protocol.

I think 0x79 is firmware version vs 0xF9 firmata version. I'd love to propose a midi compliant SysEx response for the next protocol version.

from protocol.

This is tricky because Firmata Version (0xF9) may be used by some Firmata client libraries as the signal that the board is ready after a serial port connection has been made (this is what happens when a non-standard message has been in use for several years). I don't know off hand how many libraries this would effect and how many users there are relying on any of those implementations. Therefore 0xF9 may need to remain an exception to the System Realtime Message format.

If you feel like doing some research, take a look at a bunch of client firmata libraries and see if they are looking for a response 0xF9 on startup vs the REPORT_FIRMWARE command of a SysEx message. Basically anyone using 0xF9 in an active Firmata client library will need to change to their implementation to use REPORT_FIRMWARE if this moves forward.

from protocol.

I'll take a look when I get back to firmata-pi and midi-parser work later in the week. I think we shouldn't change it for 2.3 but instead change the behavior or message format in later versions.

from protocol.

This ends up being a problem for web bluetooth.

from protocol.

@monteslu This would be a place to address the issues you encountered in WebMidi and where we could brainstorm some potential work arounds.

from protocol.

We might have to add a SYSEX method to REPORT_FIRMWARE. WebMidi doesn't seem like single byte commands: https://chromium.googlesource.com/experimental/chromium/blink/+/refs/wip/bajones/webvr/LayoutTests/webmidi/send-messages-expected.txt#12

from protocol.

@monteslu looking over that test output, it doesn't look like 0xF4 (set pin mode) and0xF5 (set digital pin value) will work either. It appears the WebMidi parser rejects any reserved system messages (0xF4, 0xF5, 0xF9, 0xFD) regardless of message length.

from protocol.

However I think the following would work if the correct number of data bytes is used:

0xF1 : 1 data byte
0xF2 : 2 data bytes
0xF3 : 1 data byte
0xF6 : 0 data bytes

I believe any of the following would work as a single byte as well:
0xF8
0xFA
0xFB
0xFC
0xFE

One possibility may be to use one of the above single byte sysex messages for the REPORT_VERSION query and use 0xF2 for the 2 data byte REPORT_VERSION reply.

from protocol.