search

firmata / protocol

Documentation of the Firmata protocol.
996 stars 151 forks source link

`protocol version 0xF9` is a system realtime message #1

Open reconbot opened 11 years ago

reconbot commented 11 years ago

Over the past few days I've been implementing a node.js midi parser with the idea that it would serve as the firmata/midi parsing guts of another project I'm working on. I've noticed that the protocol version request is a system realtime command. Which is great, however, it seems the version report is the same command except with 2 data bytes?

This only concerns me because it seems none of the other midi realtime commands have any data bytes and that parsers will have to special case this on the host side. (We're calling the two sides, host and device, right?)

I'm aware 0xF9 is undefined in the midi spec so it can technically can do anything we want.

I just want to make sure my assumptions are correct.

Thanks!

soundanalogous commented 11 years ago

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.

reconbot commented 11 years ago

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.

soundanalogous commented 11 years ago

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.

reconbot commented 11 years ago

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.

soundanalogous commented 8 years ago

This ends up being a problem for web bluetooth.

soundanalogous commented 8 years ago

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

monteslu commented 8 years ago

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

soundanalogous commented 8 years ago

@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.

soundanalogous commented 8 years ago

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.